▲ 36 points
back
31 comments
+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.
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.
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.
Isn't Vaadin paid? The last time I took a look, I got denied because of licensing.
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.
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]
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 [2] https://clojurescript.org
Wow. Missed that one. Thanks!
For a fast, lightweight, Java-based front-end, try TeaVM and its Flavour toolkit:
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-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 * Making Wordii using TeaVM and Flavour: https://frequal.com/java/MakingWordiiAPureJavaSpa.html
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?
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.
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
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.
There are a ton of Java engineers who maybe don't want to have to use Javascript though.
Yes, but how many of them understand front end? It's not a matter of language and syntax...
It would be a brave move to go all-in on JSF for new projects now.
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.
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.
Go w/ templates is more an analog to JSP tech than JSF tech, I think that's the key differentiator. I'm guessing JSP is significantly faster and Go would be more memory efficient, but I hardly doubt any of that matters at the scale these two would be used.
JSF OTTH is a component framework and is much higher level than JSP|go/template. JSF performance probably falls below both JSP and Go templates. But, at a much lower cognitive load that both by an order of magnitude. For instance, to put a street map on a page with PrimeFaces, you simply type:
<p:gm ::tab-space::
Ultimate it's a tradeoff between getting exact control over the HTML (which you often don't need) and developer productivity.
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.
Garbage collection.
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.
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?
Because we don't miss Java 5.
Even Java 5 had generics.
Go finally as wel. (since 1.18), otherwise my reference would be to Java 4.
Let see how many years they will take for proper enums instead of the strange dance of type and const.
I have an idea, what about something like
type colors (red, blue, violet, ...)It's been many years for me but i recall ZK (zkoss.org) being fairly compelling
Why not stab yourself while coding while you're at it?
> 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
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)