[HN Gopher] Using Java for the front-end of a web app in 2022
___________________________________________________________________
Using Java for the front-end of a web app in 2022
Author : 0x54MUR41
Score : 19 points
Date : 2022-09-01 14:18 UTC (8 hours ago)
(HTM) web link (nocodefunctions.com)
(TXT) w3m dump (nocodefunctions.com)
| markeibes wrote:
| Why not stab yourself while coding while you're at it?
| gardenfelder wrote:
| 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
| mechanicum wrote:
| 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
| flkiwi wrote:
| 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.
| exabrial wrote:
| +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.
| didip wrote:
| 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.
| richbell wrote:
| 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.
| exabrial wrote:
| 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::
|
| and let the autocomplete in your Java IDE fill in the rest of
| the characters to form: <p:gmap id="googleMap" apiKey="xyz" />.
|
| Ultimate it's a tradeoff between getting exact control over the
| HTML (which you often don't need) and developer productivity.
| pjmlp wrote:
| Because we don't miss Java 5.
| idoubtit wrote:
| 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.
| arein3 wrote:
| 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
| rebugger wrote:
| 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/
| Rebelgecko wrote:
| 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.
___________________________________________________________________
(page generated 2022-09-01 23:02 UTC)