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

81–90 of 120 posts

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#81

Post by dasil003 »

nailer wrote: post #74
rout39574 wrote: post #40

Earlier quoted context omitted.

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 'innova…

It's a dependency graph. It's just a data structure. You can do that in any language. Saying you need automake for a build system, or would gain anything from doing so compared to a native system, is akin to saying you need another language for arrays. Regarding your popularity argument: amongst other JS developers you'd get more network effect from gulp. If your backend is, say, Python or Ruby learning automake woul…

The point is that shell is not "another language", it's a foundation of the entire world of modern programming, not some esoteric thing for a single purpose.

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#82

Post by khalilravanna »

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),…

Specifically for "analyzing of project structure" there does exist [MaDGe (Module Dependency Graph)](https://github.com/pahen/madge). You can generate some pretty nifty dependency graphs for your javascript codebase. I use it everyday when working on my game as I have a step in my gulp watch task that checks for any circular dependencies I may have introduced every time I hit save. It was a lifesaver when I made the switch over to browserify for my large game-codebase and found out I had a nightmarish dependency graph with a huge amount of cycles in it.

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#83

Post by feedjoelpie »

MrBuddyCasino wrote: post #80
ralfn wrote: post #45

Earlier quoted context omitted.

Some of those features are only possible because Java is statically typed. They couldnt exist in the same way for "pure" JavaScript.

Facebook is doing something that enables better IDE support for JS, so static typing isn't absolutely required, it just makes it a lot easier. I forgot the projects name though, the IDE part was also not open sourced back then.

Their optional typing for JS is called Flow, and they've open sourced an IDE of sorts (a suite of Atom plugins) called Nuclide (http://nuclide.io/).

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#84

Post by tbolt »

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.

this post encapsulates why development with js can be a nightmare. you start with grunt because that's the cool one, then everyone shifts to the new cool one -gulp- but oh wait, if you are concerned about build time, you need to be using this other new hotness.

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#86

Post by temo4ka »

sirgawain33 wrote: post #77
iandanforth wrote: post #54

There is a fairly important point that is missed by this article. You do not need build tools to write JavaScript and depending on which tools you use there are significant drawbacks to using any them. Before you dive into the world of build tools and process management I urge you to write unminified, ES5 (aka the JavaScript that runs without transpilation today) until it hurts. Write unminified JavaScript and watch…

I highly recommend this road as well. Three exercises along the lines of the parent that I found particularly valuable: 1. Compare VanillaJS TodoMVC to your framework of choice http://todomvc.com/ https://github.com/tastejs/todomvc/tree/gh-pages/examples/va... What does the framework buy you? Is the framework-powered code easier to read? Easier to understand for a newcomer to the code base? 2. Read every line of Effe…

3. b) http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool...

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#87

Post by edwinnathaniel »

SonicSoul wrote: post #51
joesmo wrote: post #48

"The biggest weakness of such small tools approach is that it is hard to learn what to use and how to configure it." No. By far the biggest weakness of such a small tools approach is a Balkanization of development tools that generally refuse to work with one another and often don't work very well by themselves. One library I really wanted to try was using Browserify but I wanted to use brunch/bower because my workflo…

yes there is this overhead, but it also reduces dependency on any specific framework, avoids using big one-size-fits-all monoliths, let's you choose the best tool for the job, makes your team a lot more well rounded by understanding pros and cons of each of those libraries.

What if they _are not_ the best tool for the job largely because these tools just _get started_ (e.g.: v 0.1/0.2) and less mature?

Let's compare it with the evolution of Maven. Yes, I heard hatred and grumbling whenever Maven is mentioned but darn, that's a solid software. Old Maven, version 1 was OK, version 2 was solid, version 3 (or 4?) is when they address polishing issues and perhaps making a leap joining the new kids on the block (Gradle) by listening to the community and figure out a roadmap (I heard something about programmatically do stuff with Groovy... in Maven).

Sometimes one need to let the tools maturing and evolving before dropping judgement and roll yet-another-too-simple-tool and call it solving problems that the other tools did not do well (and for ego, of course, name a developer that has none..)

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#88

Post by hex13 »

khalilravanna wrote: post #82
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),…

Specifically for "analyzing of project structure" there does exist [MaDGe (Module Dependency Graph)]( https://github.com/pahen/madge ). You can generate some pretty nifty dependency graphs for your javascript codebase. I use it everyday when working on my game as I have a step in my gulp watch task that checks for any circular dependencies I may have introduced every time I hit save. It was a lifesaver when I made th…

Yes, I heard about Madge, but isn't it for CommonJS and AMD only?

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#89

Post by edwinnathaniel »

hex13 wrote: post #76
joesmo wrote: post #49

Earlier quoted context omitted.

WebStorm ( https://www.jetbrains.com/webstorm/ ). Or if you use other languages as well, check out any of Jetbrains' IDEs: https://www.jetbrains.com/ I haven't found a better IDE for any language yet.

I think that WebStorm is decent JavaScript IDE but if we 're talking about editing HTML/CSS/Sass, WebStorm is not any better than plethora of other text editors. IMO basic problem lies in fact that we're still trying to edit hierarchical tree structures of HTML and CSS/SCSS as a plain text instead of editing underlying tree structure. I think that good HTML/CSS editor should operate on tree and every CSS rule and eve…

Decent JS IDE?

It's the best one I've tried out there. Literally. No other text-editor-with-plugins (VIM, Emacs, Sublime, Atom) or IDEs come anywhere close.

Re: The Hitchhiker's Guide to Modern JavaScript Tooling

#90

Post by ricogallo »

joesmo wrote: post #48

"The biggest weakness of such small tools approach is that it is hard to learn what to use and how to configure it." No. By far the biggest weakness of such a small tools approach is a Balkanization of development tools that generally refuse to work with one another and often don't work very well by themselves. One library I really wanted to try was using Browserify but I wanted to use brunch/bower because my workflo…

Please take a look at how I found my peace using GNU make in frontend development: https://gist.github.com/ricogallo/726fcb6e46d5a7405a9f
Post reply on HN