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

I think this is due to the fact that not every has ability / desire to live in the console. Having a development process that can work without a compile step is important.



It's really sad to me that this is the best explanation I've heard so far for reinventing CommonJS in ES6 and it still falls flat on its face.


browserify + watch ... run it and forget it

bonus points because you can hook a linter into it.


Run it for every project you mean. The nice thing about the web is that with a simple http server you can just start coding. Compile-steps take away that incredible advantage.


> Run it for every project you mean.

Yep. Is that so bad? You know you can have multiple Terminal.app's open at once, right?

> The nice thing about the web is that with a simple http server you can just start coding.

The nice thing about browserify/node is that I can install node, clone my seed script, execute it, and just start coding.

> Compile-steps take away that incredible advantage.

While giving you the huge advantages of TDD/unit testing; the npm repository; being able to use the CommonJS module pattern...

If you're just woodshedding a toy, or trying to learn - by all means, set up lighttpd and boot sublime and go at it. But if you're trying to build production-quality software... hone your craft; be better than a codemonkey.


> While giving you the huge advantages of TDD/unit testing

You don't need a compile step to do unit testing. Or even to use CommonJS for that matter.

> If you're just woodshedding a toy, or trying to learn - by all means, set up lighttpd and boot sublime and go at it. But if you're trying to build production-quality software... hone your craft; be better than a codemonkey.

You don't need a compile-step in development to create good software. Client-side loaders have all of the advantages of server-side loaders but you can also use them without a watch task. ES6 modules are just going to make it all easier.


> You don't need a compile step to do unit testing.

Okay, I guess I could have a window with karma open and keep refreshing it every time I change code. Having an eshell open running my unit tests every time I save is a lot faster, though. Unfortunately, most of what I do is remote over SSH instead of having a local development environment. And that doesn't even begin to cover building a jenkins (or other CI) script to run your non-compile-time unit tests.

> Or even to use CommonJS for that matter.

Which client side loaders would you recommend? I've used AMD/RequireJS in the past and its headaches were not worth the benefits. The only other project in the running is Webpack.

> but you can also use them without a watch task

I suppose I don't understand the watch task hate. It's there. It runs. It versions my build. It lets me know when I've saved something stupid. It's faster than tabbing to a browser and going through the steps to reproduce the iota of code I just wrote, or refreshing a testrunner page.

How do you do continuous integration and save-time unit tests without a preprocessing step without tying your project to a bloated IDE?

> ES6 modules are just going to make it all easier.

When ES6 modules come around to being available in IE9 (or IE9 finally dies), I'll believe that you can do all this without a processing step. Even when ES6 modules become available in modern browsers, you'll still have to run everything through a preprocessing build step to get backwards compatibility. And woe to whomever tries to do dynamic dependency loading on mobile... that 200-2000ms per-http-request overhead on 3G will bite you right in the bounce rate.


SublimeLinter


And when you decide to grow up and start unit testing, you'll still have to fall back to the command line.




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

Search: