5 ms·

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

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
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
- 2trill2spill 8y 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.
  - ilaksh 8y ago
    https://docs.npmjs.com/files/package-locks https://docs.npmjs.com/files/package-locks has been the default for awhile. Are you using a pretty old version?
    - LoSboccacc 8y ago
      > It is highly recommended you commit the generated package lock to source control Fixed the Javascript way, layers of workarounds. And if you indeed need to update a dependency, you need to regenerate the lock. But the main difference is that when that happens, the onus to verify all packages transitive unpinned dependencies still result in a working combination (of which there is no guarantee) is on the receiving developer, not on the package maintainer.
      - frankwallis 8y ago
        This is untrue. If you need to update one dependency; npm/yarn will update the lockfile with the minimal changes needed to update that one dependency. You do not need to regenerate the entire lockfile.
untog 8y 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.
2trill2spill 8y 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 8y ago
  Hahaha <3
reggieband 8y 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.
- acemarke 8y 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 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 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/issues/429 https://github.com/zalmoxisus/redux-devtools-extension/issue...
  - semireg 8y ago
    I’m an experienced native app dev (swift/kotlin). I learned react/redux in a few months. For me, stressing immutability via Immutable.js/flow would go a long way. The combination is terrific but I had to piece together my own best practice.
    - acemarke 8y ago
      I personally generally discourage use of Immutable.js, for several reasons: https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abramov_redux_is_not_an_architecture_or/d51g4k4?context=3 https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abra... . However, the "starter kit" I linked does use the Immer library internally, which uses ES6 Proxies to let you write "mutative" code, but then applies the updates immutably. The goal here is to simplify your immutable update logic. (My only concern with using it is that there's no obvious indication in your own code that a given reducer function is updating immutably, because the code as-is really _is_ mutative, and that might confuse people down the road. Still, hopefully it will be beneficial in the long run.)
realusername 8y 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 8y 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.
  - foepys 8y ago
    Wasn't Kotlin introduced because Android was still stuck in Java 6? IntelliJ is running on JRE9 (a more or less LTE version they package with their installer) currently, afaik, while Android supports Java 7 and only some Java 8 features.
    - shemnon42 8y ago
      Kotlin being used by Android was very much after the fact. In fact the first few public releases had a bug that made it unusable on Android.
chrisco255 8y 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?
ilaksh 8y ago
I agree, React is overcomplicated for most things. But there are quite a few other options.

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

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

2trill2spill 8y 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.
- ilaksh 8y ago
  https://docs.npmjs.com/files/package-locks https://docs.npmjs.com/files/package-locks has been the default for awhile. Are you using a pretty old version?
  - LoSboccacc 8y ago
    > It is highly recommended you commit the generated package lock to source control Fixed the Javascript way, layers of workarounds. And if you indeed need to update a dependency, you need to regenerate the lock. But the main difference is that when that happens, the onus to verify all packages transitive unpinned dependencies still result in a working combination (of which there is no guarantee) is on the receiving developer, not on the package maintainer.
    - frankwallis 8y ago
      This is untrue. If you need to update one dependency; npm/yarn will update the lockfile with the minimal changes needed to update that one dependency. You do not need to regenerate the entire lockfile.

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

2trill2spill 8y 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 8y ago
Hahaha <3

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

acemarke 8y 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 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 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/issues/429 https://github.com/zalmoxisus/redux-devtools-extension/issue...
- semireg 8y ago
  I’m an experienced native app dev (swift/kotlin). I learned react/redux in a few months. For me, stressing immutability via Immutable.js/flow would go a long way. The combination is terrific but I had to piece together my own best practice.
  - acemarke 8y ago
    I personally generally discourage use of Immutable.js, for several reasons: https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abramov_redux_is_not_an_architecture_or/d51g4k4?context=3 https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abra... . However, the "starter kit" I linked does use the Immer library internally, which uses ES6 Proxies to let you write "mutative" code, but then applies the updates immutably. The goal here is to simplify your immutable update logic. (My only concern with using it is that there's no obvious indication in your own code that a given reducer function is updating immutably, because the code as-is really _is_ mutative, and that might confuse people down the road. Still, hopefully it will be beneficial in the long run.)

realusername 8y 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 8y 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.
- foepys 8y ago
  Wasn't Kotlin introduced because Android was still stuck in Java 6? IntelliJ is running on JRE9 (a more or less LTE version they package with their installer) currently, afaik, while Android supports Java 7 and only some Java 8 features.
  - shemnon42 8y ago
    Kotlin being used by Android was very much after the fact. In fact the first few public releases had a bug that made it unusable on Android.

chrisco255 8y 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?

ilaksh 8y ago

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