21 ms·

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

87 points by daftpanda 8y ago

sonnyblarney 8y 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_a 8y 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.
  - abhisuri97 8y 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.
    - paulie_a 8y ago
      I honestly don't get why I was down voted but mkvirtualenv, workon xyz, pip install -r requirements.txt isn't exactly a huge barrier to entry with a python project. Personally I always saw the node_modules directory as something to be ignored. It's a crowded bunch of junk.
      - mythrwy 8y ago
        Fully agree. NPM is a complete three ring circus compared to pip and a requirements.txt file.
      - deleted 8y ago
        [deleted]
      - lostcolony 8y ago
        I admit I haven't used Python that much, but I'd say about 90% of the libraries and projects I had interest in didn't have a requirements.txt. I've used Node a LOT, and I have yet to have a library or project -not- have a package.json. I'll readily admit that Python has the -ability- to be a well maintained environment. THe fact it doesn't default and practically enforce it has led to a culture where it's not often used. And half the mindshare uses conda environments instead.
      - dagenix 8y ago
        I didn't downvote you. However, I do disagree with what you are saying. In Python, the absolute most trivial case, is already a big pain. In order to get a project started, you need to: 1) create a virtual environment (which you can do with virtualenv, python -m venv, virtualenvwrapper, pyenv-virtualenv, Pipenv, poetry, or, Conda - but lets ignore Conda from here on out). 2) next, you may need to activate the virtual environment - but, its easy to forget to do this or to activate the wrong one. And, depending on how you created the virtual environment, you have to do it differently. 3) once activated, you then need to install your dependencies - possibly using pip, or, maybe using Pipenv or poetry. 4) Depending on the type of project you are setting up, you may also need to create a setup.py file, otherwise you won't be able to install the new project you are working on into a virtual environment. 5) Then, you probably need to configure your IDE to use your virtual environment - depending on how you created it your IDE may pick it up automatically, but, it probably didn't. Then, you can get down to work. But, thats the easy case - the more painful case is when you want to either deploy your project or you want to update it. If you didn't use Pipenv or poetry, you're going to need to create a requirements file - probably with pip freeze. You can then go to a different virtual environment and do a pip install -r to install the requirements from that file. Of course, when developing your code, you may have installed modules like py.test that you don't want to install on your production system - but pip doesn't know the difference between a development and a runtime dependency, so, you either need to edit the requirements file generated by pip freeze by hand, or, just live with deploying code you don't want to to production. If you used Pipenv or poetry, at least then you can keep development and runtime dependencies separate. However, both of these tools are less available than pip, so, this generally means you have to install them on your production system - which, given that they are newer, tends to be awkward to do since it may involve pulling down code from github directly. Alternatively, you can do a pip freeze to create a requirements file, but, then you are back to pull in dependencies you may not want. The next thing you're going to want to do is to update some dependencies. If all you have is a requirements.txt file, well, you are pretty much out of luck. If it was created by pip freeze, its going to include all of your transitive dependencies - good luck remembering which ones you use directly and which ones you don't. Maybe you didn't use pip freeze to create it, however, and you created it by hand. Well, now you'll know which dependencies you actually are using, since, you only put those in the file - however, the problem then becomes that since you didn't list your transitive dependencies, whenever you install the requirements, you could get a different set of transitive dependencies - and if you accidentally started using one of them without realizing it, this could break your production system. So, maybe you listed all of your dependencies in your setup.py file - if so, you can always delete your virtual environment, reinstall everything from your setup.py file, and then re-generate your requirements file. However, doing that is a massive, massive pain since it involves a number of commands. If you try to do this, odds are that your setup.py and your requirements files start to fall out of sync and you give up on one or the other of them. Pipenv helps - a bit. Its more of a replacement for the requirements file than for the setup.py file - which leads to the odd problem of not knowing if you should list your requirements in both places or try to have one include the other. Whats made more fun, is that Pipenv's interface includes a bunch of options that don't make much sense (pipenv install includes the options "--selective-upgrade", "--keep-outdated", "--skip-lock", and "--ignore-pipfile" and its not really all that clear what they are supposed to do). What I'd like to be able to do is to either update either a single dependency OR update them all, at my discretion. I assume that some combination or its arcane options are supposed to allow you to update a single dependency without updating all of them - however, if so, its not clear which one is supposed to do that as it seems like both "--selective-upgrade" and "--keep-outdated" might do that. However, worse than not knowing what option you should use, it seems like neither of them actually does work: https://github.com/pypa/pipenv/issues/966 https://github.com/pypa/pipenv/issues/966 has been open for a while and has been dismissed by the maintainers as not a problem, then "fixed", then acknowledged that it didn't actually work, and then they went dark. So, as it stands, if you try to update any dependency, Pipenv is probably going to insist on updating everything - so, have fun testing that. Poetry is probably the strongest contender for making this whole mess sane. But, for reasons that seem to completely defy logic, Pipenv is getting most of the attention in this space. It appears to be mostly a one person project - and so tying a project to it feels risky. Despite all that, it does work pretty well, but, there are still a lot of features that would be great to see and it would be really great to see it get some more attention and manpower.
    - jjjensen90 8y ago
      Just so you know, 95% of the few hundred Java devs I've worked with in the last few years used maven or gradle on the command line to handle packages, including junior developers. I think the Java = IDE concept is outdated (although IntelliJ IDEA is an amazingly well-integrated IDE with Java).
- mkozlows 8y 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.
  - hyperpallium 8y ago
    Please elaborate.
  - sonnyblarney 8y 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.
    - bodas 8y ago
      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 8y ago
        > "you can have ... v3 and ... v4 existing at the same time, at runtime" That's exactly what Java ClassLoaders do...
      - step21 8y ago
- ilaksh 8y 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_eh 8y ago
    And increasingly type definitions too.
- bborud 8y 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.
  - bborud 8y 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.
- sametmax 8y 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.
  - passiveincomelg 8y ago
    Unless C libraries are involved. Which is almost always the case.
    - sametmax 8y ago
      First, no it's not. I just checked. 1 out of 12 projects on my laptop have c dependancies. Second, wheels allow installing c dep tranparently now. And the top 20 c dep have wheels for windows, mac and most linux.
      - passiveincomelg 8y ago
        You are right, "almost always the case" was a baseless claim and binary wheels are better than nothing. However, how many projects still have "psycopg2" in their setup.py (or is it requirements.txt? ;) instead of "psycopg2-binary"? I just found out that the latter exists when I checked PyPI.
        sametmax 8y ago
        I'm not pretending all is fine in the kingdom. But a lot of big Python issues (2 vs 3, encoding, deps) are a in a fantastic state compared to years ago and I think it's important that people don't stay stuck on a bad impression from past mistakes. It's also for me a way to acknowledge the huge work the community has been putting into fixing what's been asked.
  - sonnyblarney 8y 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.
uluyol 8y ago
It is sounds like the author is more fed up with the Java ecosystem rather than Java itself.
- EdwardDiego 8y 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 8y 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.
    - snuxoll 8y ago
      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.
- p2t2p 8y 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 8y 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
noicebrewery 8y 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.
- abhisuri97 8y 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 8y 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.
- LoSboccacc 8y ago
jhowell 8y ago
One number: 2009. The author hasn't worked with Java since Tiger Woods won a major.
- suyash 8y ago
  Exactly he lost all credibility about speaking on current state of Java right there.
- andreleite77 8y 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
zmmmmm 8y 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 8y 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 8y ago
  No love for Clojure? I know many people that swear by it.
  - zmmmmm 8y 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.
  - cryptos 8y 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.
- galaxyLogic 8y 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/ https://www.graalvm.org/docs/reference-manual/languages/js/
knodi 8y ago
why he hates him self.
lxe 8y ago
I expected (2012) after the article's title. This type of hype about Node and JS is long gone I'm afraid.
- chrisco255 8y ago
  The hype may have subsided, but its usage has not: http://blog.builtinnode.com/post/node-js-will-overtake-java-within-a-year-analysis http://blog.builtinnode.com/post/node-js-will-overtake-java-...
- wvenable 8y ago
  If anyone thinks nodejs is less complex than Java hasn't looked in their node_modules folder lately.
  - SebastianM 8y ago
    Then you haven't looked into your JARs :)
- sidstling 8y 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.
mindslight 8y 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 8y 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.
suyash 8y 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.
galaxyLogic 8y 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 https://www.npmjs.com/package/cisf
- simooooo 8y ago
  Your point doesn't make sense... you talk about the weakness of not being type checked, then say it's ok because that happens at runtime?
shemnon42 8y 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 8y 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 8y ago
Liked it better the first time when it was about Ruby on Rails.
d_burfoot 8y 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 8y 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).
- bborud 8y 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 8y 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_burfoot 8y 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.
bborud 8y 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.
Rumi34234 8y ago
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>
cryptos 8y 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 8y 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=ph&test=fortune&l=hra073 https://www.techempower.com/benchmarks/#section=data-r16&hw=... Ouch.
magwa101 8y ago
Go
mizchief2 8y ago
Its coming to the realization of how much time you spend in Java just making sure that a string is really a string

87 points by daftpanda 8y 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_a 8y 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.
- abhisuri97 8y 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.
  - paulie_a 8y ago
    I honestly don't get why I was down voted but mkvirtualenv, workon xyz, pip install -r requirements.txt isn't exactly a huge barrier to entry with a python project. Personally I always saw the node_modules directory as something to be ignored. It's a crowded bunch of junk.
    - mythrwy 8y ago
      Fully agree. NPM is a complete three ring circus compared to pip and a requirements.txt file.
    - deleted 8y ago
      [deleted]
    - lostcolony 8y ago
      I admit I haven't used Python that much, but I'd say about 90% of the libraries and projects I had interest in didn't have a requirements.txt. I've used Node a LOT, and I have yet to have a library or project -not- have a package.json. I'll readily admit that Python has the -ability- to be a well maintained environment. THe fact it doesn't default and practically enforce it has led to a culture where it's not often used. And half the mindshare uses conda environments instead.
    - dagenix 8y ago
      I didn't downvote you. However, I do disagree with what you are saying. In Python, the absolute most trivial case, is already a big pain. In order to get a project started, you need to: 1) create a virtual environment (which you can do with virtualenv, python -m venv, virtualenvwrapper, pyenv-virtualenv, Pipenv, poetry, or, Conda - but lets ignore Conda from here on out). 2) next, you may need to activate the virtual environment - but, its easy to forget to do this or to activate the wrong one. And, depending on how you created the virtual environment, you have to do it differently. 3) once activated, you then need to install your dependencies - possibly using pip, or, maybe using Pipenv or poetry. 4) Depending on the type of project you are setting up, you may also need to create a setup.py file, otherwise you won't be able to install the new project you are working on into a virtual environment. 5) Then, you probably need to configure your IDE to use your virtual environment - depending on how you created it your IDE may pick it up automatically, but, it probably didn't. Then, you can get down to work. But, thats the easy case - the more painful case is when you want to either deploy your project or you want to update it. If you didn't use Pipenv or poetry, you're going to need to create a requirements file - probably with pip freeze. You can then go to a different virtual environment and do a pip install -r to install the requirements from that file. Of course, when developing your code, you may have installed modules like py.test that you don't want to install on your production system - but pip doesn't know the difference between a development and a runtime dependency, so, you either need to edit the requirements file generated by pip freeze by hand, or, just live with deploying code you don't want to to production. If you used Pipenv or poetry, at least then you can keep development and runtime dependencies separate. However, both of these tools are less available than pip, so, this generally means you have to install them on your production system - which, given that they are newer, tends to be awkward to do since it may involve pulling down code from github directly. Alternatively, you can do a pip freeze to create a requirements file, but, then you are back to pull in dependencies you may not want. The next thing you're going to want to do is to update some dependencies. If all you have is a requirements.txt file, well, you are pretty much out of luck. If it was created by pip freeze, its going to include all of your transitive dependencies - good luck remembering which ones you use directly and which ones you don't. Maybe you didn't use pip freeze to create it, however, and you created it by hand. Well, now you'll know which dependencies you actually are using, since, you only put those in the file - however, the problem then becomes that since you didn't list your transitive dependencies, whenever you install the requirements, you could get a different set of transitive dependencies - and if you accidentally started using one of them without realizing it, this could break your production system. So, maybe you listed all of your dependencies in your setup.py file - if so, you can always delete your virtual environment, reinstall everything from your setup.py file, and then re-generate your requirements file. However, doing that is a massive, massive pain since it involves a number of commands. If you try to do this, odds are that your setup.py and your requirements files start to fall out of sync and you give up on one or the other of them. Pipenv helps - a bit. Its more of a replacement for the requirements file than for the setup.py file - which leads to the odd problem of not knowing if you should list your requirements in both places or try to have one include the other. Whats made more fun, is that Pipenv's interface includes a bunch of options that don't make much sense (pipenv install includes the options "--selective-upgrade", "--keep-outdated", "--skip-lock", and "--ignore-pipfile" and its not really all that clear what they are supposed to do). What I'd like to be able to do is to either update either a single dependency OR update them all, at my discretion. I assume that some combination or its arcane options are supposed to allow you to update a single dependency without updating all of them - however, if so, its not clear which one is supposed to do that as it seems like both "--selective-upgrade" and "--keep-outdated" might do that. However, worse than not knowing what option you should use, it seems like neither of them actually does work: https://github.com/pypa/pipenv/issues/966 https://github.com/pypa/pipenv/issues/966 has been open for a while and has been dismissed by the maintainers as not a problem, then "fixed", then acknowledged that it didn't actually work, and then they went dark. So, as it stands, if you try to update any dependency, Pipenv is probably going to insist on updating everything - so, have fun testing that. Poetry is probably the strongest contender for making this whole mess sane. But, for reasons that seem to completely defy logic, Pipenv is getting most of the attention in this space. It appears to be mostly a one person project - and so tying a project to it feels risky. Despite all that, it does work pretty well, but, there are still a lot of features that would be great to see and it would be really great to see it get some more attention and manpower.
  - jjjensen90 8y ago
    Just so you know, 95% of the few hundred Java devs I've worked with in the last few years used maven or gradle on the command line to handle packages, including junior developers. I think the Java = IDE concept is outdated (although IntelliJ IDEA is an amazingly well-integrated IDE with Java).
