
Why is a Java guy so excited about Node.js and JavaScript? - daftpanda
https://blog.sourcerer.io/why-is-a-java-guy-so-excited-about-node-js-and-javascript-7cfc423efb44
======
sonnyblarney
It's not Java, it's the java culture.

Yes, Maven and Gradle are weirdly complex, but they are workable. And .jar
files are just downright amazing compared to most other things (I'm looking at
you madman Python dependencies!)

Hint: maybe you could come up with something like npm for Java ? Maybe it's
waiting to happen?

And Javadocs are mundane but still better than 'nodocs' which is the standard
on Node.js which really needs to change, and could start with some
standardization and leadership from somewhere ... maybe the Typescript team?

Oh, and also, since everything is JSON, and that blends nicely with JS ... my
god man that's so much nicer than JSON/XML in Java which is often unwiedy.

~~~
mkozlows
It's not just Java culture, though, it's also Java. For instance, you can't
have "npm for Java," because that's not how Java works at a very fundamental
level. Java gets gigantic monolithic framework libraries because Java's class
loader works fundamentally differently from Node's CommonJS module system.

~~~
sonnyblarney
Wha? I don't think so. An npm-like framework could work for Java. The
difference between classloading and node.js 'require' module loader is not
super relevant.

Frankly - the reason that Maven and Gradle are more sophisticated is because
many Java projects are _massive_ compared to most JS projects, the amount of
complexity, various kinds of packaging, testing etc. necessitates some
inherent complexity in modules. Java modules tend to be a lot bigger as well.

Again I think it's a cultural issue.

~~~
bodas
npm works because you can have lodash v3 and lodash v4 existing at the same
time, at runtime. Node sees two pieces of code at different locations on disk,
and loads them twice, considering them to have no relationship.

This means that a library can turn its API completely inside out and not cause
dependency hell. Your dependencies can update their sub-dependencies in their
own time. This means there's no pressures against releasing new updates, and
leads to the beautiful and very productive chaos that is npm.

Java is not designed to work this way.

~~~
RandyRanderson
> "you can have ... v3 and ... v4 existing at the same time, at runtime"

That's exactly what Java ClassLoaders do...

------
setr
Isn’t this just what occurs when you move beyond a single language? I wouldn’t
say he discovered how much better nodejs was over java, so much as he
discovered that java isn’t _the only way to do things_ ; he would have
probably had a similar epiphany with go, rust, smalltalk, clojure, haskell or
pretty much any other not-java language.

Imo this more an argument towards expanding beyond a single
language/ecosystem; hopefully the author doesn’t make the same mistake with
nodejs, nestling in and never moving beyond it for 10 years until finally
realizing there might just be _another way_

------
noicebrewery
I don't really care what this guys credentials are; he claims npm and yarn are
better than maven and gradle but doesn't bother explaining why (and it's
evident he hasn't used gradle)

Nor has he moved beyond a Java 6 mindset considering the things he complains
about in terms of modularity, verbosity and even strict type checking.

The fact that he thinks that the IDE race is between Eclipse and _Netbeans_ is
telling.

As far as boilerplate and unneeded code goes, he is correct. Spring, Hibernate
and Spring Boot removes code, and results in some arcane problems that you
shouldn't need to learn about. Now, let's discuss the React ecosystem: explain
to me the purity of intent behind an application that requires: \- action
classes/files \- reducer classes/files \- possibly route classes/files \- a
"store" \- a component to set a variable, complete with the half dozen
packages required to enable this behaviour. Not everyone has to do this, but
when creating a React application with the kind of scope that a Java
application often requires, this is an inevitably, and a LOT of work for a
supposedly simple task. If there is an error, you are similarly going through
a stack trace of weird abstract classes, except they are in a bundle file
which is equally impossible to parse.

~~~
abhisuri97
Being nitpicky here: you mention this somewhat in your comment, but I just
want to stress that redux is absolutely not necessary to your react
application (though a lot of beginners think it is a "must know" because every
blog article says you need to know it). React in and of itself allows you to
achieve the same functionality of redux (and a fairly complex app) without the
need for a bunch of boilerplate code. Of course, if you deeply understand
redux and its purpose, it can make creating large apps less of a hassle, but
there's nothing in react that says you must use redux to make a complex app.

~~~
bromuro
Indeed, we’ve built pretty big and solid apps without redux (when it did not
even exist). After that we investigate “flux” and eventually we decided to
adopt redux, that was easy for new hires.

------
jhowell
One number: 2009. The author hasn't worked with Java since Tiger Woods won a
major.

~~~
andreleite77
From the fifth paragraph:

