As it turns out, if you want to create a great front-end, you need to know javascript & css. You need to understand the difference between what is running on the client and what runs on the server. Corner cases which are super easy to fix with web-tooling turn into an impossible slog of trying to figure out how to get GWT do what you want it to do.
GWT interfaces are famously brittle ugly huge monoliths that send a million AJAX requests that are almost impossible to debug or optimize. There are no separations of concern. There's no defined "API".
It's like having nobody on your team know SQL and only ever use an ORM. At some point you need to break the layer of abstraction.
Fast forward to 2022 and GWT is completely obsolete. Today, systems like this compile to WASM. (IE, C# in the browser is done with WASM.) Furthermore, manipulating the DOM in code, as done in GWT, is extremely tedious and time-consuming compared to template-based approaches. GWT's live debugging leaves a lot to be desired.
Finally: Google abandoned GWT development. When I looked at its site in 2020, it looked like a hobby project; or something maintained by a small group of developers who still had projects using it.
Honestly: Don't be afraid to try a new language! In-browser development with C# (via Blazor) is really awesome, and coming from Java, it'll be an easy transition. (And it really is much, much better than GWT.)
So far I have not ran into a problem I could not fix yet. Vaadin does have a learning curve. After using it for a while, I find myself wanting to use my own components, versus the many components Vaadin provides out of the box.
Vaadin has support for PWA for single site apps. For multiple site apps, I had to create my own solution that relied heavily on Servlet Filters to dynamically return the PWA files.
Vaadin has a really cool testing library. It makes it really easy for me to do TDD on my frontend code. TDD is a MUST. So I quickly create a breaking test using the Vaadin testing framework... which uses Selenium underneath the hood. Using Selenium is huge cause I can get answers to my questions about testing by searching for the Selenium answer that I can apply in my tests.
Vaadin also supports PUSH technology out of the box. Its super easy to use. I use it extensively to have my web pages op up quickly, then slowly get filled out as the APIs return. No need to mention how awesome PUSH technology is. Though you need to be good at multi-threaded coding.
FYI, I don't work for Vaadin. Plus I am also a REACT programmer. I love REACT and find it very elegant. I shed a tear first time I used REACT. I think REACT and Vaadin are similar for me (in the sense that I can get a lot of high quality work done quickly). For personal projects I will always use Vaadin. For paying clients, they typically request REACT.... lol.
Technically, J2CL/closure-compiler, and the level of optimization and minification it can provide is unmatched by the likes of TS et al last I checked. Why one would use Vaadin (or Echo before) is a mystery to me though - these latter tools are putting too much weight into Java the language/ecosystem, for Java traditionalist developers who can't be bothered to learn something else IMO.
I have used GWT, I wouldn't use it again. I tried Vaadin, and it was so terrible I would never touch it again.
>So I'm relegated to the backend.
You are not relegated to backend. You can always learn JS Framework stuff. You shouldn't pigeonhole yourself into one area. Many many many developers do both.
rather than trying to build web front ends in a language-specific builder syntax server side and dealing w/the impedance mismatch between your language of choice and the actual realities on the ground in HTML, you use a more powerful hypertext instead
this lets you accomplish more in HTML, but also moves a lot of logic back to the back-end, so you are able to spend more time in your preferred language and framework
its an alternative approach to spending more time in your preferred language, it is just a hop skip and a jump beyond the normal HTML everyone knows anyway, and it transfers to any back-end that can produce HTML/hypermedia (nearly all of them)
SnapKit: https://github.com/reportmill/SnapKit
Demos: https://reportmill.com/snaptea/
Disclaimer: I am the primary author, so this is self-serving. But it doesn't mean it sucks. :-)
The pain was too big, styling this thing vs. just using ready made JS and HTML to create a simple UI. We eventually dumped GWT which was easier than going through the pain of adapting the UI. It seemed the community was dead and Google abandoned this long ago. Vaadin seemed nice but overly focused on the server aspect which we didn't feel we needed. Even they moved off of GWT eventually.
Today we still use TeaVM as part of Codename One itself to create web UIs. It works great and since we have the UI aspect working its good. But this works more like a Flash applet and isn't meant to be a website or typical web app.
It used to be much more acceptable to have "any" UI, but today, if you can't make a generic bootstrap, tailwind or react based UI, you might as well stop and hand that task over to someone else.
Dojo (the JavaScript framework) and ExtJs essentially died the same death (yes, there are still UIs based on those, and the instantly feel like 2006) because of the same reasons, while being completely web-targeted; they tried to make a Swing/AWT/WinForms type of application design a "thing" for the web, which didn't really work out long-term. It was great while it lasted.
I miss the times when UI didn't necessarily mean web. I guess I'm obsolete.
* There was an odd bug I had no clue about, where the top 2/3 of the page was unclickable, until I added enough elements on the page to cause scrolling
* Ugly layout, which the docs advised me to fix using CSS, which was exactly the approach I was trying to avoid
* No native support for server push, like websockets
* Pinned to Java 8
* Innate layout issues, like the clipping of panel edges
e.g., circa 2010, we were porting 50k+ LOC mapping/GIS libraries to the browser and it worked way better than we thought it would. This was a unit tested codebases that were being used for at least 5 years on the desktop. We were also able to get touch gestures working decently on it.
To second another comment, these days WASM would make more sense, but back in the day customers would be taken aback when were able to provide niche mapping features they were used to seeing on the desktop pop up on the browser.
This may be common knowledge, but I want to point out that Java's biggest problem was and remains distributing the runtime. And it's on this basis alone that JavaScript has won. Swing is a good toolkit - Swing is still used by Netbeans and IntelliJ, and a handful of other popular tools. Both of those tools have good round-tripping interactive form builders. It's a lot of value, but yeah, distribution is so bad you can't realistically access that value. (Compiling to native with Graal is an interesting option.)
Issue was though UIs started becoming a lot more stateful, and trying to manage complex state on server and synced to client brings a ton of complexity and scalability issues. (Memory was tough to manage with wicket, etc) Browsers and JS engines became way more powerful too and it just made a lot more sense starting about 10 years ago to do more UI on client.
If you actually enjoy UI development, the modern JS options are way better than the alternatives and you should try them out.
(I'm talking applications, not old school websites with no state between views)
Thinking about how a user interacts with a page, how asynchronous data loads, different screen sizes, how to handle intermittent connections are very different problems than most backend developers deal with. They are all very complex topics that have been evolving over the last 15 years. Modern frontend frameworks focus on addressing these complexities. Because JS/TS are the language of the frontend, the best frontend frameworks are written in these.
One of my reasons not to pick Vaadin was that it was backed by a company rather than a open source community. ( this seems better now in terms of support )
I do see other JVM languages like Kotlin seeing some success here.
Did you guys see dart and flutter ? I am pretty sure Java can do a comeback in terms of compiling to JS and taking the power from react/typescript guys !
https://blogs.oracle.com/javamagazine/post/java-in-the-brows...
* Super fast builds
* Complete Maven builds, no JS build nightmares
* Minifying, obfuscating
* Full, fast, HTML/CSS-based component framework.
* Works with any JVM language, not just Java
See a TeaVM-based game, Wordii: https://frequal.com/wordii/
Considering the tooling for almost any frontend framework is leaps and bounds ahead any of those two frameworks, it's a no brainer why no one uses it, in my opinion.
I love working with both.
https://compose-web.ui.pages.jetbrains.team
Vaadin has been around for a while now. I don't know how people feel about it. There is still some room for them on the market. It's "just" a backend service (Spring/VertX/etc) + a UI library (Vaadin's one/etc). It could look like Next.js but for JVM languages.
Just thinking out loud.
Everything user-facing is React.
Kotlin.js is getting pretty close to the ideal. Look into KVision, which is a framework on top of Kotlin.js, which is pretty ergonomic.
But once you start creating web apps, it all kind of breaks down.
I'd say that Vaadin was one of the less painful attempts at getting that architecture to work: it was only hard to customize when you tried doing something lower level, especially table display with custom row/column groups and how components look, as well as only had weird issues with reloading data often, like a progress bar during long processes and only certain parts of it broke when attempting version upgrades and it only was kind of slow when you needed to recompile the widget set and it only seemed to have some non-critical resource issues in some environments and it only sometimes failed in weird ways on the server.
Contrast that to PrimeFaces (which is based on JSF), the bane of my existence in legacy projects: complicated life cycle that generally causes bugs with dynamic pages and complex use cases, dynamic component ID generation but querying that only works sometimes properly (the whole naming container distinction), the need to bind front end state to back end fields, but also needing to expect lots of getter/setter calls, especially when you also need to throw in serialization for objects that you'd like to connect to your dropdowns, which in practice will more often look like storing the IDs from another list of options (though even simple things can break, like your dialogs disappearing after AJAX if someone didn't bind the visibility parameter), just generally a hard time creating custom components with their own back end behavior, especially when trying to reuse those in different contexts, problems if you ever need to mix JSF and JSP tags and even libraries like OmniFaces breaking on you, especially after updates. Honestly, I'm afraid that I don't recall most of the particular details, but on a 5-10 year old project my experience with PrimeFaces could be summed up with one word: pain.
I'm not saying that you absolutely cannot write good applications with a server side rendered approach, even with the more complex state management solutions (e.g. what Vaadin or PrimeFaces/JSF have), it's just that in practice you might be biting off more than you can chew - because once you venture off the beaten path, you'll find that the abstractions will leak their details and you'll be dealing with things that would have been easy with JS/TS/CSS/HTML becoming hard.
That said, Angular also feels a bit more complicated than it needs to be (though it does have a nice amount of functionality out of the box), personally I'd look more in the direction of React, or more recently, Vue (since it seems to do hooks a bit better than React), with simple RESTful API in the middle. That way, you have a clear separation between the front end and the back end, both remain testable and debuggable in separation, there's no leaky abstractions to deal with (or at least the ones that are there are mostly well known and you also won't kill your career by becoming a developer of a largely obsolete tech either).
Even with all of that, I might still look in the direction of Ruby on Rails, PHP with Laravel or even Java with Vaadin for when I need an admin panel and there are few design requirements to speak of - only functional ones for the most part.