Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Hitchhiker's Guide to Modern JavaScript Tooling

reactkungfu.com

Post reply on HN
Print view View original

31–40 of 120 posts

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#31

Post by Wintamute »

hex13 wrote: post #11

We talk about "modern JavaScript tooling" but year after year, the list essentially stays the same. Maybe few new players have appeared (Gulp, WebPack, Babeljs) but they do exactly the same thing that the tools we had before (e.g. Grunt, Browserify, Traceur). It occurs to me that "modern JavaScript tooling" is growing only vertically (better tools to build, better tools to modularize, better tools to transpilation),…

I think we'll see the emergence of some of these next-gen tools once ES6+ has started to bed in. ES6 modules are much more receptive to static analysis than ES5 code.

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#32

Post by Plugawy »

AdrianRossouw wrote: post #21
tete wrote: post #3

Gulp is really great and better, than Grunt, but sometimes make seems to be a good choice that people forget about.

since i switched to webpack, i've had very little reason to use gulp in my projects. Anything extra was very easily managed by some simple Makefiles.

Can you post some examples of your Makefiles?

I'm trying to work out how I can replace Rails' asset pipeline without getting a headache caused by overwhelming number of node-based tools I'd have to install.

Having one tool + make sounds like something I'd gladly adopt.

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#33

Post by Wintamute »

mbrock wrote: post #30
cozuya wrote: post #24

Earlier quoted context omitted.

No one needs anything. You can write code in notepad. No one wants that, and no one wants to have a million globals on the browser or hit F5 every single save any more. While there is a learning curve to something like gulp, you really only need to set it up once and you can use it on every project as simply as typing "npm i".

I wrote code in Notepad for years. Often now I use cat instead. Sometimes even ed, which is surprisingly useful for many editing tasks. Knowing how to do things in the most basic, fundamental way is nourishing. And I've heard from many people that the JavaScript ecosystem—by which they seem to mean all the stuff they hear that everyone else is using—makes them feel overwhelmed. So it's good to have this clear explana…

I agree that it's essential and nourishing to understand the basics, but I feel that familiarity with the basics and expertise with these tools represents a minimum baseline standard for professional frontend development, especially when working in teams on medium/large web apps. Granted it's not easy to get up to speed with all of it, but many fields in programming and CS are not easy either. As browsers become increasingly standardised and stable and web languages grow up (ES6+) we'll be able to do increasingly sophisticated things, and frontend web development will attract more serious programmers ... we're seeing that now with the interest in React and functional JS, there's a lot of cross pollination between JS and the Clojure/Haskell communities which until now have remained in their ivory towers. Modern/professional frontend development won't and indeed shouldn't be something you can still just get done with Notepad and a few tags.

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#34

Post by kriro »

the8472 wrote: post #27
hex13 wrote: post #11

We talk about "modern JavaScript tooling" but year after year, the list essentially stays the same. Maybe few new players have appeared (Gulp, WebPack, Babeljs) but they do exactly the same thing that the tools we had before (e.g. Grunt, Browserify, Traceur). It occurs to me that "modern JavaScript tooling" is growing only vertically (better tools to build, better tools to modularize, better tools to transpilation),…

> * better editors for HTML/CSS, maybe even some decent WYSIWYG Editors? How about an IDE. In the java environment I can manage an application container, profiler, debugger, compiler, packager, test suite all from one application. Also included: near-omniscient auto-complete, hot-code replace, incremental building, dependency fetching, visual version control, automatic refactoring, deployment and many other convenien…

WebStorm is pretty good already imo.

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#35

Post by hex13 »

Wintamute wrote: post #31
hex13 wrote: post #11

We talk about "modern JavaScript tooling" but year after year, the list essentially stays the same. Maybe few new players have appeared (Gulp, WebPack, Babeljs) but they do exactly the same thing that the tools we had before (e.g. Grunt, Browserify, Traceur). It occurs to me that "modern JavaScript tooling" is growing only vertically (better tools to build, better tools to modularize, better tools to transpilation),…

