Hacker News new | past | comments | ask | show | jobs | submit login

By the same note, you likely won't be writing a complex desktop application without some tooling installed, with similar pre-requisites. I don't know why people get so irritated at "JS tooling is hard". Try writing an (INSERT FRAMEWORK HERE) app outside the browser.

People assume that writing an APPLICATION for a browser is easy, which is why people get stuck maintaining monstrosities that are disorganized, not composed and tens of thousands of lines of spaghetti. Writing an application in the browser deserves just as much respect as one would give towards setting up the database & schema or creating a service layer.

That lack of respect for front end code is a big reason as to why front end projects have crappy code. React is a real break from this on so many levels... Yes, you'll need (webpack|jspm|browserify) with (babel|typescript), and likely (postcss|less|scss) in place closer to the start than the end. Much like if you're writing code for a desktop application you'll likely need at least an IDE installed, and potentially several libraries close to the start.

My current tooling of choice is webpack + babel, depending on the project I may bring in scss or less, and react tooling as needed. Using CSJ or ES6 style module syntax means cleaner code that's easier to restructure. Using webpack means being able to bundle resources in a logical flow. Working on a project without webpack + babel is just painful by comparison... I'm working on an ng1 app at work that's less than 6 months old, and feels like it was written in 2011... having to add .js files to some common point, and not being able to easily refactor services/controllers/directives/components into discrete modules is pretty painful in general.

What does it take to get a Java application going? Maven, some build system, some other tooling, and understanding the component/class hierarchies? It's not any easier than working with any new tooling.

Is there some churn, yes... is it that bad, not really... going to browserify mainly means that you can have references from a starting point into your application's code... each piece requires in its' dependencies. From there going to webpack adds in other dependencies and custom loaders. Babel is a translation layer... these tools generally build on or are supersets of the tools that came before.

There is much less tooling and much less churn even for a very complex Java application

When I see people in other teams fighting with Maven, Jenkins builds for weeks somehow I cannot believe this.

I didn't say that Maven wasn't complex. I said there are fewer tools and less churn. The advantage of Java dev is that you can justify the intellectual investment in the tools because there are fewer of them and they are going to be around for a long time. The same cannot be said about client-side development at this time.

Grunt still exists, npm has been a common point for close to half a decade now... it's pretty solid... everything else builds from there. If you've gotten used to npm and cjs modules, that's been very consistent for a number of years now.

Would you use Grunt for new projects? Maven is still being actively used.

I thought Gradle was the new Maven. Before Maven it was Ant. There's even Buildr (though not as popular).

> you likely won't be writing a complex desktop application without some tooling installed

With C++ I can just download Visual Studio, or the Qt SDK. No other dependencies.

With Go, I download Go (a single installer) and also my Go IDE of choice - LiteIDE (a single zip).

I don't have to install an installer installer or any nonsense like that.

And go doesn't have a package manager? It doesn't need any other modules to create gui apps? Aren't there wrapper bindings that would be simpler than direct api calls?

Speaking for myself, I have used many platforms ranging from embedded to desktop and I also proud myself to be a competent old skool web developer - one who has avoided node.js, angular, amber and similar. React caught my attention and I tried to learn using it... What pain! What parent is saying about tooling is totally true. But maybe I just missed a simple hello world tutorial... I will check it out in a year or so, if it's still around by then.

Got a whole bunch of tutorials listed in my React/Redux links repo, at https://github.com/markerikson/react-redux-links. If you're looking for a couple that are really simple and involve no other tools or libraries, you may be interested in http://jamesknelson.com/learn-raw-react-no-jsx-flux-es6-webp... or https://github.com/kay-is/react-from-zero.

Thanks, appreciate it! I will save the links for the next time I go exploring React (which should be soon).

This is why I like Ember: you get setup in 2 seconds. Sure, I don't like all of the decisions they've made in the framework but it does work really well out of the box.

I think having a cli will become standard for JS frameworks. You just need to have the batteries included to capture the newb mindshare.

I've recently started looking into Ember - which of their framework decisions do you dislike?

I prefer mocha to qunit and I'm a fan of coffeescript (ES6 can wait. I love the existential operator). My company had made a few decisions before ember-cli that weren't on the Ember Happy Path. I've tried to stick to those decisions to avoid making people learn a different stack. It's not that easy to rip and replace pieces of Ember.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact