Why is a Java guy so excited about Node.js and JavaScript?

https://blog.sourcerer.io/why-is-a-java-guy-so-excited-about-node-js-and-javascript-7cfc423efb44

by daftpanda • 8 years ago

87 109 8 years ago

blog.sourcerer.io

uluyol• 8 years ago

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

EdwardDiego• 8 years ago

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• 8 years ago

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.

p2t2p• 8 years ago

It sounds more like the author doesn't know shit about modern Java ecosystem. HTTP servers are embeddable and configured in 5 lines of code. Connection Pools work just fine with zero config 'cause they have sane defaults. Spring Boot allows you to have proper web-app by list couple dependencies and one line of code - the one that actually starts it. Tests work out of the box, sane distinction between integration tests and unit tests, plugins for docker and NPM so one command runs your unit tests, your integration tests, builds you docker images, runs databases, everything. Your CI is 'mvn clean verify' now, without arcane shit in bash.

Then those people come to me and say that I need to redefine "require" to be able to mock stuff (and don't forget to do it in the right order). No, thank you, I'd rather stick with my DI and write actually testable code.

Whenever I try to step away from Java I always am in trouble: - How do I mock stuff - oh, you simply hack the core mechanisms in $language - no thanks, we've moved on past that in Java. - How do I build stuff - well, simply write this bunch of supporting scripts in JS/bash/make whatever - no thank you, maven plugin ecosystem does it in declarative way with no support on my part. - How do I integrate it with IDE - well you can't because you've written a bunch of custom scripts to build stuff. - How do I package resources and dependencies - you build a docker image that has all of it (or zip file and freaking installation script) - thank you very much my jar files can do it just fine without my intervention.

Whenever I step away from Java ecosystem I feel like I'm back coding in freaking PHP.

setr• 8 years ago

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

sonnyblarney4• 8 years ago

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.

paulie_a7• 8 years ago

What's wrong with python dependcies? It's literally a small requirements file. If anything npm and js is the shit show for that.

abhisuri972• 8 years ago

I teach javascript to students coming from Java and Python and, while I do agree npm could be better, students find it to be so much more intuitive rather than have some IDE handle packages (in the case of java) or be stored somewhere in your system path with python. Being able to see the dependency within node_modules and make that connection between you saying "i want to install this" and it appears in your project file system makes a bunch of sense for beginners.

mkozlows• 8 years ago

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.

hyperpallium2• 8 years ago

Please elaborate.

sonnyblarney4• 8 years ago

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.

ilaksh3• 8 years ago

The standard for Node.js is highly modularized code where every module gets a README with examples and usually fairly comprehensive documentation.

If you mean that you think Javadocs format and type of details is ideal or ideal for JavaScript then please study JavaScript and Node.js more.

jonny_eh2• 8 years ago

And increasingly type definitions too.

bborud5• 8 years ago

It is a mystery to me why Python never managed to deal with the single biggest reason why it is unusable for serious software development.

bborud5• 8 years ago

I'm kind of sad that someone would downvote this without really asking why I might think Python isn't suitable for serious software development.

The main reason is that it isn't a language that is nice to users. It shifts the entire burden of setting up an environment to run the Python application in. Which means that installing software tends to be a messy affair at the best of times, and a complete mystery to most non-programmers.

The difference between a good professional software developer and someone who is a just hack, is empathy with the user. Having an obvious way to package applications allows developers to be nice to their users. Python never provided that, so rather than producing nice binaries (or something akin to Jar files) it just dumps the problem of assembling the bits in the user's lap. That's a dick move.

sametmax4• 8 years ago

Dependencies in python has evolved a lot in the last 2 years. You can use a simple setup.cfg to make them, and you can use a wheel like a jar if you want.

passiveincomelg2• 8 years ago

Unless C libraries are involved. Which is almost always the case.

sonnyblarney4• 8 years ago

Ok, so there's some new mechanisms?

That's not so much the issue - as Python package/dependency problems are not so much a problem of 'how it works' - it's an issue because nobody is on the same page. It's byzantine.

If python dependencies boiled down to 'point to a directory' well then fine, everything would work that way and we'd build tools around it, docs would be clear etc. etc..

But as someone who uses Python seldom and loves the syntax, I generally stay away from it mostly for that reason.

And lack of typing which is obviously another discussion.

noicebrewery• 8 years ago

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.

abhisuri972• 8 years ago

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• 8 years ago

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.

LoSboccacc2• 8 years ago

Seems to be stuck at 2000-2010 java. And hasn’t spent a whole lot of time with npm or tried to maintain a project for a significant time, wrestling the issues that the fluid npm ecosystem brings.

Maven gets a lot of flack for its rigidity but the fact that one can get a ten years old complex project and build it reliably today is simply amazing

2trill2spill3• 8 years ago

Exactly, I deal with npm on a daily basis and I really wish deterministic builds were more of a concern in the javascript/npm universe. I can't count how many times a project broke because a "minor" release came out and broke existing code. Also the majority of projects have a caret in their package.json package versions so you automatically get the updates.

untog• 8 years ago

I know it's not the main point but you're talking about Redux there, not React. I've worked with React for years without touching the stuff you're talking about.

2trill2spill3• 8 years ago

You say React but then complain about Redux. I get it I'm not a fan of Redux either, so why not direct your criticism to Redux instead of React? Also I would like to add that Redux is not needed to build a React app.

jimmeyotoole• 8 years ago

Hahaha <3

reggieband• 8 years ago

As someone who has to deal with Spring stack traces and React/Redux stack traces on a daily basis ... I'll take React/Redux 100% of the time.

There is a lot to complain about both but I think the Java boilerplate mess is at least one order of magnitude worse.

Just one man's opinion, anecdotal evidence, YMMV, etc.

acemarke3• 8 years ago

I'm a Redux maintainer. FWIW, I'm always open to suggestions on how we can make using Redux easier and better for everyone (example prior discussion: https://github.com/reactjs/redux/issues/2295 ).

We're currently working on a "starter kit" package that's intended to address some of the most common concerns about using Redux, and hope to make it an official Redux-branded package in the near future. I'd appreciate any feedback or ideas you have for improving it:

https://github.com/markerikson/redux-starter-kit

Also, since you mention stack traces: if anyone out there has a bit of free time on their hands, I'd _love_ to see the Redux DevTools core and extension updated to show a stack trace for where each action was dispatched:

https://github.com/zalmoxisus/redux-devtools-extension/issue...

realusername• 8 years ago

reducer classes/files - possibly route classes/files - a "store"

You don't need Redux for the majority of the apps.

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.

There's a reason people created Kotlin, there's clearly shortcomings in the Java language which did not move fast enough.

izacus• 8 years ago

There's a reason people created Kotlin, there's clearly shortcomings in the Java language which did not move fast enough.

Kotlin was created mainly because IntellJ couldn't move on from Java 6. It's a huge improvement, but you've just used the same type of mindset stuck at Java 6 that's being criticised.

chrisco2552• 8 years ago

If the goal of this article is to compare Node.js vs Java...then why are you bringing up React? Shouldn't the conversation be restricted to the backend? In that case, wouldn't you want to compare Express to Spring?

ilaksh3• 8 years ago

I agree, React is overcomplicated for most things. But there are quite a few other options.

jhowell• 8 years ago

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

suyash2• 8 years ago

Exactly he lost all credibility about speaking on current state of Java right there.

andreleite77• 8 years ago

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

zmmmmm3• 8 years ago

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.

gedy• 8 years ago

I can't speak for the author, but I did a similar shift around 2010 to Node.js and JavaScript from many years in the Java ecosystem. I did try Groovy and quite like(d) Scala before moving to JS, and while Scala at least was a big improvement at the language level, I eventually shifted further and further in Node.js because it simply was more productive and easier to make full stack webapps.

I can see developer's points if they are just "backend developers", but doing anything with a web UI is vastly superior experience and simpler in Node.js.

TheAceOfHearts• 8 years ago

No love for Clojure? I know many people that swear by it.

zmmmmm3• 8 years ago

Oh, for sure! I just mentioned the three that first came to mind (which is biased by the fact I personally use them). But yes, I know lots of people who love Clojure.

cryptos2• 8 years ago

I'm not saying that clojure is bad, but if you look at any language popularity index it is very rarely used in general.

galaxyLogic2• 8 years ago

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/

zmmmmm3• 8 years ago

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 ...

vorg• 8 years ago

Use JavaScript as "glue for Java" like it was originally intended.

Then we would have come full circle. JavaScript was originally intended as glue for Java applets, but applets never became popular. Instead, Java was used for standalone and server-side codebases, and Beanshell came along as glue code for those. Later, James Strachan added closures to Beanshell's basic functionality, and Apache Groovy was born. Afterwards, Scala became popular and showed that a statically-compiled language could be used dynamically as well, and Strachan said if he'd known about Scala at the time, he'd never have created Groovy. Later, Kotlin showed you could even have builders in statically-compiled code. Now Graal is finally enabling Javascript on the JVM, perhaps selling the idea to developers better than Rhino or Nashorn did.

javadocmd• 8 years ago

I went from Java to (dabbling in) Scala to TypeScript. While my heart is still with Scala, the ecosystem around Node is incredibly persuasive. The speed with which you can accomplish practical tasks, like building a desktop app with Electron, beats anything I've experienced in Javaland. (Of course that greatly depends on what kind of projects fill your time.) I think you could argue that the way Node hops domains -- web front-end, back-end, and desktop -- fulfills a broader version of Java's original vision: to be the cross-platform language.

lxe• 8 years ago

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

chrisco2552• 8 years ago

The hype may have subsided, but its usage has not: http://blog.builtinnode.com/post/node-js-will-overtake-java-...

wvenable• 8 years ago

If anyone thinks nodejs is less complex than Java hasn't looked in their node_modules folder lately.

SebastianM• 8 years ago

Then you haven't looked into your JARs :)

sidstling2• 8 years ago

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• 8 years ago

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

mindslight• 8 years ago

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)

partycoder• 8 years ago

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.

suyash2• 8 years ago

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.

galaxyLogic2• 8 years ago

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

shemnon422• 8 years ago

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.

provolone• 8 years ago

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.

JackFr• 8 years ago

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

d_burfoot2• 8 years ago

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.

wheresvic1• 8 years ago

Yours is a very niche case where you built an application that is perhaps used by other applications downstream.

The author's gripes are mostly with the day-to-day java web application development that is being done in large firms (which I could even believe is the majority of Java development work).

bborud5• 8 years ago

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?

bausshf• 8 years ago

A shot in the sky: The project might have started before those and/or he's in the mindset of reinventing the wheel instead of learning new tools

d_burfoot2• 8 years ago

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.

bborud5• 8 years ago

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.

cryptos2• 8 years ago

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.

donlebon• 8 years ago

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=...

Ouch.

magwa101• 8 years ago

Why is a Java guy so excited about Node.js and JavaScript?

Related Stories