5 ms·

Using Java for the front-end of a web app in 2022

36 points by 0x54MUR41 4y ago

exabrial 4y ago
+1 for JSF. I have my asbestos underwear on so flame away. Yes it scales just fine to thousands of users with minimal cpu/ram. And it's at least a billion times faster to develop small applications that Node + React + js callback soup. * Bootsfaces was another good component framework, but it's unfortunately fallen into dis-repair I'm not tied to JSF specifically as I think component based frameworks are still the easiest to work with to create and deploy things things at light speed. They have an upper limit of scalability (probably somewhere ~100k concurrent users) but that's a problem most people don't have.
arein3 4y ago
For simple web pages it's allright, but when you have complex UI you benefit from the declarative javascript frameworks like ReactJS, and those work best with REST endpoints
gardenfelder 4y ago
This was a grand stroll down memory lane; having hacked Java since JDK 1.0, I've seen a lot of improvement. An idle thought: he favors server-side rendering whereas the javascripts seem to favor client-side rendering. Along the way doing servlets, there came to be "view first" rendering, where you use serverside to paint a minimal page which, itself, uses ajax calls to fill in the blanks. I used that a lot. It's true also that I migrated from servlets to node. But, in all of this, clojurescript erupted on the scene. And, for me, that's where the piece gets interesting: he introduces us to a java to clojurescript transpiler and tells us it was used to craft the google app suite. Now it's time to go play [1] [1] https://github.com/google/j2cl https://github.com/google/j2cl
- mechanicum 4y ago
  That’s Google Closure [1] with an ‘s’, not ClojureScript [2] with a ‘j’. ClojureScript uses the Closure Compiler to optimise its JS output, but that’s the only relationship, and the name is a coincidence. [1] https://developers.google.com/closure https://developers.google.com/closure [2] https://clojurescript.org https://clojurescript.org
  - gardenfelder 4y ago
    Wow. Missed that one. Thanks!