> It’s not like I’ve completely divorced myself of Java. I have written a
> significant amount of Java/Spring/Hibernate code in the last 3 years (...) I
> worked in the Solar Industry doing deeply soul-fulfilling things like
> writing database queries about kiloWatt-hours

------
zmmmmm
This person definitely needs to try out some JVM languages like Scala, Kotlin
or Groovy. They solve nearly everything he talks about while keeping the good
parts of the JVM ecosystem and avoiding a lot of the bad parts of NodeJS.

~~~
galaxyLogic
For a long time I worked with Java and tried to make the move to Groovy since
I could appreciate what I read about it, having a background in Smalltalk. But
somehow using Java for some large projects just seemed more straightforward
and safe, because of type-checking which supports large-scale refactorings.

But since I moved to mainly work on Node.js I feel that Node.js is what Groovy
should have been. A simple but actually powerful language since EcmaScript
version 6.

And open.JavaScript feels open because, JavaScript is everywhere, both on the
client and now with Node.js on the server too. Everybody knows it. It can not
be called "niche language", like Groovy perhaps could. There is safety in
numbers.

What I'm looking forward to is Node.js running on GraalVM. That should make it
easy to call Java libraries from within Node.js. Use JavaScript as "glue for
Java" like it was originally intended.

[https://www.graalvm.org/docs/reference-
manual/languages/js/](https://www.graalvm.org/docs/reference-
manual/languages/js/)

~~~
zmmmmm
I agree with you about ES6 - very much in many ways it's captured the best of
the syntax from languages like groovy without relaxing so much that things
become ambiguous etc.

Nonetheless, I find JavaScript still simply isn't structured enough and
doesn't have the ability to tap into the underlying strengths of the JVM
ecosystem. Static compilation has improved enormously incidentally, which to
me means I almost never drop into Java any more where I used to code 50/50 in
Groovy / Java.

Mind you, if all you want is ES6 on the JVM, you already have a pretty good
subset of it in Nashorn / JDK9. I don't know how well it can use Node
libraries though ...

------
suyash
Seems like this guy has not touched Java for the last 10 years, this Java 10
is much more modern and there are many robust and light weight frameworks now
that make web development (Java EE) a breeze. You can even write Node.JS code
within Java using Graal VM.

------
lxe
I expected (2012) after the article's title. This type of hype about Node and
JS is long gone I'm afraid.

~~~
sidstling
I’m not so sure about that. I see node getting more and more traction these
days. In 2012 it was a hipster tech, in 2018 it’s actually starting to see its
way into production. At least around here, my own place included.

We’re a .net shop, like half the country I live in, but I could’ve written a
somewhat similar story as the author. Not exactly similar, I don’t think NPM
is really better than maven or nuget and coming from .net, the IDEs for JS are
certainly weaker than they are for .Net.

The reason we’re doing more and more JS, and using node, is because of how
fast it produces stuff that works.

It’s simply faster to write the same functionality with JS and node than it is
in .net, and it gives us the advantage of only using one language for back-
end, front-end and mobile. Which is extremely useful for a small team in an
enterprise setup.

It also works everywhere. We’re a .net shop like I said, that means we run on
IIS, which can be done with other techs than .net through stuff like fastcgi,
but have you ever tried setting that up and keeping it up-to-date? I have, and
really showed me how little of an operations guy I am because it was horrible.
IIS-node on the other hand worked out the box.

It’s a little ironic, but it’s now easier for us to deploy Node apps than .net
apps because .net apps often need different configuration on the IIS than it
does on your development box and Node works exactly the same.

It’s mostly the easy, fast part that does it for us though, and not so much
the language or node itself. We’re simply more productive when we’re using
Node.

Of course you need a lot of governance with the JS stack, but you honestly
need that for any tech, and we already had pretty strict rules in place for
how we write things in .net.

Disclaimer, it’s entirely possible that we are not as good at .net as we
think. It’s also possible that I’m noticing Node in more places than I did in
2012, or 2016 for that matter, places because I’m more focused on it now that
we use it in production. Node is a rising trend throughout my network though,
with more and more people picking it up for stuff that isn’t just weekend
projects.

~~~
oaiey
.NET Core took a lot of ideas from the node platform. Have you tried this?

~~~
sidstling
We have, I haven’t personally done any of it in production because I didn’t
really see a reason to use it over node. My coworkers did a few pocs though,
and initially had to spend a lot of time actually getting it to work with
deployment. I have no idea why that was, you’d expect it to just work
considering it’s a complete Microsoft setup, but it didn’t work out.

So it was a terribly expensive poc, because our most expensive resource is the
time developers/operations spend. I mean, core is more performant than node
technically, but as far as cost-efficiency goes, time to market is just much
more important than technical performance in our organization. We have a lot
of iron, and we don’t have a lot of users. We’re a muniplacity of average size
after all, the most simultaneous visitors we’ve ever had across every system
we operate is in the tens of thousands.