I think we'll see the emergence of some of these next-gen tools once ES6+ has started to bed in. ES6 modules are much more receptive to static analysis than ES5 code.

Maybe... but maybe it will be like that: https://xkcd.com/927/

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#36

Post by rout39574 »

tdumitrescu wrote: post #7
tokenizerrr wrote: post #6

Earlier quoted context omitted.

I recently tried switching from Grunt to Gulp and was expecting to see improvements in build times, but my builds actually wound up taking about 2x as long (on an ssd). Maybe I was doing something wrong, I don't know, but it was pretty disheartening. Here is my Gruntfile in case anyone cares: http://hastebin.com/wezizasiye.js

If build time is a big concern, I'd suggest Brunch. It starts out fast and it caches previously built assets so that subsequent builds are incremental.

How is that different from make?

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#38

Post by williamcotton »

Plugawy wrote: post #32
AdrianRossouw wrote: post #21

Earlier quoted context omitted.

since i switched to webpack, i've had very little reason to use gulp in my projects. Anything extra was very easily managed by some simple Makefiles.

Can you post some examples of your Makefiles? I'm trying to work out how I can replace Rails' asset pipeline without getting a headache caused by overwhelming number of node-based tools I'd have to install. Having one tool + make sounds like something I'd gladly adopt.

Here's something I made about 6 months ago:

https://github.com/williamcotton/makeify

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#39

Post by mbrock »

Wintamute wrote: post #33
mbrock wrote: post #30

Earlier quoted context omitted.

I wrote code in Notepad for years. Often now I use cat instead. Sometimes even ed, which is surprisingly useful for many editing tasks. Knowing how to do things in the most basic, fundamental way is nourishing. And I've heard from many people that the JavaScript ecosystem—by which they seem to mean all the stuff they hear that everyone else is using—makes them feel overwhelmed. So it's good to have this clear explana…

I agree that it's essential and nourishing to understand the basics, but I feel that familiarity with the basics and expertise with these tools represents a minimum baseline standard for professional frontend development, especially when working in teams on medium/large web apps. Granted it's not easy to get up to speed with all of it, but many fields in programming and CS are not easy either. As browsers become incr…

Well, one thing about JavaScript is that it's a very flexible language in itself without any additions. It's similar to something like Scheme. And good Schemers can accomplish a lot of cool stuff with the proverbial Notepad. I'd rather hire someone with no clue about Gulp or npm but who understands all of JavaScript and knows how to do stuff in the simplest possible way, than someone who's mastered all of these tools and can't do anything without a framework. Forgive my bluntness. I disagree with the premise that sophistication requires complexity. I prefer to see it the other way around. Maybe I'm growing older. When I see a complex build tool replaced with three lines of bash, that makes me happy. And when I notice someone has given a bit of thought to making a simple solution based on fundamental needs instead of installing all kinds of stuff, like the commenter who mentioned downloading 200 MB of code just to initialize a project...

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#40

Post by rout39574 »

nailer wrote: post #17
tete wrote: post #3

Gulp is really great and better, than Grunt, but sometimes make seems to be a good choice that people forget about.

I'd rather use JS than add shell mixed in with Makefile. Two extra languages just to run a build system seems like adding unnecessary complexity.

Shell and make are pervasive. If you're not comfortable with them, you will glean great value from becoming so.

Your perspective rings to me like "There's plenty of technical literature in Mandarin; learning English just to ...." Not wrong, per se. But profoundly limiting, and to an extent you won't comprehend until you've crossed that knowledge barrier.

Elswhere in this comment stream someone talks about the 'innovation' of incremental builds in the JS build tool landscape... I think you might find that Make discovered, and solved, most of the build-system challenges the language-specific tools will encounter, decades ago.

Post reply on HN