6 ms·

The times of ever-changing JavaScript frontend frameworks is long behind us (and, arguably, React has won for MVw-style browser apps). The core node.js web serv

The times of ever-changing JavaScript frontend frameworks is long behind us (and, arguably, React has won for MVw-style browser apps). The core node.js web serving APIs (expressjs and core http request API, which expressjs middlewares forwards and decorates) is stable since node.js v0.1 or at least 2015, and infinitely better than Java's servlet, JSP, and taglib APIs (web.xml/jetty-config.xml anyone?). The flip side of Java's stability is stagnation. On the server-side, customers use mostly Spring/Spring Boot these days to make Java's overengineered stack usable, using even more over-engineering and metaprogramming. Same with maven/gradle, which turns what should be a developer-focussed build system into an enterprise XML mess. SWT? I'm glad it works for you. Last I heard, IBM had pulled out of developing Eclipse and SWT/RCP over ten years ago. In the one project where we used it, the app looked like an IDE, and customers hated, then cancelled it. Designed as wrappers for OS-native GUI controls, it has even less of a place in a browser than Swing had. Last I looked, of the Java rich-client frameworks, only Swing has been updated with HIDPI support, whereas JavaFX and SWT haven't. None is using any of those (with the exception of experimental JFX apps) for new apps in this decade.

vbsteven 8y ago
You can call Spring (boot) over-engineered. I call it feature full and extensible. Whereas in the modern JS world, you start out with a lean project and then add small libraries from NPM that all work slightly different for every feature you need, in the Spring world where the framework has matured for 10+ years most of the things you will need are in the box or are available as external libraries that all work on the same defined interfaces. Spring Boot with Java 11 or Kotlin are still my preferred backend stack for that reason. It’s solid, has aged well and makes me super productive.
- nickspacek 8y ago
  Actually they just said that Java's server-side stack is overengineered, and that Spring/Spring Boot hides that complexity. I think that is mostly true.
  - vbsteven 8y ago
    Parent said that Spring Boot accomplishes that with more over-engineering and metaprogramming. I wanted to point out that what parent calls over-engineering is actually useful abstractions that make it easy to get started out of the box, and have sane standardized interfaces to replace or integrate components where needed.
  - jimbokun 8y ago
    "Spring/Spring Boot hides that complexity" Until it doesn't, then everything goes to Hell very quickly. Spring is close to impossible to debug, because everything is driven by annotations, configuration settings, property files, beans defined in XML, default values, or code that runs because you added a dependency even though you never explicitly call it. Program logic is defined in anything and everything, except actual Java code. The whole thing is a nightmare ignoring every principle of simplicity, composability, referential transparency, and every other established principle of good software design.
    - vbsteven 8y ago
      > Spring is close to impossible to debug, because everything is driven by annotations, configuration settings, property files, beans defined in XML, default values, or code that runs because you added a dependency even though you never explicitly call it. I see a comment like this every week on HN and I've been meaning to write a blogpost or two to address this. Yes, as you mentioned there is a myriad of ways to configure a Spring(Boot) application, and I think that is one of things that make it such a powerful framework or platform to build a service on. To address a few of your points: * beans defined in XML : we don't do that anymore since annotations got introduced. I haven't written a beans.xml file in years. * Program logic is exactly where you expect it: in the Java code. All the property files and annotations are used for configuration to allow for different environments. This setup allows us to run the exact same binary jar or docker image built from CI to run in CI, in dev, in staging and in multiple different production environments. * configuration settings and property files are the same thing as the configuration values go into property files, you can have multiple property files to group configuration logically by their purpose, and if needed duplicate each property file per environment to group those together. I know my database config for the staging environment is in database-staging.properties. If that is not enough you can easily override any of the values with environment variables * Debugging : another point where Java gets huge flak here on HN is huge stack traces, well I think those are actually helpful in figuring out exactly what is running and giving you trouble in a specific environment. And because of the separation of configuration from code mentioned above it is trivial to setup a testcase with the exact same configuration that you are having trouble with and use a debugger on that testcase to inspect and debug. * Simplicity and composability : While the framework can look complex if you don't understand the configuration system, it is actually there to facilitate composability. See my point about running the same binary in all environments. The big idea is that you put all code in the same repo and then compose and configure your application at runtime with the configuration system.
pjmlp 8y ago
In all these years I have used Spring exactly once for an architecture prototype, during one month project. All our customers doing Java Web projects are either on JEE, or a CMS platform running on top of servlets and JEE related JSRs, like Liferay and AM.
- tannhaeuser 8y ago
  I have no doubt it's working for you and your customers. But JEE and JSRs have been a dead end for many years now. When there are only single implementations for JSRs left, the whole exercise becomes pointless and masochistic, doesn't it? In 2006 I played around with Jackrabbit for an architecture concept (for managing airworthiness of airplanes and kit). That was before the Iphone even existed. I was honestly surprised Adobe is still using it in their AEM product. From what I recall, it manages a document tree, based on a 2004-ish, Drupal-like node graph in typical Java enterprise fashion. I'm no insider, but my guess is Adobe is struggling for some time now to integrate AEM, Magento, and other purchases into a lineup for creating shopping experiences. We'll see how this works out.
  - tannhaeuser 8y ago
    Edit: Liferay is a portlets container isn't it? My experience is only with Websfear portal (shudder) but I think managing UI state on the server has had no reason to exist since at least 2008 when Chrome/V8 came out, and the massive JavaScript improvements of the last 10 years following it
    - pjmlp 8y ago
      Meanwhile JavaScript frameworks are all the hype rediscovering server side rendering to improve performance. I have learned it pays off longterm to watch caravans pass by. Pure HTML and CSS with minimal JavaScript rules rendering performance.
  - coldtea 8y ago
    >When there are only single implementations for JSRs left, the whole exercise becomes pointless and masochistic, doesn't it? Not any more than PEPs are.
ivan_gammel 8y ago
Any app reaching complexity of what’s being done on Java will look the same, no matter what platform do you choose. I haven’t yet seen large nodejs deployments with MLOCs and hundreds of developers, but I’m pretty sure it can easily become much bigger mess - the tools and the libraries are immature, there’s lack of enterprise SDLC patterns etc, which creates a lot of obstacles. Spring is becoming too enterprisey these days, that’s true, but it’s still fit for use in modern architectures - only if you understand how to utilize all of its capabilities.
- tannhaeuser 8y ago
  nodejs isn't a replacement for fat backends for sure, but it's working really well for a frontend-facing light backend where frontend developers can add endpoints as the need arises, such as for autocomplete functionality, and where first-party support for asset pipeline tools is desired. The Spring experience isn't bad for newbies creating "REST" microservice spaghetti to have something to show at the end of their agile day, but it gets seriously in your way if you're a seasoned dev and have a solid understanding of what you want to achieve in terms of network-exposed interfaces and integration with other apps.
  - ivan_gammel 8y ago
    I‘m seasoned dev with 20 years of Java programming experience, I see no problems using Spring and I don’t see why anyone with similar experience would have any. It’s sometimes not obvious, how some things work, but it’s open source and the code is quite good to analyze, extend or replace.
    - jimbokun 8y ago
      "the code is quite good to analyze, extend or replace" But how do you even know what code to read when so much of the program's logic is in annotations and other kinds of action at a distance?
      - tannhaeuser 8y ago
BozeWolf 8y ago
Haha! Funny man! I am only doing javascript occasionly. Most of my time i do python and swift. Even stuff in “core” dependencies like webpack/yarn/npm/npx/nvm/babel changes a few times a year. Right now doing a react native app and a browser extension. While javascript/typescript is fun to write, the time you have to spend fixing the tools is just horrible. Whiping cache, rebooting, switching package versions.. It makes the overall experience cumbersome. I would not call something stable if it manages to work 2 whole years.
sourcesmith 8y ago
Bad decisions can be made using any technology. Java has a lot of crufty legacy APIs because, well it has a legacy. I gave up using JSPs years ago for Freemarker. I now use Vert.x rather than servlet contains which gives me a node.js environment but with access to the Java ecosystems and basic things like mature logging frameworks, as well as more advanced features (oh and multithreading in a single process). Despite Spring being Enterprise it still scales down to simpler apps pretty well due to its modularity. These can be build into a single jar app that is easy to build and deploy, and combined with a database migration library, maintain their own database schemas. Very, very usable. Yes, I probably would not use Java on the frontend unless it was for a technical audience.
lmm 8y ago
> On the server-side, customers use mostly Spring/Spring Boot these days to make Java's overengineered stack usable, using even more over-engineering and metaprogramming. There was definitely an era of that, but over the past decade or so it's been acknowledged as a problem, and there's been a lot of effort put into making things simpler and more vanilla. Modern Spring is much much closer to plain old code. (Of course it's still possible to write in the XML/setter injection/afterPropertiesSet style, and always will be - that's backward compatibility for you - but it's very possible to migrate existing applications to a better style in place, which very few platforms manage). > Same with maven/gradle, which turns what should be a developer-focussed build system into an enterprise XML mess. Maven is pretty close to the perfect build system, it's just taken a while for knowledge and practices to catch up with it. All the stuff people love and praise Cargo for, Maven has been doing for 15+ years.
- tannhaeuser 8y ago
  The basics of maven might be sound (though it could make it easier to work with local dependencies) and npm et al have basically copied it. Where maven dropped the ball is the myriad of maven plugin magic, maven's implicit lifecyle, and a pom.xml's Turing pits, etc. I've developed Java apps since almost the beginning, and am as much of a markup geek as could be, but still hate maven with a passion, and often times do not understand what tf it wants from me. I just don't have the patience with wading through crap that 2003ish Java nerds thought would be a good idea. And increasingly, as Java libs get EOLd, this will be a major problem for monolithic Java apps with tens of submodules. I don't think you can expect younger devs to keep maintaining daddy-o's web framework crap and cleanup the mess left by Java heads. However, I don't want to sound too negative. I can see a perspective for the JVM (Graal/Truffle) as a polyglot runtime where most of the ancient Java stuff is hidden from you, and you're using JavaScript or other non-JVM-only language as a migration strategy to get rid of Java alltogether in the distant future.
  - lmm 8y ago
    > Where maven dropped the ball is the myriad of maven plugin magic, maven's implicit lifecyle, and a pom.xml's Turing pits, etc. Could you be a bit more concrete? I don't recognize any of your descriptions in my experience of maven. There are probably some bad plugins out there, but as in any system the solution is not to use them. The complete lifecycle is listed in the documentation, and it's all very common-sense. pom.xml isn't meant to be Turing-complete, and if you try to use it like a Turing-complete build language you will get yourself in trouble (as many of the early Ant diehards did). You need to treat it as a declarative config file, no different from e.g. Cargo.toml. > I just don't have the patience with wading through crap that 2003ish Java nerds thought would be a good idea. And increasingly, as Java libs get EOLd, this will be a major problem for monolithic Java apps with tens of submodules. I don't think you can expect younger devs to keep maintaining daddy-o's web framework crap and cleanup the mess left by Java heads. It's just the opposite. I don't expect anyone to want to maintain Ant or Gradle builds in the future, since they can have any kind of crap in them. But Maven builds are forced to be kept sensible; the tool just isn't flexible enough to let you put crap in your build definition, by design. (If you really insist on doing crap you can make a crappy plugin, but your plugin is then forced to be versioned, tagged in VCS etc., so stands a better chance of being picked up by your organisation's normal code quality efforts).
provolone 8y ago
Spring and other frameworks may be popular, but the base servlet api with db connection pooling is enough. This approach feels much lighter than using frameworks. Not sure where the 'over-engineered' view comes from. I'd call that 'sane'. People complain about the verbosity of Java, but how much time do you spend learning a new framework and all of the gotchas? At the end of the day it seems easier to just write the boilerplate. All of that verbose code means you got exactly what you asked for. JVM projects never surprise me. When there is a problem debugging is a dream.
- coldtea 8y ago
  >Spring and other frameworks may be popular, but the base servlet api with db connection pooling is enough. This approach feels much lighter than using frameworks. That. I've used the Servlets API for years in the early to late 00s. I'm now (for the past 5 years) using Express with Node. Static typing and cosmetic differences aside, Servlets and Express (or Node's raw handlers) are pretty much the same API. Request, Response objects, handlers, middleware (iirc we used to call those last "filters" in the Servlet era), etc. It's not like it's some alien convoluted design. (Java Server Faces now was another thing)
apta 8y ago
> On the server-side, customers use mostly Spring/Spring Boot these days to make Java's overengineered stack usable, using even more over-engineering and metaprogramming. Could you elaborate on the overengineering part? There are many modern frameworks that are much lighterweight than Spring/Spring Boot, and with the introduction of lambdas in Java, things are even more straightforward. Also, gradle doesn't use XML.

vbsteven 8y ago

You can call Spring (boot) over-engineered. I call it feature full and extensible. Whereas in the modern JS world, you start out with a lean project and then add small libraries from NPM that all work slightly different for every feature you need, in the Spring world where the framework has matured for 10+ years most of the things you will need are in the box or are available as external libraries that all work on the same defined interfaces. Spring Boot with Java 11 or Kotlin are still my preferred backend stack for that reason. It’s solid, has aged well and makes me super productive.

nickspacek 8y ago
Actually they just said that Java's server-side stack is overengineered, and that Spring/Spring Boot hides that complexity. I think that is mostly true.
- vbsteven 8y ago
  Parent said that Spring Boot accomplishes that with more over-engineering and metaprogramming. I wanted to point out that what parent calls over-engineering is actually useful abstractions that make it easy to get started out of the box, and have sane standardized interfaces to replace or integrate components where needed.
- jimbokun 8y ago
  "Spring/Spring Boot hides that complexity" Until it doesn't, then everything goes to Hell very quickly. Spring is close to impossible to debug, because everything is driven by annotations, configuration settings, property files, beans defined in XML, default values, or code that runs because you added a dependency even though you never explicitly call it. Program logic is defined in anything and everything, except actual Java code. The whole thing is a nightmare ignoring every principle of simplicity, composability, referential transparency, and every other established principle of good software design.
  - vbsteven 8y ago
    > Spring is close to impossible to debug, because everything is driven by annotations, configuration settings, property files, beans defined in XML, default values, or code that runs because you added a dependency even though you never explicitly call it. I see a comment like this every week on HN and I've been meaning to write a blogpost or two to address this. Yes, as you mentioned there is a myriad of ways to configure a Spring(Boot) application, and I think that is one of things that make it such a powerful framework or platform to build a service on. To address a few of your points: * beans defined in XML : we don't do that anymore since annotations got introduced. I haven't written a beans.xml file in years. * Program logic is exactly where you expect it: in the Java code. All the property files and annotations are used for configuration to allow for different environments. This setup allows us to run the exact same binary jar or docker image built from CI to run in CI, in dev, in staging and in multiple different production environments. * configuration settings and property files are the same thing as the configuration values go into property files, you can have multiple property files to group configuration logically by their purpose, and if needed duplicate each property file per environment to group those together. I know my database config for the staging environment is in database-staging.properties. If that is not enough you can easily override any of the values with environment variables * Debugging : another point where Java gets huge flak here on HN is huge stack traces, well I think those are actually helpful in figuring out exactly what is running and giving you trouble in a specific environment. And because of the separation of configuration from code mentioned above it is trivial to setup a testcase with the exact same configuration that you are having trouble with and use a debugger on that testcase to inspect and debug. * Simplicity and composability : While the framework can look complex if you don't understand the configuration system, it is actually there to facilitate composability. See my point about running the same binary in all environments. The big idea is that you put all code in the same repo and then compose and configure your application at runtime with the configuration system.

pjmlp 8y ago

In all these years I have used Spring exactly once for an architecture prototype, during one month project. All our customers doing Java Web projects are either on JEE, or a CMS platform running on top of servlets and JEE related JSRs, like Liferay and AM.

tannhaeuser 8y ago
I have no doubt it's working for you and your customers. But JEE and JSRs have been a dead end for many years now. When there are only single implementations for JSRs left, the whole exercise becomes pointless and masochistic, doesn't it? In 2006 I played around with Jackrabbit for an architecture concept (for managing airworthiness of airplanes and kit). That was before the Iphone even existed. I was honestly surprised Adobe is still using it in their AEM product. From what I recall, it manages a document tree, based on a 2004-ish, Drupal-like node graph in typical Java enterprise fashion. I'm no insider, but my guess is Adobe is struggling for some time now to integrate AEM, Magento, and other purchases into a lineup for creating shopping experiences. We'll see how this works out.
- tannhaeuser 8y ago
  Edit: Liferay is a portlets container isn't it? My experience is only with Websfear portal (shudder) but I think managing UI state on the server has had no reason to exist since at least 2008 when Chrome/V8 came out, and the massive JavaScript improvements of the last 10 years following it
  - pjmlp 8y ago
    Meanwhile JavaScript frameworks are all the hype rediscovering server side rendering to improve performance. I have learned it pays off longterm to watch caravans pass by. Pure HTML and CSS with minimal JavaScript rules rendering performance.
- coldtea 8y ago
  >When there are only single implementations for JSRs left, the whole exercise becomes pointless and masochistic, doesn't it? Not any more than PEPs are.

ivan_gammel 8y ago

Any app reaching complexity of what’s being done on Java will look the same, no matter what platform do you choose. I haven’t yet seen large nodejs deployments with MLOCs and hundreds of developers, but I’m pretty sure it can easily become much bigger mess - the tools and the libraries are immature, there’s lack of enterprise SDLC patterns etc, which creates a lot of obstacles. Spring is becoming too enterprisey these days, that’s true, but it’s still fit for use in modern architectures - only if you understand how to utilize all of its capabilities.

tannhaeuser 8y ago
nodejs isn't a replacement for fat backends for sure, but it's working really well for a frontend-facing light backend where frontend developers can add endpoints as the need arises, such as for autocomplete functionality, and where first-party support for asset pipeline tools is desired. The Spring experience isn't bad for newbies creating "REST" microservice spaghetti to have something to show at the end of their agile day, but it gets seriously in your way if you're a seasoned dev and have a solid understanding of what you want to achieve in terms of network-exposed interfaces and integration with other apps.
- ivan_gammel 8y ago
  I‘m seasoned dev with 20 years of Java programming experience, I see no problems using Spring and I don’t see why anyone with similar experience would have any. It’s sometimes not obvious, how some things work, but it’s open source and the code is quite good to analyze, extend or replace.
  - jimbokun 8y ago
    "the code is quite good to analyze, extend or replace" But how do you even know what code to read when so much of the program's logic is in annotations and other kinds of action at a distance?
    - tannhaeuser 8y ago

BozeWolf 8y ago

Haha! Funny man! I am only doing javascript occasionly. Most of my time i do python and swift. Even stuff in “core” dependencies like webpack/yarn/npm/npx/nvm/babel changes a few times a year. Right now doing a react native app and a browser extension. While javascript/typescript is fun to write, the time you have to spend fixing the tools is just horrible. Whiping cache, rebooting, switching package versions.. It makes the overall experience cumbersome. I would not call something stable if it manages to work 2 whole years.

sourcesmith 8y ago

Bad decisions can be made using any technology. Java has a lot of crufty legacy APIs because, well it has a legacy. I gave up using JSPs years ago for Freemarker. I now use Vert.x rather than servlet contains which gives me a node.js environment but with access to the Java ecosystems and basic things like mature logging frameworks, as well as more advanced features (oh and multithreading in a single process). Despite Spring being Enterprise it still scales down to simpler apps pretty well due to its modularity. These can be build into a single jar app that is easy to build and deploy, and combined with a database migration library, maintain their own database schemas. Very, very usable. Yes, I probably would not use Java on the frontend unless it was for a technical audience.

lmm 8y ago

> On the server-side, customers use mostly Spring/Spring Boot these days to make Java's overengineered stack usable, using even more over-engineering and metaprogramming. There was definitely an era of that, but over the past decade or so it's been acknowledged as a problem, and there's been a lot of effort put into making things simpler and more vanilla. Modern Spring is much much closer to plain old code. (Of course it's still possible to write in the XML/setter injection/afterPropertiesSet style, and always will be - that's backward compatibility for you - but it's very possible to migrate existing applications to a better style in place, which very few platforms manage). > Same with maven/gradle, which turns what should be a developer-focussed build system into an enterprise XML mess. Maven is pretty close to the perfect build system, it's just taken a while for knowledge and practices to catch up with it. All the stuff people love and praise Cargo for, Maven has been doing for 15+ years.

tannhaeuser 8y ago
The basics of maven might be sound (though it could make it easier to work with local dependencies) and npm et al have basically copied it. Where maven dropped the ball is the myriad of maven plugin magic, maven's implicit lifecyle, and a pom.xml's Turing pits, etc. I've developed Java apps since almost the beginning, and am as much of a markup geek as could be, but still hate maven with a passion, and often times do not understand what tf it wants from me. I just don't have the patience with wading through crap that 2003ish Java nerds thought would be a good idea. And increasingly, as Java libs get EOLd, this will be a major problem for monolithic Java apps with tens of submodules. I don't think you can expect younger devs to keep maintaining daddy-o's web framework crap and cleanup the mess left by Java heads. However, I don't want to sound too negative. I can see a perspective for the JVM (Graal/Truffle) as a polyglot runtime where most of the ancient Java stuff is hidden from you, and you're using JavaScript or other non-JVM-only language as a migration strategy to get rid of Java alltogether in the distant future.
- lmm 8y ago
  > Where maven dropped the ball is the myriad of maven plugin magic, maven's implicit lifecyle, and a pom.xml's Turing pits, etc. Could you be a bit more concrete? I don't recognize any of your descriptions in my experience of maven. There are probably some bad plugins out there, but as in any system the solution is not to use them. The complete lifecycle is listed in the documentation, and it's all very common-sense. pom.xml isn't meant to be Turing-complete, and if you try to use it like a Turing-complete build language you will get yourself in trouble (as many of the early Ant diehards did). You need to treat it as a declarative config file, no different from e.g. Cargo.toml. > I just don't have the patience with wading through crap that 2003ish Java nerds thought would be a good idea. And increasingly, as Java libs get EOLd, this will be a major problem for monolithic Java apps with tens of submodules. I don't think you can expect younger devs to keep maintaining daddy-o's web framework crap and cleanup the mess left by Java heads. It's just the opposite. I don't expect anyone to want to maintain Ant or Gradle builds in the future, since they can have any kind of crap in them. But Maven builds are forced to be kept sensible; the tool just isn't flexible enough to let you put crap in your build definition, by design. (If you really insist on doing crap you can make a crappy plugin, but your plugin is then forced to be versioned, tagged in VCS etc., so stands a better chance of being picked up by your organisation's normal code quality efforts).