As far as development goes, I don’t think there is much difference between
core and standard, but I’ll admit that I haven’t looked into it since 1.0.

We’re in this weird spot where we’re using more and more powershell and azure
orchestration for back-end services that used to be powered by C#. A lot of
that has also moved from development to operations, so that development is
mainly focused on building APIs, working with data-sets or building various
minor web/mobile apps, and Node + JS is just working out better than
everything else.

We’ve tried core, we’ve tried Django and flask, we’ve tried a bunch of other
stuff, but for getting an app up and running the same hour you start building
it? Well, node just works for us.

I’m not saying node or JS are better than .Net though, I don’t think it is and
I’d still prefer Java or C# if I was building something major.

~~~
GFischer
I stayed away from Core because of the issues you mention, but it's gotten a
lot better recently.

Did a POC for an API that wouldn't break anything if it had to be reworked,
and it was a breeze.

Of course, if Node works for you, then it does :) but my recent experience is
that Core has gotten better and merits consideration.

------
d_burfoot
I develop a very complex, 500K+ LoC Java application. It implements a natural
language sentence parser that is integrated with a specialized lossless data
compressor. I use:

\- No IDE, just a simple text editor

\- No ORM, hand-written SQL code

\- My build tool is a Python script that marshals a javac call

\- I have just a few JAR file dependencies, which are checked into the repo

\- My own simple unit test and integration test framework

For me, Java Just Works. It's literally been years since I've encountered a
problem with the actual language. Yeah, there can be a lot of boilerplate.
Yeah, there are some issues with complex type manipulation. But those
limitations almost never cause me any real pain.

~~~
bborud
What made you create your own build tool rather than use Maven or Gradle?
Ditto for the unit tests; why does JUnit not fit you?

~~~
d_burfoot
I only introduce new dependencies into my system when I see them as strictly
necessary. I am _completely_ satisfied with my alternative implementations of
those components (this is in contrast to the IDE question, where I at least
see the benefit of tools like autocomplete that the IDE provides, but choose
not to use it because the benefit of simplicity is greater). Given the rage
and anger the OP directs against Maven, I think I am completely justified in
that choice.

~~~
bborud
I can understand where you are coming from, and I often follow a rather
similar approach where I will implement things myself if the alternative is
depending on some unwieldy beast of a dependency.

(I did write my own Servlet engine for a project once, and it was faster than
Jetty, and had better GC characteristics at the time, but in the end I ditched
it for Jetty as I didn't want to maintain a complete HTTP implementation -
that wasn't key to the project. The extra performance and the dependencies I
got rid of were just not worth the extra effort).

However the reason I always chose to use JUnit was because I wanted the unit
tests to be familiar to other developers since this is often where people go
to understand how a piece of code works. In a sense it was a part of Java at
the time. And I chose Maven for similar reasons. Plus the fact that Maven
wasn't something you could really escape from in Java. Sooner or later it
rears its head and I thought I would cause less pain if I just accepted that.

I like the idea behind Maven: convention over configuration, but I've never
been a fan of how that idea has been executed. It could have been better if
someone more experienced (and obsessive) had designed it way back when.

I still think Gradle is worse than Maven though. I'm not a fan of scriptable
build systems, they should be declarative (and most of the time when people
think they need to script things they just haven't bothered to learn how to
use the tools). And even if you use Gradle, you can't really escape dealing
with Maven.

(I ditched Java a couple of years back, so I haven't done Java for a while.
I'm not overly fond of Oracle, so I had promised myself that I would stop
using Java as soon as I found a replacement language that suited me. It took a
few years, but I eventually found a different language I liked even better:
Go)

------
bborud
My observation is that if you use Java mainly through large frameworks, you
won't mind as much switching to JavaScript. When using large frameworks, most
of your day is essentially spent doing what I think of as configuration work
-- making things fit together, rather than actual programming.

That's not a value judgement -- I'm just describing very different jobs.

If you are a configuration programmer then it really doesn't matter much what
language you use. In fact, the simple ergonomics of the tools for a given set
of tasks may be more important than the language itself.

------
uluyol
It is sounds like the author is more fed up with the Java ecosystem rather
than Java itself.

~~~
EdwardDiego
And a particular subset of it at that. Spring isn't the only choice, neither
is Hibernate, both of which I also loathe.

I'll admit, I prefer Kotlin to Java, but I find the JVM based ecosystem a joy.

~~~
jarym
Yep - once I got beyond 'EJBs' and other JavaEE stuff and eventually to Kotlin
life has been a joy. Maven can be bewildering but to me that's the price of
flexibility and I've learnt to deal with it.

