Comment by noicebrewery | Hacker News Reader

Comment by noicebrewery | Hacker News Reader

Parent Full thread

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.

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.

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.

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.

Hahaha <3

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

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

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.

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.

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.

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.

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

So on the off chance that anyone happens to look at this thread in the future: last night I decided to try implementing that stack trace display idea, and I got it working! Still needs better formatting, but the important thing is the data is there and viewable.

I made an alternative to Redux that requires a lot less boilerplate. Could you take a look? I'd love to know what a Redux contributor thinks.

https://github.com/JonAbrams/SpaceAce

Take a look at what, specifically? If you want him to invest his time helping your competing tool, then respect that time and direct him to specific places where his input might be appreciated.

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.

I personally generally discourage use of Immutable.js, for several reasons: 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.)

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

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.

https://docs.npmjs.com/files/package-locks has been the default for awhile. Are you using a pretty old version?

I'm well aware of package locks. However npm has a horrible implementation of package locking. Running npm install will regenerate your package lock unless you removed prefixs from all your packages or you install using --package-lock-only[1].

So my question to you is, have you been using npm package locks correctly? Or do you let npm install generate a new package lock every time its run?

[1]: https://stackoverflow.com/questions/45022048/why-does-npm-in...

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

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.

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?

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

Reply on news.ycombinator.com