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
I can't speak to Vaadin, but adopting GWT was a huge mistake at my old company. We bought into the promise that you didn't need front-end developers or retrain on front-end tech, you can just use Java that you know and love!
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 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.
Also, GWT makes interacting with JavaScript libraries VERY painful. You have to go through a JNI-like FFI to do it.
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.
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.
Agreed, this was the same pitch at my old job. "We can all keep writing Java and have a consistent front end". Which was true to some extent but we had very few people who were proficient with CSS/HTML so when we had to build out new components it always went to them or was time consuming for other people. They use React/Redux now and have a few dedicated front end teams.
Exactly the same thing happened at my previous company...
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.
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.
Exactly. The abstraction is good to have quick first results.
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.
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.
This. I had so much hatred for GWT, even as a backend developer. I remember how painful debugging was
I did a few learning projects in GWT when it was new, in 2007. It was truly groundbreaking.
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.)
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.)
While the GUI frontend part in GWT is indeed mostly abandoned by Google, they still use the Closure compiler (which is the evolution of GWT in a way) very heavily in all of their flagship web applications. That way, most of the business logic is written in Java on every platform (backend, frontend with the aforementioned compiler (which produces crazy good output), android, and ios with a similar objc compiler), and the frontend can be native everywhere, which is imo the best tradeoff.
I don't know. Learning a new language isn't to be taken lightly and while I sort-of like C# I'm constantly aware that it's MS's property and shit is going to change and break. Also it seems Blazor is by MS, so ditto twice. I do not trust MS not to screw anyone over. Caveat emptor.
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.
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.
> while I sort-of like C# I'm constantly aware that it's MS's property and shit is going to change and break
You can say the same about Sun.
There's also the Mono project, which is kind of the analog of OpenJDK.
You can say the same about Sun.
There's also the Mono project, which is kind of the analog of OpenJDK.
I ask the same question. I use Vaadin extensively. What I really love about it is that I am able to code my frontend apps just like my backend microservices apps... e.g. with Spring Boot. You can really leverage the years of experience in Java backend on your frontend.
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.
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.
Do all those things you mentioned apply to Vaadin free plan or pro?
Free version. I do use pro but not for the things i mentioned. For example I use Vaadin Charts which is pro. Its ok, i might switch to another chart library but not a high priority right now.
FYI, GWT lives on as J2CL and is integrated with closure-compiler. Only the front end lib that was GWT is gone - arguably what people used it for though. AFAIK J2CL is still heavily used for gmail and gdocs ie those projects haven't been rewritten from scratch. J2CL sees less use than GWT used to since there are alternatives today for typed large-scale browser app development (such as ts), and also because J2CL is wrapped in Bazel build scripting, though J2CL and closure-compiler can be used from regular Java build tools or the command line as well via plain "java -jar ..." invocation.
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.
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'm interested in J2CL, but surprised by the sparse implementation of the JRE. I currently use TeaVM and CheerpJ which have both managed a much more complete JRE implementation despite less backing. I don't have the resources to help much myself, but I hope the JRE gets more support in the future.
The JRE emul stuff is from the gwt times so as old as the hills; I wouldn't hold my breath it'll ever get major official updates for things like java.io and similar.
I think the biggest reason is that they are really bad frameworks. GWT isn't really supported anymore, but for a while it was a creative way to build UI in a world where Javascript frameworks weren't that advanced. You might not like Angular, but React, Vue, Ember, Meteor, and many many others exist. If you want types and don't like the JS style, you can use Typescript.
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 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.
Further frontend is a lot about developing intuitions and mindset of user. The underlying thing doesn't change, you have components, events, pages/routes. All you need is a bit of html+css.
Just because it makes you break out in a cold sweat doesn't necessarily map to others. I can work comfortably on both ends of the stack. I despise gwt and vaadin. Why would I want to pick an inferior technology because someone has an inability to program in a different syntax or spend a few weeks on the job learning about a new framework. Jesus.
"inferior technology"
.... 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.
.... 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.
> GWT had a place back when the frontend capabilities of browsers were very very badly balkanized and pathetic.
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.
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.
> 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.
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.
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.
> Those big clients throw away their software at the end of the project?
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.
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.
i have an alternative suggestion (of course I do):
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>
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>
HTMX kept making my radar until I learned React. Now I consider Next/Mithril/SolidJS ahead of HTMX. I'm not sure how legit it is to track the evolution of items I don't get around to trying. :)
I'm not sure they solve the same problems; if you NEED the REST api and want to keep all of that consistent then something like react makes more sense.
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
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
I use SnapKit to do Java desktop development which compiles easily to JavaScript using TeaVM. SnapKit is both modern and conventional, a good middle ground between Swing and JavaFX. But most importantly, it combines the traditional win of desktop Java UI dev with the ease of web deployment.
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. :-)
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. :-)
Definitely worth a look thank you! On another note, I've experimented successfully with https://www.jsweet.org/.
While this looks impressive technically (everything rendered using <canvas>), it seems completely inaccessible to anyone else than users with a pointing device.
The demos feel fast on my iPhone, but deeply weird to squint at a teeny tiny 2000s style UI on my smartphone. Have you thought about “retina” or “responsive” UI patterns? I guess if you’re explicitly targeting only 2000s desktop users you don’t need it, but more and more consumers have 13” HiDPI tablets or touch laptops, and all consumers have touch phones.
SnapKit does support Retina/HiDPI, but most of the demos assume a larger default screen.
The look is a little dated, much of it due to the gray backgrounds. It just needs a couple months of work from someone with more aesthetic design sense than me.
The look is a little dated, much of it due to the gray backgrounds. It just needs a couple months of work from someone with more aesthetic design sense than me.
We built our startups web UI on GWT. It was super easy to get started and we had a decent looking UI in no time. Then newer JS frameworks came along and our site looked obsolete and crappy by comparison (I'm talking circa 2014-15 or so). We started looking at making the GWT code look good visually.
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.
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.
Someone else mentioned TeaVM and SnapKit, I plan to look into those.
Mostly because today, a Java application is either a back-end application or a dead-end project. Everything a user touches is either native or web, and you can't get proper UX if you skip steps and try to magically render a useful UI as a non-UI developer.
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.
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.
The language you write an UI in, isn't directly connected to how it feels. There are plenty of old feeling web, native and mobile apps out there.
Some years ago I wrote a desktop app in JavaFX. This is a Java UI toolkit (though I wrote in Kotlin), but, you can style it with CSS. It was a piece of cake to give it a GitHub-ish feel. The result felt a lot like a web app, just without the browser chrome. The app in question was a peer to peer app that benefited from some libraries written in Java, so it was a good fit for what the app needed to do.
At the moment it's a bit painful to do this sort of thing because of a lack of good distribution tools. But, that's about to change ...
Some years ago I wrote a desktop app in JavaFX. This is a Java UI toolkit (though I wrote in Kotlin), but, you can style it with CSS. It was a piece of cake to give it a GitHub-ish feel. The result felt a lot like a web app, just without the browser chrome. The app in question was a peer to peer app that benefited from some libraries written in Java, so it was a good fit for what the app needed to do.
At the moment it's a bit painful to do this sort of thing because of a lack of good distribution tools. But, that's about to change ...
JavaFX was about to be revolutionary for over a decade ;-) First it was availability, then it was integration, then it was build tooling and now it's distribution.
Most of the Java-for-the-user only exists on Android and niche markets (like some financial software).
And while it's true that the language doesn't determine the UX, the different things I mentioned (frameworks, languages etc.) are mostly relevant due to the mindshare, adoption and general availability of up-to-date resources to get the job done.
Most of the Java-for-the-user only exists on Android and niche markets (like some financial software).
And while it's true that the language doesn't determine the UX, the different things I mentioned (frameworks, languages etc.) are mostly relevant due to the mindshare, adoption and general availability of up-to-date resources to get the job done.
I don't think JavaFX is revolutionary, it's just a nicely designed UI toolkit. There are lots of markets where software needs GUIs but doesn't actually benefit from anything the web provides, beyond the general inertia you mention.
The cold sweat comment wasn't referring to my abilities, but to the thought that actual enterprises use the horrific combination of terrifying garbage called Angular, React, TypeScript, JavaScript and the legion of tools needed to make them do anything comprehensibly close to intelligibly useful in this year, 2022.
I miss GWT. Glad to see I'm not the only one. Then again I don't like web programming at all and I'd rather write a desktop UI, which explains it, I guess.
I miss the times when UI didn't necessarily mean web. I guess I'm obsolete.
I miss the times when UI didn't necessarily mean web. I guess I'm obsolete.
I started a GWT project last winter, but abandoned GWT and replaced it with Bootstrap + JS, because
* 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
* 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
GWT was great for boring tech stories back in the day. It was briefly alluded to in one of the comment I think but, at least to me, GWT's killer feature was porting big legacy battle-tested core GUI SDKs to HTML5 compliant browsers.
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.
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.
The biggest reason IMHO is that it was yet another GUI toolkit unrelated to Swing. It might have done better if it was more Swing-ish.
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.)
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.)
Check out Vaadin Flow framework. Modern single page web app in 100% in Java. Everything just works. And looks beautiful by default.
I'll give it a look, it's been years since I checked Vaadin out.
I used to love Java and was very into server side UI frameworks like these and Wicket.
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)
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)
You're relegated to the backend not because you know Java instead of Typecript, but because you don't understand the problems of frontend development.
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.
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.
Async data loading and intermittent connections are something backend developers should actually be prepared for, even though some of them like to pretend everything is always available quickly and reliably because of "cloud".
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.
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.
I dont think you have checked Blazor runtime libraries size. Last time I tried, it downloaded 5MB wasm files to the client in a simple hello-world screen.
Personally, I don't think Blazor is really finished, I wouldn't use it in production. It's more of an example of what can be.
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.
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.
> Ultimately, I don't think 5MB blobs are all that bad for web applications that need the enormous complexity these libraries provide.
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)
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)
[deleted]
"You're relegated to the backend not because you know Java instead of Typecript, but because you don't understand the problems of frontend development."
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.
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.
I don't know why but I do feel there is a gap here to empower backend developers to take over the full stack. ( I am one of the developers looking out for a good maintained, component rich, completely supported JVM java based FE framework )
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 !
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 !
Kotlin is not and never will be on my list of languages.
TeaVM is faster and more web-centric than either of the mentioned options:
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/
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/
This sounds encouraging, yours is around the third comment I've seen so far about TeaVM.
Had a peer the other day tell me he wanted to use Microsoft Blazor on a new project. I didn't know what that was so I did some research. After some research I finally determined that it was basically some kind of frankenstein between Vaadin and GWT for C# developers. My first thought was yep we tried this before with Java.
Microsoft had Silverlight, it's end of life now... that pretty much tells the story.
I used Vaadin a couple of years back converting a flash based app. Getting plug-ins to work was not fun, at all. Using JavaScript yourself/directly is much easier. Now I write Java and Typescript and have even more fun writing the right code for the problem while increasing my value/compensation.
Hilla (https://hilla.dev) should be a nice match then, for Java+TypeScript.
The is little intersection between people who do frontend development and people who are comfortable at that level with Java.
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.
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.
The fact that the pile of tools required to get a web to do anything useful is such a terrible mess including Angular and React is why I'm in full dismay that they are used by otherwise intelligent developers at all.
Funny, I pretty much consider Angular with TS the frontend version of Java with Spring.
I love working with both.
I love working with both.
Not Java, but close. With Kotlin, there is a version of Jetpack Compose (Android UI framework) ported for the Web. It's still experimental. Produced size is a bit too much (because of Kotlin/JS not being super optimized yet).
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.
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.
Vaadin Flow works great with Kotlin.
I've no interest in any Russian connected project including Kotlin, IntelliJ or nginx these days.
I remember JSF being big around the same time and working well enough (especially a4j ajax for jsf) so I think people preferred that as an interface since it was more similar to what they already knew, jsp.
We use Vaadin for admin frontends in Spring Boot backend services written in Kotlin - this way the BE team can build admin UIs without frontend dev involvement. For that, it works ok.
Everything user-facing is React.
Everything user-facing is React.
Google came up with Dart so they could move away from GWT and now use Dart extensively internal to the company. Why would I want to use GWT and not Dart?
Where exactly is that extensive usage? I am fairly sure Java is more used inside Google on every front than Dart is.
Google engineers use Dart to create many apps, including some that are essential to Google’s business. For example, if you use the Google Ads web or mobile app, you’re using a Dart app that supports much of Google’s revenue. Also, the Assistant team at Google uses Dart for features in Smart Displays, as described in this announcement.
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...
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...
The fact that after all these years that page only lists AdWords, is not encouraging.
I too write Dart (not Flutter), but let's not kid ourselves, Dart is not extensively used anywhere, even within Google.
I too write Dart (not Flutter), but let's not kid ourselves, Dart is not extensively used anywhere, even within Google.
We really should update that page: looking at git blame, it hasn't been touched for several years :( I'll file an issue.
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...
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...
It must sometimes be demoralizing for a respected member of the programming community (Bob Nystrom - munificent) who worked on Dart at Google, most recently adding null safety, for people to constantly sh*t on Dart on Hacker News, especially since it's a really nice language that is going unappreciated
HN shits on Dart and V extensively... And they are the only two languages I use daily. So even as a user it can be demoralizing!
I'm not shitting on Dart if that's what you mean, quite the opposite, I'm just sad that Dart is not getting same amount of push from Google as Go. I'm afraid that one day Dart may end up in already impressive Google Graveyard[0]. I very much prefer Dart to Go but I'm in the minority.
[0] https://killedbygoogle.com/
[0] https://killedbygoogle.com/
Sorry, I wasn't referring to you. When Dart came out in 2012 it was a big improvement on JavaScript, but some Google exec said the goal was to replace JavaScript, which was incorrect, so that community has been down on Dart ever since. It's kind of remarkable to me how sticky this Dart hate is even 10 years later. It's unreasonable, and like you, it makes me sad because working with the DOM in Dart is even nicer than jQuery to me.
I'm really interested in https://hilla.dev/ these days but I doubt any company I'll work at will use it as everyone seems to be react focused. I remember the hilla devs saying they were going to work on it compiling to wasm.
As others have said, GWT was really groundbreaking, but it ended up making codebases turn to mush really fast. I would look into Blazor if I were you. It lets you use C# with javascript to make not only webapps, but apps on pretty much any platform with no tweaks. It's pretty much GWT done right.
I do Java as I've done for several decades. I tried C# years ago despite Microsoft. Java and the JVM are superior, technologically and morally to anything they can come up with.
I think GWT lost the plot when they moved to browser based debugging (the initial version supported IDE debugging of frontend code, which was awesome.)
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.
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.
Tried it once. It was clunky but interesting for its time. The big draw was to get away from JavaScript, but today you can do that in better languages like Go or Rust using WASM or you can use TypeScript to get a JavaScript that doesn't suck as bad.
The only languages worth their weight are Java and C.
When GWT came out it was a rather unique way to write widget-based applications that run in the browser. There wasn't anything like Angular, React, Vue or Svelte. So competition is much fiercer than when it came out.
there seems to be a good push for server side front end development in other languages like LiveView (Phoenix/Elixir) , Livewire (PHP/Laravel) and Stimulus Reflex (ruby). There are many more.
There's also https://j2html.com/. I've been wanting to try it.
GWT can fuck right the fuck off.
I think that creating UIs in Java is only doable (well) when you have appropriate design tools - so in theory even Swing or OpenJFX (https://openjfx.io/) are okay.
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.
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.
I’m not sure about you, but for certain kinds of applications, I am fairly sure JSF is unbeatable in productivity. You don’t have to create a rest api, state is automatically replicated, automatic conversion of everything.
For say, an admin page, it is godsend.
For say, an admin page, it is godsend.
> For say, an admin page, it is godsend.
As long as you don't attempt to do anything that's too complicated, sure.
But if you get something along the lines of:
> "User α should be redirected to view β after choosing option γ in the confirmation dialog and the view should contain fieldsets δ, ε and ζ, the latter of which will display a table with data that will be fetched according to issue η, will have an input field in each of the rows and will recalculate the values of column θ and ι, whilst also letting the user to press the button at the bottom of the table to validate all of the data and show validation messages κ, λ and μ if any of the data doesn't match business rules. Oh, and you should also be able to click on a chevron in the table to extend the table row into a sub-table to preview the data there, as well as open a modal dialog ν that will contain a dropdown and an autocomplete to select data from EAV table ξ, which should update the table data accordingly."
then it's likely that the majority of developers will run into quite a few problems with life cycle management, compared to something like React/Vue, where you could easily have nested components that would typically also be reusable wherever necessary.
At the end of the day, I'd argue that it's easier to find people who are competent in any of the nowadays popular front end frameworks/libraries, as opposed to JSF or even JSP.
As long as you don't attempt to do anything that's too complicated, sure.
But if you get something along the lines of:
> "User α should be redirected to view β after choosing option γ in the confirmation dialog and the view should contain fieldsets δ, ε and ζ, the latter of which will display a table with data that will be fetched according to issue η, will have an input field in each of the rows and will recalculate the values of column θ and ι, whilst also letting the user to press the button at the bottom of the table to validate all of the data and show validation messages κ, λ and μ if any of the data doesn't match business rules. Oh, and you should also be able to click on a chevron in the table to extend the table row into a sub-table to preview the data there, as well as open a modal dialog ν that will contain a dropdown and an autocomplete to select data from EAV table ξ, which should update the table data accordingly."
then it's likely that the majority of developers will run into quite a few problems with life cycle management, compared to something like React/Vue, where you could easily have nested components that would typically also be reusable wherever necessary.
At the end of the day, I'd argue that it's easier to find people who are competent in any of the nowadays popular front end frameworks/libraries, as opposed to JSF or even JSP.
Agreed on JSF productivity, also found the parent comment quite astounding in this regard.