I love JavaScript too - but for front-end stuff.

~~~
snuxoll
For all the complexity that you _can_ have with Maven, a large majority of
projects can get away with nothing but a <dependencies> section and maybe a
plugin or two. The one thing it does right that no other build tool I've used
has managed to reach is make projects adhere to a fairly rigorous standard,
once you understand the various phases to a maven build and the basics of a
POM you can pick up any project and get started fairly quickly.

------
cryptos
The author compares Spring and Java EE vs. Node.js. But these three things can
do very different things. It would be better to compare Node.js with something
like Reactor or RxJava and a reactive Web framework like WebFlux.

> Dahl’s experience was that using threads made for a heavyweight complex
> system. He sought something different, and spent a couple years honing and
> refining a set of core ideals arriving at Node.js. The result was a light-
> weight system, a single execution thread, an ingenious use of JavaScript
> anonymous functions for asynchronous callbacks, and a runtime library that
> ingeniously implemented asynchronicity.

He cured the symptom with an oversimplified solution. Having only one thread
per process is a severe limitation. It would have been better, to create good
APIs (like Reactor or Kotlin coroutines) or language-level solutions (like
Rust) to handle multi-threading.

> In Java. Listeners require creating a concrete instance of an abstract
> interface class.

That is no longer true, since event handlers can be defined as anonymous
functions since Java 8 (from 2014).

> Another learning: Most programming languages obscure the programmers intent,
> making it harder to understand the code.

The author mixes Java the language, Java the platform and
libraries/frameworks, so it is worth pointing out, that the Java ecosystem is
not limited to the Java language. Using Kotlin or Scala would remove his
reasons to complain.

> JavaScript, by contrast, has loosey-goosey typing. The theory is obvious:
> The programmer has no certainty what kind of object they’ve received, so how
> can the programmer know what to do?

You have to make certain assumptions to handle incoming data, but it would be
good for robustness and security to make these assumptions explicit. And,
really, converting a Json string into a Java object is a single line calling
Jackson and maybe a few annotations.

The section about modules could be applied to Java 9+ as well.

------
galaxyLogic
Obviously Java's type-checking compiler is a benefit for large projects. How
could JavaScript ever address its lack of that? Well JavaScript is a dynamic
language, it can check types at runtime. Combined with unit-testing that can
go a long way without requiring that "everything must always be type-checked".
For instance it makes sense to declare the types of public interfaces of a
class, maybe not so much every variable used in their implementation.

Cisf.js is one attempt at providing simple run-time assertions to serve the
purpose of (optional) dynamic type-checking.

[https://www.npmjs.com/package/cisf](https://www.npmjs.com/package/cisf)

------
donlebon
> Both Java and Node.js offer excellent performance, running counter to the
> myth that JavaScript is slow and therefore Node.js performance must be bad

> Node.js performance is riding the coattails of Google investment in V8 to
> speed up the Chrome browser

> The intense competition between browsers is making JavaScript more and more
> powerful every year, benefitting Node.js

Sounds ammmmazing! So JS is really damn fast and on a par with Java, right?
But wait, are there any numbers?

[https://www.techempower.com/benchmarks/#section=data-r16&hw=...](https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=fortune&l=hra073)

Ouch.

------
mindslight
I had thought about a stupid joke to answer the clickbait headline: "because
he just discovered it". Turns out, that's the actual post.

(ps stay away from any sort of lisp - right now you're only doing a gateway
drug)

------
Rumi34234
They're produced by the very best degree developers who will be distinguished
for your polo dress creating. You'll find polo Ron Lauren inside exclusive
array which include particular classes for men, women. <a
href='[http://whatdaytoday.com/national-chicken-wing-
day/'>National](http://whatdaytoday.com/national-chicken-wing-day/'>National)
Chicken Wing Day</a>

------
JackFr
Liked it better the first time when it was about Ruby on Rails.

------
shemnon42
> What’s it mean when you get a Hibernate PersistentObjectException about a
> “detached entity passed to persist”? That took several days to figure out —
> at the risk of oversimplification — it meant the JSON arriving at the REST
> endpoint had ID fields with values. Hibernate, oversimplying, wants control
> of the ID values, and throws this confusing exception.

I found your problem. You're using Hibernate.

------
partycoder
The problems of node.js are different: most packages have a high number of
dependencies, and some of those dependencies can be of low quality.

Another problem is that event loop is a leaky abstraction, and a majority of
developers do not know how to produce code that doesn't block it.

------
provolone
He spends a fair amount of time complaining about spring. I've never used
spring. I recognized it as bloat from the beginning.

The base servlet API + commons dbcp is good enough for me. If writing SQL
queries is too much to ask, then perhaps he shouldn't be writing webapps.

------
magwa101
Go