provolone 8y ago

Spring and other frameworks may be popular, but the base servlet api with db connection pooling is enough. This approach feels much lighter than using frameworks. Not sure where the 'over-engineered' view comes from. I'd call that 'sane'. People complain about the verbosity of Java, but how much time do you spend learning a new framework and all of the gotchas? At the end of the day it seems easier to just write the boilerplate. All of that verbose code means you got exactly what you asked for. JVM projects never surprise me. When there is a problem debugging is a dream.

coldtea 8y ago
>Spring and other frameworks may be popular, but the base servlet api with db connection pooling is enough. This approach feels much lighter than using frameworks. That. I've used the Servlets API for years in the early to late 00s. I'm now (for the past 5 years) using Express with Node. Static typing and cosmetic differences aside, Servlets and Express (or Node's raw handlers) are pretty much the same API. Request, Response objects, handlers, middleware (iirc we used to call those last "filters" in the Servlet era), etc. It's not like it's some alien convoluted design. (Java Server Faces now was another thing)

apta 8y ago

> On the server-side, customers use mostly Spring/Spring Boot these days to make Java's overengineered stack usable, using even more over-engineering and metaprogramming. Could you elaborate on the overengineering part? There are many modern frameworks that are much lighterweight than Spring/Spring Boot, and with the introduction of lambdas in Java, things are even more straightforward. Also, gradle doesn't use XML.