mkozlows 8y 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.
- hyperpallium 8y ago
  Please elaborate.
- sonnyblarney 8y 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.
  - bodas 8y ago
    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 8y ago
      > "you can have ... v3 and ... v4 existing at the same time, at runtime" That's exactly what Java ClassLoaders do...
    - step21 8y ago
ilaksh 8y 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_eh 8y ago
  And increasingly type definitions too.
bborud 8y 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.
- bborud 8y 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.
sametmax 8y 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.
- passiveincomelg 8y ago
  Unless C libraries are involved. Which is almost always the case.
  - sametmax 8y ago
    First, no it's not. I just checked. 1 out of 12 projects on my laptop have c dependancies. Second, wheels allow installing c dep tranparently now. And the top 20 c dep have wheels for windows, mac and most linux.
    - passiveincomelg 8y ago
      You are right, "almost always the case" was a baseless claim and binary wheels are better than nothing. However, how many projects still have "psycopg2" in their setup.py (or is it requirements.txt? ;) instead of "psycopg2-binary"? I just found out that the latter exists when I checked PyPI.
      - sametmax 8y ago
        I'm not pretending all is fine in the kingdom. But a lot of big Python issues (2 vs 3, encoding, deps) are a in a fantastic state compared to years ago and I think it's important that people don't stay stuck on a bad impression from past mistakes. It's also for me a way to acknowledge the huge work the community has been putting into fixing what's been asked.
- sonnyblarney 8y 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.

uluyol 8y ago

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

EdwardDiego 8y 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 8y 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.
  - snuxoll 8y ago
    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.
p2t2p 8y 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 8y 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

noicebrewery 8y 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.

abhisuri97 8y 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 8y 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.
LoSboccacc 8y ago

jhowell 8y ago

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

suyash 8y ago
Exactly he lost all credibility about speaking on current state of Java right there.
andreleite77 8y 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

zmmmmm 8y 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 8y 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 8y ago
No love for Clojure? I know many people that swear by it.
- zmmmmm 8y 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.
- cryptos 8y 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.
galaxyLogic 8y 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/ https://www.graalvm.org/docs/reference-manual/languages/js/

knodi 8y ago

why he hates him self.

lxe 8y ago

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

chrisco255 8y ago
The hype may have subsided, but its usage has not: http://blog.builtinnode.com/post/node-js-will-overtake-java-within-a-year-analysis http://blog.builtinnode.com/post/node-js-will-overtake-java-...
wvenable 8y ago
If anyone thinks nodejs is less complex than Java hasn't looked in their node_modules folder lately.
- SebastianM 8y ago
  Then you haven't looked into your JARs :)
sidstling 8y 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.

mindslight 8y 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 8y 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.

suyash 8y 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.

galaxyLogic 8y 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 https://www.npmjs.com/package/cisf

simooooo 8y ago
Your point doesn't make sense... you talk about the weakness of not being type checked, then say it's ok because that happens at runtime?

shemnon42 8y 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 8y 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 8y ago

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

d_burfoot 8y 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 8y 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).
bborud 8y 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 8y 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_burfoot 8y 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.

bborud 8y 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.

Rumi34234 8y ago

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>

cryptos 8y 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 8y 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=ph&test=fortune&l=hra073 https://www.techempower.com/benchmarks/#section=data-r16&hw=... Ouch.

magwa101 8y ago

mizchief2 8y ago

Its coming to the realization of how much time you spend in Java just making sure that a string is really a string