rebugger 4y ago
I can recommend Vaadin[1]. It feels like a successor to GWT, feels natural for backend develops and looks similar to Swing. A big component library is included and it offers binding for Typscript webcomponents (there's a frontend-centric variant of the framework named Hilla too). Frontend states are held in a backend session, so it's safe for manipulations but i'd only recommend it for management UIs. [1] https://vaadin.com/ https://vaadin.com/
- Rebelgecko 4y ago
  I've used Vaadin for a small Kotlin utility and really liked it. The learning curve was pretty friendly and there's good documentation on their site.
- BossingAround 4y ago
  Isn't Vaadin paid? The last time I took a look, I got denied because of licensing.
didip 4y ago
But in this situation, why don’t I just use Go and it’s templating engine? Even faster to develop and slimmer when running in production.
- idoubtit 4y ago
  I doubt Go is really a better offer than Java to serve HTML pages. Go promoters are clearly focused on the backend (web APIs). For instance, my experience with HTML templating in Go using the standard library is that it's really slow. And that's even after taking the pain to optimize them as recommended (caching, etc). But, most of all, each frontend web project in Go has to decide if it's going to reinvent the wheel, or select one of the many short-lived frameworks.
- richbell 4y ago
  If you're familiar with Go, go for it. But there isn't really a compelling reason for a person or team to switch from Java to Go; Java also has a rich ecosystem of templating engines.
  - jrjarrett 4y ago
    Garbage collection.
    - dehrmann 4y ago
      This complaint is getting old. Java GCs have become really good. I've seen more issues on startup with empty connection pools, empty caches, and no compiled code than GC pauses.
    - pjmlp 4y ago
      You mean the poor experience of Go's GC that requires allocation of unused GB to keep it under control at scale, because the authors refuse to provide fine tuning options?
      - cdelsolar 4y ago
flkiwi 4y ago
I was weirdly disappointed in this because I thought it was going to be about applets—grey background, weird typography, no antialiasing fonts applets—in 2022, and I was super excited someone was going rogue. Like, it ended up interesting but it wasn’t what my heart wanted.
WantonQuantum 4y ago
It would be a brave move to go all-in on JSF for new projects now.
markeibes 4y ago
Why not stab yourself while coding while you're at it?
aitchnyu 4y ago
My bubble: major Java and .Net apps have crazy server heavy state and communication. I have to wait for a round trip to an overloaded server to view a tab with 50 words of info. They scold you for hitting back or refresh or idling 15 minutes and ask you to login again. Apparent "links" may be buttons and tabs may be unsupported. Does modern JSF have horizontal scalability and recover from state or networking hiccups?
- bzzzt 4y ago
  Technically, horizontal scaling is the job of the application server runtime. If you can keep server state limited it's possible to use clustered caches. Which requires a lot more setup than just failing over to another stateless node... A problem with component based frameworks like JSF is they like to put the entire component tree in the session to know which component is associated with a browser control. Complex pages will have a huge overhead to sync the state to a central cache or another node.
BossingAround 4y ago
I would think the biggest problem with JSF would be hiring new people. There aren't a ton of frontend developers who are happy to jump to Java in my experience, so putting this to production might prove challenging.
- mobiuscog 4y ago
  There are a ton of Java engineers who maybe don't want to have to use Javascript though.
  - BossingAround 4y ago
    Yes, but how many of them understand front end? It's not a matter of language and syntax...
harrylepotter 4y ago
It's been many years for me but i recall ZK (zkoss.org) being fairly compelling
KronisLV 4y ago
> But Java is slow and heavy? [in the context of JSF/PrimeFaces and others] Yes, with the setup of JSF and PrimeFaces, my experience has only been negative, both in regards to resource usage, performance and developer experience. Maybe not for smaller projects where your requirements are relatively simplistic, but once you're working on a huge monolith that has been around for 5+ years and has hundreds of forms, with nested components and lots of partial form updates and form state, absolutely - the experience is hot garbage. You might say that I've just worked on a bad codebase and I'd wholeheartedly agree, however in my eyes that's essentially the inevitable end point for how this entire technology stack will evolve in live codebases: a downwards trend towards hard maintainability and everything breaking. For example, it might be because you put <p:commandButton/> inside of a <p:panelGrid/> directly instead of a <p:outputPanel/>, but only the layout will break initially (and not always in obvious ways), yet the form state will be lost on tab navigation and will give you cryptic errors because your TabChangeEvent has null in the new tab field. Or maybe you'll need OmniFaces to handle validations but those won't play too nicely with <p:growl/> or any of the auto update logic, or maybe you'll find yourself struggling with PrimeFaces selectors because you just need to update a single row in a table that has components inside of it, as opposed to the whole table because that would be too slow, but won't be able to do so efficiently because somewhere along the way half of the ID will be generated dynamically but CSS selectors won't work properly either for some silly reason. Or maybe you'll run into problems where you must restructure your form because you cannot put certain elements such as modal dialogues inside of components that will be updated with AJAX thanks to some of the state being lost otherwise and sometimes the modal dialog flashing when things elsewhere in the form are updated. Even better when it won't play nicely with any other JS libraries that you might need because of project requirements, like custom calendar widgets or time pickers, or anything of the sort. Oh, and good luck integrating it with the rest of the application, serving static resources, figuring out all of the servlet related configuration, as well as scaling it, especially horizontally with multiple instances needing to share server side state information. I've actually written about some of the things previously: https://news.ycombinator.com/item?id=32071817 https://news.ycombinator.com/item?id=32071817 In short: my experience might be completely the opposite of many of the folks here, but if I see JSP/JSF/PrimeFaces/OmniFaces (and to a lesser degree, GWT or Vaadin), I'll run for the hills. I've had universally better experiences with Vue, React (even with hooks), Angular, and even jQuery back in the day. Actually, I think the only thing worse than the Java front end setup was Angular.js but maybe that was also due to a badly commented and bloated codebase. Instead, consider serving a React/Vue/Angular SPA app with Nginx/Apache/Caddy. Have a separate API as a self-contained Java/.NET/Node/Go/Python/Ruby/whatever executable/container. Set up a reverse proxy for SSL and any path related manipulations and live without having to stress over brittle architectures. Keep it simple and stay away from overengineered technologies. (disclaimer: I'm biased, server side rendering can also be pretty reasonable, e.g. Ruby on Rails, or perhaps a slightly better implemented setup with other stacks than what I've seen)
TeaVMFan 4y ago
For a fast, lightweight, Java-based front-end, try TeaVM and its Flavour toolkit: https://teavm.org/ https://teavm.org/ It is easy to get started by using the maven archtetype, there's an tutorial in Java Magazine here: https://blogs.oracle.com/javamagazine/post/java-in-the-browser-with-teavm https://blogs.oracle.com/javamagazine/post/java-in-the-brows... With TeamVM and Flavour you get a full front-end SPA framework that lets you code business logic in Java, and pair that with HTML and CSS to make components. To see what it can do, check out Wordii, a fast-paced 5-letter word game: * Wordii: https://frequal.com/wordii https://frequal.com/wordii * Making Wordii using TeaVM and Flavour: https://frequal.com/java/MakingWordiiAPureJavaSpa.html https://frequal.com/java/MakingWordiiAPureJavaSpa.html

36 points by 0x54MUR41 4y ago

+1 for JSF. I have my asbestos underwear on so flame away. Yes it scales just fine to thousands of users with minimal cpu/ram. And it's at least a billion times faster to develop small applications that Node + React + js callback soup. * Bootsfaces was another good component framework, but it's unfortunately fallen into dis-repair I'm not tied to JSF specifically as I think component based frameworks are still the easiest to work with to create and deploy things things at light speed. They have an upper limit of scalability (probably somewhere ~100k concurrent users) but that's a problem most people don't have.

arein3 4y ago

For simple web pages it's allright, but when you have complex UI you benefit from the declarative javascript frameworks like ReactJS, and those work best with REST endpoints

gardenfelder 4y ago

This was a grand stroll down memory lane; having hacked Java since JDK 1.0, I've seen a lot of improvement. An idle thought: he favors server-side rendering whereas the javascripts seem to favor client-side rendering. Along the way doing servlets, there came to be "view first" rendering, where you use serverside to paint a minimal page which, itself, uses ajax calls to fill in the blanks. I used that a lot. It's true also that I migrated from servlets to node. But, in all of this, clojurescript erupted on the scene. And, for me, that's where the piece gets interesting: he introduces us to a java to clojurescript transpiler and tells us it was used to craft the google app suite. Now it's time to go play [1] [1] https://github.com/google/j2cl https://github.com/google/j2cl

mechanicum 4y ago
That’s Google Closure [1] with an ‘s’, not ClojureScript [2] with a ‘j’. ClojureScript uses the Closure Compiler to optimise its JS output, but that’s the only relationship, and the name is a coincidence. [1] https://developers.google.com/closure https://developers.google.com/closure [2] https://clojurescript.org https://clojurescript.org
- gardenfelder 4y ago
  Wow. Missed that one. Thanks!

rebugger 4y ago

I can recommend Vaadin[1]. It feels like a successor to GWT, feels natural for backend develops and looks similar to Swing. A big component library is included and it offers binding for Typscript webcomponents (there's a frontend-centric variant of the framework named Hilla too). Frontend states are held in a backend session, so it's safe for manipulations but i'd only recommend it for management UIs. [1] https://vaadin.com/ https://vaadin.com/

Rebelgecko 4y ago
I've used Vaadin for a small Kotlin utility and really liked it. The learning curve was pretty friendly and there's good documentation on their site.
BossingAround 4y ago
Isn't Vaadin paid? The last time I took a look, I got denied because of licensing.

didip 4y ago

But in this situation, why don’t I just use Go and it’s templating engine? Even faster to develop and slimmer when running in production.

idoubtit 4y ago
I doubt Go is really a better offer than Java to serve HTML pages. Go promoters are clearly focused on the backend (web APIs). For instance, my experience with HTML templating in Go using the standard library is that it's really slow. And that's even after taking the pain to optimize them as recommended (caching, etc). But, most of all, each frontend web project in Go has to decide if it's going to reinvent the wheel, or select one of the many short-lived frameworks.
richbell 4y ago
If you're familiar with Go, go for it. But there isn't really a compelling reason for a person or team to switch from Java to Go; Java also has a rich ecosystem of templating engines.
- jrjarrett 4y ago
  Garbage collection.
  - dehrmann 4y ago
    This complaint is getting old. Java GCs have become really good. I've seen more issues on startup with empty connection pools, empty caches, and no compiled code than GC pauses.
  - pjmlp 4y ago
    You mean the poor experience of Go's GC that requires allocation of unused GB to keep it under control at scale, because the authors refuse to provide fine tuning options?
    - cdelsolar 4y ago

flkiwi 4y ago

I was weirdly disappointed in this because I thought it was going to be about applets—grey background, weird typography, no antialiasing fonts applets—in 2022, and I was super excited someone was going rogue. Like, it ended up interesting but it wasn’t what my heart wanted.

WantonQuantum 4y ago

It would be a brave move to go all-in on JSF for new projects now.

markeibes 4y ago

Why not stab yourself while coding while you're at it?

aitchnyu 4y ago

My bubble: major Java and .Net apps have crazy server heavy state and communication. I have to wait for a round trip to an overloaded server to view a tab with 50 words of info. They scold you for hitting back or refresh or idling 15 minutes and ask you to login again. Apparent "links" may be buttons and tabs may be unsupported. Does modern JSF have horizontal scalability and recover from state or networking hiccups?

bzzzt 4y ago
Technically, horizontal scaling is the job of the application server runtime. If you can keep server state limited it's possible to use clustered caches. Which requires a lot more setup than just failing over to another stateless node... A problem with component based frameworks like JSF is they like to put the entire component tree in the session to know which component is associated with a browser control. Complex pages will have a huge overhead to sync the state to a central cache or another node.

BossingAround 4y ago

I would think the biggest problem with JSF would be hiring new people. There aren't a ton of frontend developers who are happy to jump to Java in my experience, so putting this to production might prove challenging.

mobiuscog 4y ago
There are a ton of Java engineers who maybe don't want to have to use Javascript though.
- BossingAround 4y ago
  Yes, but how many of them understand front end? It's not a matter of language and syntax...

harrylepotter 4y ago

It's been many years for me but i recall ZK (zkoss.org) being fairly compelling

KronisLV 4y ago

> But Java is slow and heavy? [in the context of JSF/PrimeFaces and others] Yes, with the setup of JSF and PrimeFaces, my experience has only been negative, both in regards to resource usage, performance and developer experience. Maybe not for smaller projects where your requirements are relatively simplistic, but once you're working on a huge monolith that has been around for 5+ years and has hundreds of forms, with nested components and lots of partial form updates and form state, absolutely - the experience is hot garbage. You might say that I've just worked on a bad codebase and I'd wholeheartedly agree, however in my eyes that's essentially the inevitable end point for how this entire technology stack will evolve in live codebases: a downwards trend towards hard maintainability and everything breaking. For example, it might be because you put <p:commandButton/> inside of a <p:panelGrid/> directly instead of a <p:outputPanel/>, but only the layout will break initially (and not always in obvious ways), yet the form state will be lost on tab navigation and will give you cryptic errors because your TabChangeEvent has null in the new tab field. Or maybe you'll need OmniFaces to handle validations but those won't play too nicely with <p:growl/> or any of the auto update logic, or maybe you'll find yourself struggling with PrimeFaces selectors because you just need to update a single row in a table that has components inside of it, as opposed to the whole table because that would be too slow, but won't be able to do so efficiently because somewhere along the way half of the ID will be generated dynamically but CSS selectors won't work properly either for some silly reason. Or maybe you'll run into problems where you must restructure your form because you cannot put certain elements such as modal dialogues inside of components that will be updated with AJAX thanks to some of the state being lost otherwise and sometimes the modal dialog flashing when things elsewhere in the form are updated. Even better when it won't play nicely with any other JS libraries that you might need because of project requirements, like custom calendar widgets or time pickers, or anything of the sort. Oh, and good luck integrating it with the rest of the application, serving static resources, figuring out all of the servlet related configuration, as well as scaling it, especially horizontally with multiple instances needing to share server side state information. I've actually written about some of the things previously: https://news.ycombinator.com/item?id=32071817 https://news.ycombinator.com/item?id=32071817 In short: my experience might be completely the opposite of many of the folks here, but if I see JSP/JSF/PrimeFaces/OmniFaces (and to a lesser degree, GWT or Vaadin), I'll run for the hills. I've had universally better experiences with Vue, React (even with hooks), Angular, and even jQuery back in the day. Actually, I think the only thing worse than the Java front end setup was Angular.js but maybe that was also due to a badly commented and bloated codebase. Instead, consider serving a React/Vue/Angular SPA app with Nginx/Apache/Caddy. Have a separate API as a self-contained Java/.NET/Node/Go/Python/Ruby/whatever executable/container. Set up a reverse proxy for SSL and any path related manipulations and live without having to stress over brittle architectures. Keep it simple and stay away from overengineered technologies. (disclaimer: I'm biased, server side rendering can also be pretty reasonable, e.g. Ruby on Rails, or perhaps a slightly better implemented setup with other stacks than what I've seen)

TeaVMFan 4y ago

For a fast, lightweight, Java-based front-end, try TeaVM and its Flavour toolkit: https://teavm.org/ https://teavm.org/ It is easy to get started by using the maven archtetype, there's an tutorial in Java Magazine here: https://blogs.oracle.com/javamagazine/post/java-in-the-browser-with-teavm https://blogs.oracle.com/javamagazine/post/java-in-the-brows... With TeamVM and Flavour you get a full front-end SPA framework that lets you code business logic in Java, and pair that with HTML and CSS to make components. To see what it can do, check out Wordii, a fast-paced 5-letter word game: * Wordii: https://frequal.com/wordii https://frequal.com/wordii * Making Wordii using TeaVM and Flavour: https://frequal.com/java/MakingWordiiAPureJavaSpa.html https://frequal.com/java/MakingWordiiAPureJavaSpa.html