Wt

Hello Stefan,

Good news: we have no intention to reduce the effort in the development of Wt and/or JWt (rather the opposite), and there are no plans to discontinue Wt. Forum activity comes and goes, but you're right that lately we've been a bit too passive on answering to community questions. We'll try to be a bit more active on the fora - often this is not the top priority and too easy to keep track of when things get busy.

It is our target to have about 4 releases per year. These definitely include security fixes, and important bug fixes. In the coming releases, you can expect new features in the are of WebSockets (WWebSocketResource), an update to the authentication framework (MFA), and a rework of the authentication framework to support additional authentication methods.

Wt's new features are in big part steered by the popular suggestions we get from the community, and the requests from our commercial customers.

As usual, I highly recommend Wt for developing future-proof web applications! :-)

Best regards,
Wim.

Great to hear! I've been working on a commercial offering for 2 1/2 years and I can't imagine having to re-write it for another framework. I could do it, but I love this framework. I fear the process of training new hires (if I get to level!), but I think I know enough to get them productive.

Two suggestions:

1) A Swift language wrapper around the C++ apis would be very interesting since there are a lot of leading-edge things happening around Swift. And Swift is just a wrapper around C++/C/Obj-C. But I submit that C/C++ will never go away and I think C++ might be coming back around as more people learn the C++17 and C++20 standard libraries that make things SO much easier than C++11 and prior versions.

2) There is a very interesting project that I've been following for a few years that has been working on a next-gen identification platform. https://dock.io I think they are using blockchain or something along those lines.

https://www.swift.org/documentation/cxx-interop/

A bit late to the question, but perhaps an interesting data point nevertheless:

At our company we're in the process of implementing a new customer-facing web front end for our web-based services using Wt. (We are mostly into producing desktop apps, but start to provide web-based services.)

We began to "play around with Wt" a few years back and what's especially great (to us) is that even our early prototypes or demos can be made to run with minimal effort (mostly spent updating dependencies, and our custom premake files). Deployment is also pretty simple which helps as we don't yet have a dedicated ops team, and we like it "as simple as possible".

Our company is heavy on C++ talent (among a few other languages) so that can make a difference when making a choice regarding technology.

Wt, live long and prosper.

I'd like to revisit this thread. Over the past 6 months, I'm nearing the finish line to put my app into production. (Yes, a 3 year alpha->beta->production development effort!) I picked up some side work from another Wt user to pay the bills, and lately it seems like I'm jumping through hoops more and more to get things to work in our increasingly complex and modern world.

For instance, TinyMCE is now at Version 7, though I don't recommend going past Version 6 unless you are very familiar with their new Version 7 license. However, they have switched to NPM Rollup packaging and there are now far more capabilities available. WTextEdit needs a re-write to update this since it still caters to V3 and V4.

The current WCharts libraries are very powerful, but I'm currently building a wrapper around Charts.js (after giving up on D3!) because I need stacked bar charts, among other things. Buyers and Users these days get pulled into an app's orbit with good "eye candy" in the form of visuals and charts. They stay for the algorithms and results, but they get attracted by the visuals. Many of the powerful features of the WCharts libraries have been implemented in these new, alternative javascript libraries, or you can bake in extra functionality by rolling up other javascript libraries into one package. It's just a matter of plugging in the right options via JSON format.

I don't use WLeafletMaps, but that was designed for v1.56 which is now up to V2.

All of the CMakeLists.txt files reference C++14 and have deprecated keywords that cause CLion not to pick up the recursive CMakeLists.txt files in the subdirectories. I just saw that CLion will be introducing a bundled version of CMake 4.0 in the next release. I personally require C++17 as a minimum in my project. I always have to change the Wt CMakeLists.txt to 17 from 14 so that std::any (among other things) get packaged in the build properly.

Are there plans to modernize these frameworks? I'm loving the capabilities I have with WTemplates and Bootstrap 5, among other things, but some of these core, specialty engines (charts, maps, editors, etc) are getting a bit long in the tooth.

I'm hoping that is not the reason for the decreased activity in the forums, and hopefully you haven't shown a drop in the number of downloads for each release.

Is it expected that the community build these modernizations and donate them back to the library? Or are they on the long-term roadmap for Wt?

I wonder if there is a way to build an interface around NPM Rollup (or other javascript library delivery mechanisms) to make it easy to embed any javascript library of choice. Maybe it's an object that does all of the javascript and JSON setup behind the scenes so that a developer could name the javascript library (local or cloud) via wt_config.xml, populate a few std::vectorsstd::strings that feed into the backend javascript/JSON transformations to build the DOM tree.

It's not easy to build these wrappers without the help of some of the "internal use only" frameworks, especially those in the /web directory like WebUtils "round_css_str" or EscapeOStream.

Sorry, this was a little longer than I planned to write, but these are thoughts I've been noodling on for more than a few months.

Hey Mark,

sorry for the delay, I was out of office for a little while.

Some of the items you have said are either currently being worked on, or at least scheduled to be implemented soon:

• TinyMCE will be updated to facilitate version 5/6 (not 7, since as you said the license there is a limiting factor)
• charts is a little more complex to nicely integrate, but we will be considering it
• WLeafletMap is getting a big upgrade to add more functionality (in 4.12.x)
• an internal C++17 upgrade ticket exists (not all tickets are immediately made public, e.g. if they require some interface/big/tricky changes, or are exploratory)

Community involvement is of course always nice, and I have noticed people sharing their work here, some of which can be nicely integrated.

I like your suggestion for managing the JS dependencies, approaching it a little like (p)npm or maven. If I can pick your brain a little more, how would you see this working out? A developer defines a library and version, and a single command will generate the right "connector" code (i.e. WTextEdit would become somewhat of a template, and depending on the library generate concrete code)? That seems very tricky to generalize. Or am I misinterpreting here?

As for the widget/wrapper creation. I admit that there is some code in Wt that is fairly obscure, or more hidden. We try to be as permissive as possible now when writing new widgets / code, but the uses of certain classes can be so varied it becomes tricky to imagine what developers can or cannot do with them. We have a couple tutorials, showcasing certain aspects, but I don't think it's feasible to have a tutorial to cover all bases.

Thank you for your thoughts, I really appreciate them. I'd say to not be hesitant to share them in the future. Feedback is always nice.

Best,
Matthias

Thanks for the reply!

I'll address the Charts here, too. If it were under my control, I'd just do a parallel effort to the current chart library. No reason to rip and replace.

In terms of adding a library, I doubt a single command would do it. Although I've had some eye-opening experiences getting code out of Gemini Pro!

I think if there were a good tutorial on how to do it in general and provide an easy-to-understand framework, that should be sufficient. The hardest part for me was figuring out how everything worked. After you figure it out, it seems almost obvious, but until you get to that realization, it may as well be a puzzle from another galaxy.

If there was a standard way to say 1) load this module (with type="module") 2) create a new wt library widget in this manner 3) write the interface calls that are specific to this library (c++ to js and back). The customizations that you can put into the rollups almost demand that the implementer write their own interface. But loading them and making them available in Wt should be a standard process I would think.

Again, no need for rip and replace. Just introduce a parallel way to do it, if that is possible. Maybe it's not possible, I don't know.