Hacker News Reader

I think you're over simplifying the gradle solution though. I know when I did java in school, it was not easy. There was a fair bit of configuration. Getting glassfish or tomcat to work with eclipse was a challenge. Gradle has definitely helped this a lot, but you still need to know how to configure the gradle script if you need to change something.

You're right in that JS tools do need to get stronger, and over even the last 2-3 years they have. I haven't had mine "constantly breaking", generally once you build a new application and set it up with your standard dependencies. Like an ORM, what ever server middleware, test frameworks, utility libraries, etc. It tends to be pretty stable, unless you try to upgrade something years down the road.

Which is why both the Ember.js project and Angular 2.0 have a cli now that provide standard commands for development and a standardized structure. Of course, both are much larger frameworks than React and attempt to provide a complete solution for web applications while React is just a popular view layer.

> The problem is that for many, react does not do that – because you need npm, webpack, babel, systemjs, and so on and so on.

This couldn't be further from the truth. And besides, create-react-app solves that.

> No need to configure thousands of transpilers, no need to handle constantly breaking dependencies, because people keep their API stable for years, some even decades

I have been using react since early 2014, back when it was still very early pre-release. I have had to change exactly one thing w.r.t to the react API. When we decided to add in webpack, again, I had to change exactly one thing there as well -- I switched to a .babelrc file and they included the react transpiler by default.

> And besides, create-react-app solves that.

Until something breaks, and you have to go through all the configs and try to fix it.

I’ve seen https://kukuruku.co/post/hello-real-world-in-php-in-2017/ far too often.

I think your comment is touching on two different points, in my view.

> Until something breaks, and you have to go through all the configs and try to fix it.

This is solved by understanding the language and the tools you are using. I see so many people screw up a react app because they don't know javascript. They take the same smorgasbord approach to languages and tools they have used in the past (like jQuery) and apply it to react. React is really a frontend framework for javascript developers, not a frontend framework for creative types (like Misko originally slated angular to be) If people would just take the time to learn the actual language they are using, it would make these other tools easier to grok. This is software development. It is suppose to be hard. Take the time to learn your tools.

> I’ve seen https://kukuruku.co/post/hello-real-world-in-php-in-2017/ far too often.

I always wonder why people elect to use a heavy set of opinionated tools to solve simple problems. I understand the point the blog post is trying to make, but again, it's like taking a highly set of specialized tools and complaining when it is difficult to do the simple things, when all you needed was a hammer. React is a UI library first and foremost. You can take it, inject it into your page, and use it. You shouldn't add the bells and whistles until your complexity grows to the point where it makes sense to use it. I tell people to ask themselves this question all the time, "Are you sure you need flux?" Stop and ask that question. Can this be solved by just maintaining state on a top level component and passing down props? Do you need codesplitting and chunking and the advanced features of webpack? Or do you still operate in a traditional way where designers hand of their templates to coders to create the html and css and you are just tasked with writing the javascript? Then don't use webpack loaders. Use your coder's classnames on your components.

This is people making things harder than they have to be. But again, all of this is really not that difficult if you take the time to fundamentally understand javascript.

One of the big issues I see with JS is a bit of an abstraction problem.

See, in the Java world, lambdas were introduced, and I can write code with them using RetroLambda, and it will run on old JVMs, too.

But Java 8 has them natively.

And I can write a modern Java8 project with nano and javac. No transpilers, nothing.

While in the JS world, even now that browsers are starting to support ES6, everyone just adds more and more steps to the build process, instead of trying to simplify them.

Ideally, if I write code, I want it to be simple, without any such tools.

I want to be able to write one file containing dependencies, my code in a few files, execute one command, maybe two, and have a fully working product. And have it work for years, even while dependencies update.

One config, one command, and my code. Not any single LOC or invocation more.

That’s doable with JS – you just need a dependency format where dependencies can define macros over the language, and they’re handled by a transpiler or compiler, and you can import them normally. And just like that, a lot of this stuff would go away. TypeScript would just use its own frontend to the transpiler, and in your config you’d just define a different plugin.

In the gradle and java world, all that exists, with language-plugins, and annotation processors.

Yet in the JS world, it’s not like that, you have dozens of abstractions on top of another.

> This is solved by understanding the language and the tools you are using.

The problem is that the JS world is simply more complex than the Java world.

