I used Wt about a year ago for an application at work. I was able to write a GUI program that could be accessed at a web address or with a native Qt application, and Wt was equivalent enough (API-wise) that I was able to template between the two. Really neat actually. There was one place where the GUI was defined and you could choose whether you wanted web, native, or both! Only stumbling block was when I needed some opengl (webgl), but with a fairly minimal abstraction I was and to get that working in both two.
Wt felt very polished and worked exactly as I expected.
The Qt port for WebAssembly still has zero accessibility support, e.g. for blind people with screen readers. Assuming Wt is using standard HTML form controls, it shouldn't get in the way of accessibility. Of course, the app developer still needs to follow good accessibility practices, such as labeling images and not conveying information through color alone.
While it is unfortunate, in 30 years of software development that has never been a requirement for the projects I have been involved unless the customer was some kind of governmental institution and made it part of the acceptance criteria.
So unless there is a mindset change, that will keep happening.
Maybe the mindset change has to come from developers. That is, maybe developers are obligated to implement accessibility regardless of what the customer says. Remember, this isn't just a checkbox on a compliance form; it determines whether some people can do their jobs, complete their education, access essential services, etc.
Depends pretty much on your jurisdiction, then in many countries even if that is required by law, trying to make a lawsuit out of it will lead nowhere, as most countries aren't so lawsuit friendly as US.
Assuming that there is a court willing to hear it, probably by the time it reaches the first audience there is a new website in place.
Unfortunately the Qt demos all take 8-10 seconds to load on a phone for me and several of them fail with out of memory even on high end devices like a Pixel 4 XL. Certainly I'd expect a Pizza Ordering app to work on mobile (and to not show a flash style loading spinner for 10 seconds).
WT is doing all the logic server side so the client ends up being lighter weight and will work on more devices, and with better performance.
A lot of the comments question the use case but I think your story captures the ideal use case, a hybrid C++ / web app where you want to or need to share some of the functionality between web / c++ sides
It's not a bad way to build a web interface for a C++ application that needs to be configured over an intranet. It makes tying "click on a button on a web site" to "run an administrator action on my application" very easy, and you can use your Qt muscle memory to lay out a simple admin interface with relatively little mucking about.
You can do all that with CGI scripts or whatever, but if you already have a bunch of C++ running on the server it isn't nuts to use Wt to build your CRUDy admin interface.
In addition, I have used the templating in the library and it works really well. Let the UI/UX people do their thing and get the best performing back end.
But for a modern-C++ developer, Qt is so outdated... it's based on what the language was like 20 years ago. I would really rather not be limited to writing UI that way.
With 'modern C++' you can make APIs way nicer than the Java-like API going on here. Lambdas really help, along with RAII which has already been around. I have an API going where the following syntax creates a div with a 'toolbar' class and a toggle button with the 'edit' class and updates the DOM (C++ running in WASM, using IncrementalDOM for the DOM access):
This works by having `.div()` etc. return an `Elem` type whose constructor opens an HTML element and destructor closes it, with various overloads of `operator()` letting you set attributes, bind events or add child elements.
Yeah it's not great unfortunately. It ends up being that I have two sides of this code--one side is this subset that I've wondered about writing analysers for and checking the syntax just for this custom "dialect" almost. The other side is the impls of the APIs that side uses.
In general though I wonder how much the new 'concepts' stuff can help.
But yeah this is the closest I've come to having a UI DSL in a language with deterministic resource management and access to direct byte data layout for your structures. The main other alternative seems to be Rust and IME I've had a harder time with its error messages but I think it's also bc. I happen to have experience with 'old' C++. If I was starting fresh it'd be different.
The error messages produced by g++ for anything template related are a really difficult hurdle to overcome as a beginner. I am sure once you mastered it, it does make sense -- but right now it's a source of frustration for me.
I haven't used GCC in a while, but clang's template error msgs are way better than MSVC's in my experience. Still not like--good--haha. Like not Elm-level.
Yeah I'm looking forward to seeing how concepts work out in practice.
Also, to clarify on the original point, in this case it doesn't require that much template trickery. Most attributes could be handled as `.foo(Foos::BAR_1)` to set HTML attribute `foo="bar_1"` for example and have things still be 'type safe' on the C++ side. I just pass strings through right now to have a catch-all API, then I could go back on it after some real use and see what styles come in practice.
The only template it happens to use right now is the usual `template<typename F>` with `F &&f` to let you pass an inlineable lambda. I could use `static_assert` as you say, with `std::is_invocable_v`, and offer a nicer error message when that doesn't match.
I'm fine with that rn cuz the use case is a personal API for me making game tooling UI on a side project, still kind of experimental.
It's basically what the JS that gets generated from React JSX is like, and also like immediate mode UI APIs that get used for game tooling a lot: https://github.com/ocornut/imgui
I tried using Wt for a site almost a decade ago, it seems. The layout managers would make the site so terribly jittery that it could cause motion sickness.
My use case for Wt at the time as "I know C++ well and I don't want to learn anything else." I don't think I'll ever have a better use case for it and I don't think that one was very good to begin with.
The best use case I can imagine is something like "We have a lot of existing C++ code which we need to turn into a web app." But even then, why does the C++ code need to manage the DOM? It almost certainly doesn't.
So widget gets rendered to HTML on server side with events sent to it from client? That may work for logical events like click but not for mousemove (too expensive) ...
It's hard to compete with Open Source Libre libraries and lower C++ interest in new developers, not to mention developing in C++ is harder than many other languages.
My employer still struggles to this day finding good recent grads remotely interested in C++. In contrast, Java and Javascript skills are easy to find in the market.
Google and Facebook -- two of the biggest software companies are incredibly C++ focused -- especially in backend/infra. To a lesser extent Microsoft and Amazon are the same. And as others mentioned, trading farms love C++ too.
Essentially, in 2020, the highest paying software companies in the world all are heavily invested in modern C++. Knowing modern C++ is the biggest advantage you can have in the market. But you won't know that from reading the HN comments section.
They can afford to demand competence, and they need it. But they don't always get it.
They are the reason it can be hard to hire qualified C++ programmers elsewhere. You compete for the rest who find Wall Street and monopolists both morally repugnant.
I would say programming is really difficult and it is hard to find competent(pick an arbitrary line in the sand) for any skill let alone programming. Pick a field, and the web is stuffed full of people with battle stories of cleaning up after other people. This is actually a point or two against C++ as the breadth of it is so large. The trick, as in any practice, is to find motivated people willing to learn that are not stubborn in their set ways.
c++ are heavily used when a company need to push out more performance out of hardware through software, rather than just buying more hardware. When ever I hear someone wanting to get into game development I mention c++ as the standard language for that, but naturally there are many other places where performance in software can have a large impact on revenue or in reducing costs.
C++ people don't do CRUD webshit. C++ is for compilers, HFT, machine learning, browsers, search engines, robotics. When C++ touches "the web" it's in the form of something like Envoy or HAProxy, not exactly application layer. For CRUD webshit, there are literally hundreds of options out there that largely automate the entire process (Rails/Django/Spring). There is no reason to use C++ for it not just because of the timesink but because the lack of safety makes it an aggressively bad idea. You would get all kinds of "I thought that wasn't a problem in the 21st century anymore" type of problems.
People do need to write UIs in C++ though (sometimes as frontends for some of the purposes you mentioned), and Qt is probably the most used UI toolkit for C++.
Wt is basically Qt for the web. I've used a lot of UI toolkits across many languages, and Qt with modern-ish C++ is fairly productive, doubly so if you're slapping something together for an existing C++ codebase you have.
This is the exact use-case where I've used Wt. Existing C++ codebase, needs an admin interface, needs to be accessible over the corporate intranet. Wt is perfect for that.
I've written several applications using this approach lately, administrative systems.
None in C++ yet, but Java & Go.
Integrating the UI tightly with the backend has a lot of advantages and I strongly prefer working in a sane language to both template engines and JSON APIs.
You are better served using D and Vibe.d or other D web frameworks if you really want a compiled web stack. Also the other obvious choice is Go and probably Rust but I havent found a web framework for Rust that doesnt annoy me to no end yet.
So, Wt is about having the server do a bunch of computational work for rendering the UI. Now, I'm not a web developer, so I may be talking nonsense, but I don't see how that's reasonable:
1. It doesn't scale, or if you're rich - it's annoying to scale.
2. It interferes with the client/user's ability (albeit theoretical) to decide how they want to present the information
3. It seems to go against what are, or used to be, the principles of the web: Interlinked, clear-text, markup which the client renders as it sees fit.
Do you realize what Wt does is exactly the same thing PHP, Rails and others do and have been doing for decades?
So:
1. It does scale and it's easy to scale. In fact, one of the use cases of Wt is massive applications (e. g. Facebook apps)
2. No, it does no interfere with client's ability to decide how they want to present the information. What Wt does is the same thing any other web toolkit is doing: gracefully degradation, fallback, etc depending on your browser, browser version, and whether you have JavaScript enabled or not
3. How is Wt's output not interlinked, clear-text, markup which the client renders?
It seems you only know Angular, React and other client-side toolkits. The server-side approach has been (an is still) working for decades, do not disregard it.
The Wt backend spits out HTML/JS (or sometimes PDF or svg for charts), like any other server-side framework. It's not replacing the browser's renderer.
Wt is different to templating. It's server side rendering and the widgets communication is transparent, based on slots and receivers in the server side.
If you came from java it has similarities to Vaadin.
You don't have to write JavaScript, and it generates a page that acts like an SPA and does all the AJAXy stuff for you in the background. So you can just say "I want a button that does this server action on click" and it manages all the communication between the browser and the back end. It even gracefully degrades to full page reloads if the user doesn't have JavaScript turned on.
Kind-of, but you write webapps as if you were writing desktop apps: widgets, layouts, etc.
Wt can be compiled to its own webserver (which you would use directy if on an embedded device oruse behind a reverse-proxy for other cases), or you can compile it to a FastCGI module you can run with Apache.
I find it irritating that even after reading their front-page and the "How you can use WT" I still have no clue what it is supposed to be. Is this an embedded browser? Is it a C++ app GUI that allows you to use HTML like construction? Is it an emscripten application? How can it work without JS enabled? Is it compiled into pure WebASM? What the heck do they mean by connection? What connection? What does have PDF and DB to do with all that? Etc.
Very poor marketing imo. After reading all this I have even less clue what it is supposed to do.
It works without JavaScript because it can render everything server-side. If the user has JavaScript it uses websockets or Ajax to fetch updates from the server, but if it doesn't have those it can just reload the whole page like you would with a CGI application.
"Qt, but for web applications" would be a short and basically accurate descriptor. You slot together widgets in C++ and it works out how to lay them out and connect actions taken by the user to your event-handling code, which lives on the server.
The PDF thing is for rendering reports to PDF, instead of HTML. Not useful unless you're in a corporate sort of space, but when you want a PDF report you do want something like that. The DB thing is an ORM that makes basic CRUD operations on your database easier.
Oh strange, I completely assumed from the start that it was referring to front end C++ using Webassembly, similar to how some rust libraries do it. Never occurred to me this is server side.
Yeah it dawned on me the moment I hit sent... That this is probably something like ASP.NET for C++. Probably some people still need that :). Legit use case, just I think they need to work a lot on their messaging.
WrDesigner author here. I started the QtDesigner-like tool for Wt because I had a project where I needed to expose some existing C++ code on to the web. In the end I never used it. As I learnt web technologies, I found much flecible and easier to expose an API to the web using QWebChannel and then do the frontend with one of the existing frameworks (Vue, React, etc).
Wt felt very polished and worked exactly as I expected.