Ask HN: Why isn't GWT or Vaadin more popular among Java developers?
When I think about TypeScript and Angular I break out in a cold sweat. When I remember creating UI's in GWT and it just worked, in Java, it brings back fond memories. So I'm relegated to the backend. Any other Java devs out there who'd like to to more in the front end but in Java, the language we know and love?
92 comments
[ 3.9 ms ] story [ 130 ms ] threadSo 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.
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 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.
I love working with both.
https://htmx.org
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)
</shill>
If you're just building a webapp then you can do a low-js SPA app that's often significantly simpler AND more performant with HTMX.
But as always, different projects have different needs. <3
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.
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.)
If you want to learn a new lang and still have java access, maybe look into scala. I really did like that but I don't know what state it's in now.
You can say the same about Sun.
There's also the Mono project, which is kind of the analog of OpenJDK.
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.
As soon as it comes to browser-specific issues or very detailed customer requirements you need the flexibility to look behind the abstraction layer. Then, if you do not have the necessary expertise, you are lost.
My take away from my time working in GWT is that the main thing it was trying to do is fundamentally misguided. It tried to make Web development more like desktop UI development by erasing the client/server boundary. But that’s a natural and important boundary that needs to be clearly visible. And, in its effort to do so, the project ended up also creating a new artificial boundary that isn’t helpful and shouldn’t exist.
The problem isn’t writing client code in Java, BTW. There are plenty of projects like Elm that use the same language for both client and server code, and work well. The problem is trying to hide the Web behind a Swing-like API.
In particular, @GWTIncompatable made the leaking between frontend and backend an absolute nightmare. Their whole application was built on the idea that your models would be the same from the presentation layer all the way through to the database layer for 'DRY' reasons. It was horrible to work with and security was a disaster.
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.
In my experience as a "full stack developer" frontend likes to reinvent itself rather than find new solutions to problems. We've had responsive design policies for years now and touch screens have been the norm, I don't think you need a "modern" library for anything, really. Just one that works well enough and a big chunk of well thought-out CSS.
I think technologies like Blazor are more useful to practical application development than a new version of React/Svelte/Vue where the widgets are now Fogo-based rather than Bar-based because the library developers considered it a better API.
In a perfect world, you don't need two languages for frontend and backend. You can torture yourself by adding the Node stack to the backend, or try something like that new Kotlin project, but it's clear we're still quite a ways away from well integrated web application development.
Ultimately, I don't think 5MB blobs are all that bad for web applications that need the enormous complexity these libraries provide. Classic Django/Symphony/Spring Boot with some CSS animations and Javascript glue can work perfectly for the smaller apps. For things that aren't applications, you shouldn't need any framework at all, websites can/should just be static files to make everyone's lives easier.
The cases where this makes sense are probably internal enterprise applications or advanced tools.
For everyone else, there is this: https://whatdoesmysitecost.com/#gniCost (or at least it was a curious reference, before the pricing figures seemed to kind of break in other tabs; though this might as well be considered, not just site load times, or battery life implications)
I've designed a number of front-ends in various languages on various platforms and am very comfortable with vanilla web programming and design.
The reason I'm relegated to the back-end because 99% of front-end developers don't know how to program and choose garbage like JavaScript or based on it and are often intently amused by the mention of yet another tool out of hundreds that churn all that crap into something almost useful but hopelessly unmaintainable.
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.
Everything user-facing is React.
I miss the times when UI didn't necessarily mean web. I guess I'm obsolete.
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 !
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.
https://dart.dev/community/who-uses-dart
Flutter 1.0 is officially announced on Dec 04, 2018. After that, the demand of dart programmers is gaining popularity now. Because entire flutter app development is completely based on a dart. It seems that tech-giant Google has some big plans with the language. That’s why dart is implemented on two big projects including flutter and fuchsia OS.
https://dev.to/harshuinc/dart-the-language-behind-flutter-an...
I too write Dart (not Flutter), but let's not kid ourselves, Dart is not extensively used anywhere, even within Google.
[0] https://killedbygoogle.com/
Dart is used in almost every product group at Google.
- The Ads team continues to grow, with hundreds of SWEs primarily writing Dart code.
- The Google Play Console that lets app publishers market Android apps: all Dart (https://android-developers.googleblog.com/2020/06/introducin...)
- The Google Nest Hub and Hub Max devices: both the UI and a lot of back-end code are written in Dart
- Google Pay: Dart (and Flutter)
- Family Link, Google One, Stadia, Cloud Search: Flutter and Dart
Several other really big apps are being rewritten right now in Flutter. In all, there are thousands of SWEs writing millions of lines of code in Dart at Google.
And outside of Google, of course, there is the likes of BMW (https://www.press.bmwgroup.com/global/article/detail/T032861...), Sonos (https://tech-blog.sonos.com/posts/renovating-setup-with-flut...) and over 500,000 other Flutter apps that are all Dart-based.
Redmonk, the developer analyst firm, is pretty bullish on Dart: https://redmonk.com/jgovernor/2022/05/16/flutter-propels-dar...
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.
.... I turn my head and look at javascript.
GWT had a place back when the frontend capabilities of browsers were very very badly balkanized and pathetic. Now it doesn't.
.... and don't look now, but server-side rendering, like bellbottoms is trendy again!
" spend a few weeks on the job learning about a new framework"
... um, have you seen React? and in the few weeks you spend learning it, the entire javascript ecosystem has moved onto a new micropackage manager.
Everything that GWT did, frontend-wise, could be done just fine in any of the 'pathetic' browsers back then. Frontend capabilities of browsers were pretty good, if you knew what you were doing. (After all, GWT ran on top of that exact tech)
GWT's USP was that it enabled Java programmer's to build browser-based frontends, and not worry about HTML/CSS/JS. In theory at least — in practise: you'd eventually meet the edge of what GWT could do, the shit would hit the fan, and then you'd have to jump through hoops to e.g. integrate some JS library.
> server-side rendering, like bellbottoms is trendy again!
Modern server-side rendering actually still serves a modern JS SPA, with the exception that it hydrates (pre-populates with data/etc and renders) the page it serves.
— Your bellbottoms might look about the same at first glance, but it's a long way from being a simple apples-to-apples comparison.
> React? and in the few weeks you spend learning it, the entire javascript ecosystem has moved onto a new micropackage manager.
I've built apps for big clients using React (and SSR, FWIW). You pick your package manager and build system at the start of the project, and then you generally stick with it until (well after) the end of the project.
Tech always changes.
But for many big projects, you stick your stake in the ground, and work with that — it's a fool's errand to try and keep updating a real-world project to always use this week/month's fashion, and no decent management should even entertain the thought.
Doesn't mean you can't build a project on pretty recent versions of s/w though (e.g. React). Upgrades and changes to systems (e.g. package managers, build systems) should be managed properly, not chased like some primary goal of s/w development.
Those big clients throw away their software at the end of the project? That's what bugs me about Javascript: the Java/.NET/PHP server-side rendered applications from 10 years ago can be moved forward. Not painless, but if you want you can adapt them to run on a modern stack while with Javascript frameworks from 10 years ago you mostly have to start over.
Nope. Not at all. They're still in use, and still being further developed. None of it's been thrown away. Some things have been updated over time (in a managed way, e.g. newer React versions, updated build system, extra/better build-time tooling). New features have been added to the software. No problem hiring devs to do the work, React is a known quantity. The back-ends are a known quantity. All the apps are still a fairly modern stack: from front to back. No problem moving them forwards and implementing any of the things the customer/management wish for. All pretty painless.
— Some of the apps I refer to here were in fact a start-over from exactly what you describe, because that simply wasn't working out (for various different reasons on different apps, but one reason was the UI wasn't working as folk expected it to, in some cases wasn't responsive enough, etc).
Some apps are simply best done as a SPA. Horses for courses, innit. It's just a different kind of software development at the end of the day. It's not necessarily any less manageable to use React/similar in one's project(s). And we chose React because of what it brings to the table plus we could clearly see it would be well supported for some time into the future. — In fact we found React (plus the appropriate libraries) permitted very fast development / iteration, particularly compared to when one reaches the edge of what can comfortably be done using pure server-side rendering, and/or SSR plus 'spot' Javascript usage.