A helloworld JavaFX app is about 30LOC of config, and 20LOC of code and imports. And compared to a production JavaFX app, no more config will be added. It’s just that. That’s all you need. And easy to understand.

For React, it’s an entirely different beast (see the mentioned link)

> While in the JS world, even now that browsers are starting to support ES6, everyone just adds more and more steps to the build process, instead of trying to simplify them.

To build on your Java comparison -- this is would be akin to using a new feature that is still in the JSR approval process, and then downloading an edgey JVM platform (maybe OpenJDK nightly, or something like that) and then complaining when your app gets more complicated. The solution to that problem is to stick to the stable syntax until the new becomes fully supported. Admittedly, this is a problem with browsers where instead of 1 environment, there are 8 with some 1 offs, but again, there is IBM JDK, OpenJDK, Oracle JDK, Android Java (whatever that's called, Dalvik or something?)

> The problem is that the JS world is simply more complex than the Java world.

I strongly disagree. Have you seen "enterprise fizzbuzz"?* I don't mean disrespect but you are kidding yourself if you think Java isn't as complex (if not more) than the current JavaScript ecosystem. I spent 6 years programming in Java and never felt I scratched 10% of the surface.

* https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

> I strongly disagree. Have you seen "enterprise fizzbuzz"?* I don't mean disrespect but you are kidding yourself if you think Java isn't as complex (if not more) than the current JavaScript ecosystem. I spent 6 years programming in Java and never felt I scratched 10% of the surface.

But that’s the point. That’s all just code. Just normal code. Not additional command line utilities. Even Enterprise FizzBuzz can be compiled simply with gradle or maven. No processors. No transpilers.

> To build on your Java comparison -- this is would be akin to using a new feature that is still in the JSR approval process, and then downloading an edgey JVM platform (maybe OpenJDK nightly, or something like that) and then complaining when your app gets more complicated.

But I can do that. And I just have to import one single plugin – https://github.com/evant/gradle-retrolambda, and never configure it! Nothing to configure, nothing else. One import, and I’m done.

Look at that fizzbuzz enterprise build.gradle, it’s 29LOC!

The problem of "good defaults" was never even considered in the JS world, it seems.

Again, this is not a good example of why the javascript ecosystem is worse / java is better.

> But that’s the point. That’s all just code. Just normal code. Not additional command line utilities.

First, Maven does not come standard with java. Second, in a previous reply, I mentioned that if you are not comfortable with the latest and greatest, then stick to the current standard. There is nothing wrong with that, and you can be productive. If transpilers and babel seems too scary to you, which given you mention maven and gradle I assume not, then don't use them, use polyfil, which is just like that retrolambda you linked. Most all of ES6's features are sugar anyways.

Your intimate knowledge of tools and frameworks for the Java ecosystem will not equal another. What's a plugin? Ohhh you mean OSGI? No? Oh well I am lost.

What is gradle? Oh it's a new build tool? Well sorry I only know ant, and my coworker uses sbt. He's hipster like that.

> The problem of "good defaults" was never even considered in the JS world, it seems.

touché for java.

Not a React guy, but there is lot's of hyperbole in here. Not sure how npm, webpack, babel, "thousands of transpilers" et al slow you down. They're tools that do things so you don't have to... Are you seriously saying that hand converting ES6/7+ to running ES5 would be faster than babel? Hand bundling/splitting of code would be faster than browserify, webpack? Hand finding, curating, tracking of dependencies would be faster than NPM? mmk.

> Are you seriously saying that hand converting ES6/7+ to running ES5 would be faster than babel?

No, that shouldn’t even be a thing. All runtimes, worst case, should be maybe 6 months behind the standard, otherwise I’d want to use a single transpiler.

Going TypeScript -> ES7 -> ES6 -> ES5 is insanity.

> Hand bundling/splitting of code would be faster than browserify, webpack?

Why should that even be necessary? Upload your code file by file, and actually use the browser’s required, or have one single script implementing this as polyfill. Why should I even have to do this?

> Hand finding, curating, tracking of dependencies would be faster than NPM? mmk.

No, but NPM’s tracking is useless when dependencies constantly change their API with every release.

I’ve got so many dependencies via NPM that even change their name and API constantly that many of my projects have been broken after just a year, but all after max 2 years.

I’ve got Java projects that are 5 years old and every dependency is still update, with a stable API.