The Hitchhiker's Guide to Modern JavaScript Tooling(reactkungfu.com)
reactkungfu.com
The Hitchhiker's Guide to Modern JavaScript Tooling
http://reactkungfu.com/2015/07/the-hitchhikers-guide-to-modern-javascript-tooling/
20 comments
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 Effective Javascript (it's short and eminently practical) and write out every code example.
http://www.amazon.com/Effective-JavaScript-Specific-Software...
There are about a dozen small errors in the code in the book, see if you can find them.
3. Read substack's alternative Javascript build flow:
http://substack.net/task_automation_with_npm_run
Think about the possibilities and limitations. (I personally love his approach at the beginning of projects when I could care less about fiddling with gulp and want to get into exploring the guts of a problem)
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 Effective Javascript (it's short and eminently practical) and write out every code example.
http://www.amazon.com/Effective-JavaScript-Specific-Software...
There are about a dozen small errors in the code in the book, see if you can find them.
3. Read substack's alternative Javascript build flow:
http://substack.net/task_automation_with_npm_run
Think about the possibilities and limitations. (I personally love his approach at the beginning of projects when I could care less about fiddling with gulp and want to get into exploring the guts of a problem)
There's a definite balance between cargo-culting and reinventing the wheel. Minification is often a premature optimization. A somewhat proper/standardized module system (aka that which comes with ES6), on the other hand, is almost a necessity when it comes to building software.
Standalone JS was meant to add little bits of interactivity to documents. If what you're building is interactive documents, build tools are generally overkill. If you're building applications, the tools exist largely b/c JS-in-the-browser was not designed to build applications.
Standalone JS was meant to add little bits of interactivity to documents. If what you're building is interactive documents, build tools are generally overkill. If you're building applications, the tools exist largely b/c JS-in-the-browser was not designed to build applications.
> Discover for yourself why these tools exist or you'll waste a ton of time learning the newest thing and in the end not have gained much at all.
Exatcly. It's important to clarify these things because so many inexperienced developers get lost in the maze of js tooling for no apparent reason.
Learning how to use these tools takes time which could be spent on learning how to program properly. And in some cases JS tooling isn't necessary at all, even in more complex projects. For example if you end up working in environments such as rails where most of these things are done automatically.
I've also noticed how people seem to look down on GUI tools such as https://incident57.com/codekit/. I think it's a great solution for beginners and people who don't need complex custom tooling.
Exatcly. It's important to clarify these things because so many inexperienced developers get lost in the maze of js tooling for no apparent reason.
Learning how to use these tools takes time which could be spent on learning how to program properly. And in some cases JS tooling isn't necessary at all, even in more complex projects. For example if you end up working in environments such as rails where most of these things are done automatically.
I've also noticed how people seem to look down on GUI tools such as https://incident57.com/codekit/. I think it's a great solution for beginners and people who don't need complex custom tooling.
People get lost not for "no apparent reason" but because the maze of JS tooling is incredibly confusing, full of people telling you "do this, use that!" (without accounting for the other 40 things you want to use together with that) and full of stuff that is underdocumented and misdocumented and outright broken and changes every 6 months. Even if you learn "how to program properly" it doesn't in any way mean that you will be conversant with this confusing world.
Rather than blaming the user we should probably recognize there are quality problems that are the root cause of user confusion.
Rather than blaming the user we should probably recognize there are quality problems that are the root cause of user confusion.
> It's really only when you find yourself with a problem that you can quantify that these tools start to make sense.
Good point. Another reason to be careful is that there are too many half-assed solutions to problems that might not even be real.
Good point. Another reason to be careful is that there are too many half-assed solutions to problems that might not even be real.
I wish and hope web developers (and developers in general) read your post. Very well said.
"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 workflow was already in brunch. Even with the brunch-browserify plugin this wasn't possible. After wasting two days on it, I gave up and just used Browserify by itself. Another couple of hours it was actually working. This is typical. On another app, I use gulp. Another piece of garbage that claims that when you run a command 'gulp watch' it will automatically rebuild your assets. It won't.
These are only three small projects, each using a different build tool: browserify, gulp, and brunch + bower. None of them are compatible with each other and it's unlikely they will ever work together in one project without hours or days of trial and error. If there was one monolithic (or not) dependency / build tool that actually worked, I'd much rather use that, and it would be a much better approach than having a whole bunch of small crappy tools that don't work together.
tl;dr: Not only is having multiple tools doing the same thing in this area not appealing, it just leads to developers wasting massive amounts of time and "what the fucks?" working with half a dozen tools that do the same thing and do it poorly.
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 workflow was already in brunch. Even with the brunch-browserify plugin this wasn't possible. After wasting two days on it, I gave up and just used Browserify by itself. Another couple of hours it was actually working. This is typical. On another app, I use gulp. Another piece of garbage that claims that when you run a command 'gulp watch' it will automatically rebuild your assets. It won't.
These are only three small projects, each using a different build tool: browserify, gulp, and brunch + bower. None of them are compatible with each other and it's unlikely they will ever work together in one project without hours or days of trial and error. If there was one monolithic (or not) dependency / build tool that actually worked, I'd much rather use that, and it would be a much better approach than having a whole bunch of small crappy tools that don't work together.
tl;dr: Not only is having multiple tools doing the same thing in this area not appealing, it just leads to developers wasting massive amounts of time and "what the fucks?" working with half a dozen tools that do the same thing and do it poorly.
That may be your experience but it's not even close to mine. I've used gulp, bower, and browserify across several projects and it's never taken me more a couple of hours to set them up and they have saved me a ton of time. You might not like the way the tools work but that certainly doesn't mean they are poor tools.
Please take a look at how I found my peace using GNU make in frontend development: https://gist.github.com/ricogallo/726fcb6e46d5a7405a9f
This was definitely my experience when I tried to move from python/django to javascript and gulp/browserify/foundation/nunjucks/backbone And it almost led to me getting fired. I almost certainly made rookie mistakes in trying to set up my development environment, but I think the lesson learned here is that when I try that again, I'm going to either:
1) Work with each tool individually first and really get to know it.
2) Have someone else who is experienced in this assemble the toolchain with the promise that I can come to them to debug toolchain problems.
1) Work with each tool individually first and really get to know it.
2) Have someone else who is experienced in this assemble the toolchain with the promise that I can come to them to debug toolchain problems.
Unix much?
My biggest hesitation about WebPack is that it does too much and duplicates so many other tools. If I'm already using Gulp to watch files and BrowserSync (love!) as my local dev server, why do I need WebPack when I'm only going to be using one of its abilities? Isn't this bloat?
My biggest hesitation about WebPack is that it does too much and duplicates so many other tools. If I'm already using Gulp to watch files and BrowserSync (love!) as my local dev server, why do I need WebPack when I'm only going to be using one of its abilities? Isn't this bloat?
Perhaps your research didn't lead you to an answer, however I feel like the bower/browserify isn't that big a bridge to cross. A tool like literalify[1] will allow you to 'require' globals. If you wish to require bower components, browserify-ing them isn't going to work quite well simply because normal javascript adds globals while commonjs has you explicitly get what you desire. As for CSS, there are ways to [2] inject it on the fly. Though at that point your making your bundle much larger than it needs to be.
[1] https://github.com/pluma/literalify [2] https://github.com/substack/insert-css/blob/master/index.js
[1] https://github.com/pluma/literalify [2] https://github.com/substack/insert-css/blob/master/index.js
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..)
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..)
I don't see how this reduces dependencies on any specific framework or in any way affects that at all. I'm the one who chooses what dependencies and frameworks I work with. The only way these tools affect which dependencies I choose is that they limit the ones that can work with each other. Nor does it "avoid using big one-size-fits-all monoliths," because that wasn't a problem I had in the first place. The article is about build tools in case you haven't noticed.
It does not let me choose the right tool for the job. That's exactly what I'm describing in the post. It forces you to use whatever the authors of library X thought is the right tool for the job. And the authors of library Y and the authors of library Z ... etc. to the point where it becomes impossible to actually work with libraries from different sources together unless you manually manage them.
It does not make the team a lot more rounded to learn and understand a bunch of build tools that do the same thing as each other. What would make it more rounded is if these tools weren't so shitty, worked together, and there was only one of them so they could focus on actually building stuff instead of mentally masturbating about stupid build tools that don't work.
It does not let me choose the right tool for the job. That's exactly what I'm describing in the post. It forces you to use whatever the authors of library X thought is the right tool for the job. And the authors of library Y and the authors of library Z ... etc. to the point where it becomes impossible to actually work with libraries from different sources together unless you manually manage them.
It does not make the team a lot more rounded to learn and understand a bunch of build tools that do the same thing as each other. What would make it more rounded is if these tools weren't so shitty, worked together, and there was only one of them so they could focus on actually building stuff instead of mentally masturbating about stupid build tools that don't work.
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), but not horizontally. If we see some "brave new tool" on the scene, this tool will do exactly what previous tools did, only better.
I would like to have some decent tools for:
* analysing of project structure (e.g. dependencies between modules, graphs, trees etc.)
* code visualising (not toy! Gource is beautiful, but pretty useless. JSCity... I also don't see much use of it. I would see something that would allow me to draw some useful information from code visualisation. Something that would allow to understand better. But I see only beautiful animations and abstract 3D scenes)
* maintaining code (something that would allow me to conduct massive scale refactoring, or automatically convert code from one framework to another etc.)
* better editors for HTML/CSS, maybe even some decent WYSIWYG
Okay. Plain build systems and transpilers also are super useful. I think that Gulp, Babel.js, Browserify etc. are greeeat. But I think we need more. Something different. There is still room for innovation. Projects grow bigger and I think that we need something that helps us
* to understand easily new codebase
* to navigate codebase, conduct semantic search etc.
* to maintaining, refactoring etc.
I feel that some important tools are missing, not created yet.
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), but not horizontally. If we see some "brave new tool" on the scene, this tool will do exactly what previous tools did, only better.
I would like to have some decent tools for:
* analysing of project structure (e.g. dependencies between modules, graphs, trees etc.)
* code visualising (not toy! Gource is beautiful, but pretty useless. JSCity... I also don't see much use of it. I would see something that would allow me to draw some useful information from code visualisation. Something that would allow to understand better. But I see only beautiful animations and abstract 3D scenes)
* maintaining code (something that would allow me to conduct massive scale refactoring, or automatically convert code from one framework to another etc.)
* better editors for HTML/CSS, maybe even some decent WYSIWYG
Okay. Plain build systems and transpilers also are super useful. I think that Gulp, Babel.js, Browserify etc. are greeeat. But I think we need more. Something different. There is still room for innovation. Projects grow bigger and I think that we need something that helps us
* to understand easily new codebase
* to navigate codebase, conduct semantic search etc.
* to maintaining, refactoring etc.
I feel that some important tools are missing, not created yet.
> * 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 conveniences I'm taking for granted. Hell, I could even file tickets from my IDE if I wanted to.
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 conveniences I'm taking for granted. Hell, I could even file tickets from my IDE if I wanted to.
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 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 every property should be object rather than plain text. That would allow to more natural editing and faster code modification/refactoring (I am frontend developer but I hate writing CSS/HTML by hand. It feels like using punch cards... Better editor could allow to do things faster and more effective).
I was looking for structural (and projectional) editor for HTML/CSS and didn't find any. So I started making my own (here is prototype: https://www.youtube.com/watch?v=yRwx09bAT08 )
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 every property should be object rather than plain text. That would allow to more natural editing and faster code modification/refactoring (I am frontend developer but I hate writing CSS/HTML by hand. It feels like using punch cards... Better editor could allow to do things faster and more effective).
I was looking for structural (and projectional) editor for HTML/CSS and didn't find any. So I started making my own (here is prototype: https://www.youtube.com/watch?v=yRwx09bAT08 )
I agree with edwinnathaniel, IntelliJ with its browser JavaScript debugging plugins is pretty awesome and I find it a fantastic JavaScript IDE.
I am curious what use cases you have for editing in the fashion of your demo video? I don't find myself frequently wanting to view just fonts in a css file. I either have specific rules I want to edit, or I pull up reused fonts and colours into re-used classes (or less variables) and just edit that one spot.
Why would you want to view just colours? Or just fonts? BTW, I am not trying to put down your idea, infact I think it's very interesting concept to work more closely with the tree structures.
Edit: as I think about the idea, it would be awesome if I could click on any html element in a file and it would be able to statically analyze and show all applicable css selectors. Although I frequently use angular and dynamically applied css classes.
I am curious what use cases you have for editing in the fashion of your demo video? I don't find myself frequently wanting to view just fonts in a css file. I either have specific rules I want to edit, or I pull up reused fonts and colours into re-used classes (or less variables) and just edit that one spot.
Why would you want to view just colours? Or just fonts? BTW, I am not trying to put down your idea, infact I think it's very interesting concept to work more closely with the tree structures.
Edit: as I think about the idea, it would be awesome if I could click on any html element in a file and it would be able to statically analyze and show all applicable css selectors. Although I frequently use angular and dynamically applied css classes.
> or I pull up reused fonts and colours into re-used classes (or less
> variables) and just edit that one spot.
good editor could pull up reused fonts and colours automatically (detecting if they the same in various nodes).
> I either have specific rules I want to edit
Yes, I'm also making possibility of filtering by specific rules and finding by CSS selector (in HTML also)
And different filters are just a part of the editor. Actually, my first idea was creating something that would allow to make quick changes that are super easy when operating on tree, but you must do them by hand in text editors (e.g. operations like "move to parent", "wrap this HTML element in new `div` element etc.).
I also want editor to be operable without keyboard/mouse switching. And because when I make websites I often use mouse to test in browser all functions, I want good mouse support and be able to change e.g. top from 0px to 10px using only mouse. This is possible in e.g. DevTools, why not to put this feature in editor?
> Edit: as I think about the idea, it would be awesome if I could click on
> any html element in a file and it would be able to statically analyze and
> show all applicable css selectors.
Yes. It would be nice, although I didn't solve this from technical perspective yet.
But for now I think about something like in Brackets - you edit HTML and could edit styles in place without switching to the other file.
good editor could pull up reused fonts and colours automatically (detecting if they the same in various nodes).
> I either have specific rules I want to edit
Yes, I'm also making possibility of filtering by specific rules and finding by CSS selector (in HTML also)
And different filters are just a part of the editor. Actually, my first idea was creating something that would allow to make quick changes that are super easy when operating on tree, but you must do them by hand in text editors (e.g. operations like "move to parent", "wrap this HTML element in new `div` element etc.).
I also want editor to be operable without keyboard/mouse switching. And because when I make websites I often use mouse to test in browser all functions, I want good mouse support and be able to change e.g. top from 0px to 10px using only mouse. This is possible in e.g. DevTools, why not to put this feature in editor?
> Edit: as I think about the idea, it would be awesome if I could click on
> any html element in a file and it would be able to statically analyze and
> show all applicable css selectors.
Yes. It would be nice, although I didn't solve this from technical perspective yet.
But for now I think about something like in Brackets - you edit HTML and could edit styles in place without switching to the other file.
These are some great ideas. There are little features in DevTools that I wish my IDE had (or I am not aware of the features if they do).
Be sure to post anything awesome you create to HN!
Be sure to post anything awesome you create to HN!
I'll do :) As soon as my editor is advanced enough to show.
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.
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.
Webstorm on OSX actually became more of a burden to use as my projects grew large. Excessive memory usage and crashing forced me to dump it in favor of Sublime Text. It's version history saved my butt a few times, but it was nothing that better Git habits couldn't solve.
WebStorm is pretty good already imo.
Some of those features are only possible because Java is statically typed. They couldnt exist in the same way for "pure" JavaScript.
But they can exist in a statically typed extension to javascript. See typescript in Visual Studio.
I've been playing with Typescript in both Visual Studio and Visual Studio Code and Intellisense is great.
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/).
That was the one, thanks.
I have never seen anyone successfully bolt type-checking onto an existing language. It is always painful to use. It usually requires ugly added syntax and you need a special compiler if the language isn't flexible enough.
Why not just use a different language altogether? One that was designed with static type checking from the ground up?
Maybe Facebook likes the pain, they also pushed PHP further than anyone else was willing to. Burning insane amounts of resources with a somewhat disappointing result.
Why not just use a different language altogether? One that was designed with static type checking from the ground up?
Maybe Facebook likes the pain, they also pushed PHP further than anyone else was willing to. Burning insane amounts of resources with a somewhat disappointing result.
Give Visual Studio a try (particularly v2015). It's pretty good at auto-complete at the very least. And you could still file tickets from it as well.
An IDE is not a fundamentally different thing from an editor, and certainly not a superior one.
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/
Esprima [1] is a full-featured and quite extensible ES5 parser, which has been used as the basis for a lot of the sort of analysis tools you're thinking about here. You might want to take a look at it, and at the software that's been written around it. In particular, there are several static analysis tools you might find of interest; I don't have a handy list, but searching "esprima static analysis" should find you plenty of candidates for further investigation. Refactoring tools shouldn't be hard to write, too, given an AST. (But I'd tend to suspect that automatic conversion from one framework to another is probably a pipe dream, at least for any nontrivial code base. Frameworks tend to come with too many mutually incompatible assumptions for that to be possible without an outright rewrite. Hell, that's even true of Angular 1.x and Angular 2!)
I'd be curious to know what you mean by "better", in your fourth bullet. I can think of a few things, but I doubt they're the same things you've thought of.
(And, while I have extensive experience with WYSIWYG HTML/CSS editors, that experience lies far in my professional past, because I found they were always too inaccurate to be worth the effort. Besides, it's not like there's anything particularly difficult about just viewing your changes in an actual browser; with tools like LiveReload, you needn't even go to the modicum of effort required to hit F5.)
What kind of codebase visualization would you consider "useful"? I think that's really the hard question to answer there; implementing a visualization is probably pretty easy, compared to coming up with a visualization from which you can easily derive information that's hard or impossible to obtain any other way. (I surmise this to be a difficult question based on the fact that no such visualization exists, or at least if it does it's not well known. Otherwise, it'd probably be part of the standard toolkit by now.)
[1] http://esprima.org
I'd be curious to know what you mean by "better", in your fourth bullet. I can think of a few things, but I doubt they're the same things you've thought of.
(And, while I have extensive experience with WYSIWYG HTML/CSS editors, that experience lies far in my professional past, because I found they were always too inaccurate to be worth the effort. Besides, it's not like there's anything particularly difficult about just viewing your changes in an actual browser; with tools like LiveReload, you needn't even go to the modicum of effort required to hit F5.)
What kind of codebase visualization would you consider "useful"? I think that's really the hard question to answer there; implementing a visualization is probably pretty easy, compared to coming up with a visualization from which you can easily derive information that's hard or impossible to obtain any other way. (I surmise this to be a difficult question based on the fact that no such visualization exists, or at least if it does it's not well known. Otherwise, it'd probably be part of the standard toolkit by now.)
[1] http://esprima.org
Yes, I know about Esprima. But I think it would be perfect library to create some more high level tool. Pure Esprima is pretty low-level (and JavaScript ASTs are pretty complex to traverse).
Angular 1.* for me was just an experiment full of accidental complexity and I am glad that Angular 2 will be more simpler.
If we talk about HTML/CSS I think that we need two different kind of tools (possibly integrated):
- structural editor of HTML/CSS that would be operate on tree nodes rather than text (my previous answer: https://news.ycombinator.com/item?id=9952022 ). That would allow editor to be smarter.
- WYSIWYG in browser (realised for example via plugin extension or browser itself) as a method for tweaking end results. I think about something like that: https://twitter.com/malyw/status/615974892928954368
Angular 1.* for me was just an experiment full of accidental complexity and I am glad that Angular 2 will be more simpler.
If we talk about HTML/CSS I think that we need two different kind of tools (possibly integrated):
- structural editor of HTML/CSS that would be operate on tree nodes rather than text (my previous answer: https://news.ycombinator.com/item?id=9952022 ). That would allow editor to be smarter.
- WYSIWYG in browser (realised for example via plugin extension or browser itself) as a method for tweaking end results. I think about something like that: https://twitter.com/malyw/status/615974892928954368
> something that would allow me to conduct massive scale refactoring
Here's an interesting tool for that: http://www.graspjs.com/ (structural search/replace)
Here's an interesting tool for that: http://www.graspjs.com/ (structural search/replace)
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.
Yes, I heard about Madge, but isn't it for CommonJS and AMD only?
You should definitely be looking at TypeScript.
Flow is also great.
Flow is also great.
I think it's good to note that you don't actually need a single one of these tools to make functioning software. You can pack your scripts with cat and download libraries with wget and use regular old JavaScript without transpilers. When you have a problem with this, you can use tools... But you don't have to top-load every project with a whole suite of complex tools just for the sake of it.
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 explanation of the "modern" tools. But it's also good to know that it's all optional and that you can start without them. It is entirely possible to make a modern web application with just a few plain JS files included with script tags. Yet people think the first step is to learn about half a dozen sophisticated tools that they don't even know why they need. So I say start with Notepad. Be aware that there are popular tools to improve your workflow... But also that sometimes the best workflow is the one you fully understand.
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 <script> tags.
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...
> When I see a complex build tool replaced with three lines of bash, that makes me happy
Amen to that! I think what I'm trying to say, and I suspect that we agree, is that there's the right tool for a job. Setting up a project to use 200mb of over-complicated npm modules and tools probably signifies the work of an inexperienced craftsman. Likewise, a non-trivial project built entirely from home-grown native Javascript may well run into complexity problems too as it re-implements features for which simple, well-tested and widely-used open source modules are available. Our desire for simplicity will lead us variously towards either of these extremes, and our experience tells us how to tread. We want our projects to be "simple", but that doesn't mean they're going to be "easy". The barrier to entry for frontend development is increasing in terms of developer capability, but that doesn't mean complexity is increasing, or that well architected projects that use modern tooling aren't simple.
Amen to that! I think what I'm trying to say, and I suspect that we agree, is that there's the right tool for a job. Setting up a project to use 200mb of over-complicated npm modules and tools probably signifies the work of an inexperienced craftsman. Likewise, a non-trivial project built entirely from home-grown native Javascript may well run into complexity problems too as it re-implements features for which simple, well-tested and widely-used open source modules are available. Our desire for simplicity will lead us variously towards either of these extremes, and our experience tells us how to tread. We want our projects to be "simple", but that doesn't mean they're going to be "easy". The barrier to entry for frontend development is increasing in terms of developer capability, but that doesn't mean complexity is increasing, or that well architected projects that use modern tooling aren't simple.
Yeah, I think it's a continuous tension in software development, and for various reasons I have a hunch that it's useful to kind of try to nudge the JavaScript world towards the appreciation of basic, stupid, non-fancy simplicity. Actually that's true for way more than JavaScript. I felt the same thing very strongly the last time I installed desktop Ubuntu... I can sometimes get slightly obnoxious in my nudging, because "moving parts" complexity irritates me on a visceral level. Which can lead to NIH syndrome... By the way, Nick Bostrom uses the term "infrastructure profusion" to describe a particular nightmare scenario of AI, and I think it's evocative, so I've started to think of human intelligence as prone to this profusion, too. A perfect example would be something like if you had problems with your multiple JavaScript build tools and so you started a new build tool project to coordinate all your other build tools... Call it something cool, like "Leviathan"!
Of course you can write code using cat but there is no good reason to do so. That would be like being a carpenter who refuses to use powertools and instead relies on manually operated ones. If you don't understand how to use the tools of the trade that will greatly improve your productivity, then you simply are not a professional.
You don't know that there's no good reason to do what I do. I use many different tools. Try ed sometime, it might improve your productivity. Professional? I deliver and get paid.
How about some specific examples instead of "I use `cat` and I'm right"?
>You don't know that there's no good reason to do what I do.
Exactly. Show us.
>You don't know that there's no good reason to do what I do.
Exactly. Show us.
What does it matter if I'm "right" about using a fundamental Unix command to enter text once in a while? What do you think I'm arguing, that cat is the best text editor and everything else sucks? Some guy said I'm not a professional even before I had a chance to give an example, which is rude and ignorant.
"No good reason to do so" is a bit strong, what about basic concatenation of two files when you're working at the command line `cat file1 >> file2` is much faster than anything else.
The OP may not be talking about editing files line by line.
The OP may not be talking about editing files line by line.
Well, you do at minimum need something that understands CommonJS modules, if you want to pack isomorphic code to run in the browser, so you need Browserify or Webpack.
And you need a module downloader that resolves and installs dependencies, so you need NPM and/or Bower.
And, if you want to write unit tests (which you should!) then you need a Javascript test harness, because otherwise you're going to have a bad time instantiating your modules and injecting mocks into them. You could do this in just plain Node, sure, but you'll end up reinventing a lot of wheels if you do. So you need Mocha, or something very like it.
But build tools are sort of a luxury, sure. You can get by just fine with make, if you already know how to use it. And nobody needs transpilers, except people who just don't have enough problems in their lives already.
And you need a module downloader that resolves and installs dependencies, so you need NPM and/or Bower.
And, if you want to write unit tests (which you should!) then you need a Javascript test harness, because otherwise you're going to have a bad time instantiating your modules and injecting mocks into them. You could do this in just plain Node, sure, but you'll end up reinventing a lot of wheels if you do. So you need Mocha, or something very like it.
But build tools are sort of a luxury, sure. You can get by just fine with make, if you already know how to use it. And nobody needs transpilers, except people who just don't have enough problems in their lives already.
> Well, you do at minimum need something that understands CommonJS modules, if you want to pack isomorphic code to run in the browser, so you need Browserify or Webpack.
No, you don't. These are optional. You only need these for larger applications that need packing.
> And you need a module downloader that resolves and installs dependencies, so you need NPM and/or Bower.
No, you don't. You can manually keep things up to date.
> And, if you want to write unit tests (which you should!) then you need a Javascript test harness, because otherwise you're going to have a bad time instantiating your modules and injecting mocks into them.
Okay, you probably do need this.
No, you don't. These are optional. You only need these for larger applications that need packing.
> And you need a module downloader that resolves and installs dependencies, so you need NPM and/or Bower.
No, you don't. You can manually keep things up to date.
> And, if you want to write unit tests (which you should!) then you need a Javascript test harness, because otherwise you're going to have a bad time instantiating your modules and injecting mocks into them.
Okay, you probably do need this.
> No, you don't. You can manually keep things up to date.
Sure, but there are better things I could be doing with my time.
Sure, but there are better things I could be doing with my time.
Your first 2 responses fit into this category:
> people who just don't have enough problems in their lives already.
> people who just don't have enough problems in their lives already.
Like any tool, the value of these tools becomes apparent only when the alternatives become inconvenient. If your workflows are simple enough that you don't need them, more power to you!
Also, while JS lib/framework fatigue is a very real thing, ever since I switched to React+Webpack, I haven't felt the urge to switch to the 'latest n greatest'.
They are a major milestone in the JS dev tools space, and a pretty safe bet for someone who just wants to pick something and not have to think about it afterwards.
Also, while JS lib/framework fatigue is a very real thing, ever since I switched to React+Webpack, I haven't felt the urge to switch to the 'latest n greatest'.
They are a major milestone in the JS dev tools space, and a pretty safe bet for someone who just wants to pick something and not have to think about it afterwards.
If you want to get started with this stuff but you're feeling lost or overwhelmed then the free SurviveJS - Webpack and React book is a nice place to start! It covers many of these tools. http://survivejs.com
Gulp is really great and better, than Grunt, but sometimes make seems to be a good choice that people forget about.
Yes, I feel like both Gulp and Grunt miss something fundamental that Make still has. I don't want to depend on other people's plugins for basic tasks and I want to only rebuild the stuff that changed. I tried Gulp with some 'notice if changed' plugins but it didn't seem to work so I end up sticking to Make.
Some of my Make build systems have gotten a bit unwieldy so recently I have been looking at using Ninja and ninja-build-gen from npm. This way I can still write my configure and my build tasks in JS/CoffeeScript and get to use a modern less cluttered version of Make that will scale well with the project.
Some of my Make build systems have gotten a bit unwieldy so recently I have been looking at using Ninja and ninja-build-gen from npm. This way I can still write my configure and my build tasks in JS/CoffeeScript and get to use a modern less cluttered version of Make that will scale well with the project.
Make doesn't work on windows. Its not cross platform, while Node, and all technologies built on top of it, are.
[deleted]
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.
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.
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 wouldn't help you there either.
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 wouldn't help you there either.
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.
It's a shaky foundation typically based on scraping text. 'its important and popular' is not a significant reason to add a language (or two in this case) to a project.
If writing everything in one language is your goal, then you are severely limiting yourself.
The beauty of Make is that it doesn't care what languages the scripts are written that it's running.
In my JS projects I typically have Makefiles that use a combination of: JS, bash and Python
If you compile NodeJS from source, guess what command you have to type in...
I feel being more open minded in terms of programing languages will make you a better and more powerful programmer.
The beauty of Make is that it doesn't care what languages the scripts are written that it's running.
In my JS projects I typically have Makefiles that use a combination of: JS, bash and Python
If you compile NodeJS from source, guess what command you have to type in...
I feel being more open minded in terms of programing languages will make you a better and more powerful programmer.
Except one of the most important ones.
Hermetic and 100% Reproducible builds. Sadly most of the Make replacements still haven't really solved that one either so your point still stands in a way.
Hermetic and 100% Reproducible builds. Sadly most of the Make replacements still haven't really solved that one either so your point still stands in a way.
I find it depends on the scale of the project. If I just need something to encapsulate my test runner and packing tool invocations, then I'll just toss those in a five-line Makefile, because why add a heavyweight build tool most of whose capabilities I'm not going to exercise?
I tend to agree that Gulp is better than Grunt. I prefer the code over configuration approach Gulp takes. The other benefits is that Gulp is streams based and will save you a lot of disk I/O over Grunt.
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.
How is that different from make?
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.
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.
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
https://github.com/williamcotton/makeify
Nice one! Thanks a lot
Same here.
It didn't just eliminate the use of gulp for much things, but also minimized the boilerplate I needed to get this stuff done in gulp.
Everything is just a "loader" away and doesn't need much configuration.
I even got rid of Bower for most libraries.
It didn't just eliminate the use of gulp for much things, but also minimized the boilerplate I needed to get this stuff done in gulp.
Everything is just a "loader" away and doesn't need much configuration.
I even got rid of Bower for most libraries.
Make can be good but can also be quite tedious/verbose to get started. I actually prefer using the npm scripts and using the binary files in `./node_modules/.bin/{ webpack, babel, etc }`
Takes no time at all and there is no interface that can break like in gulp or grunt
Takes no time at all and there is no interface that can break like in gulp or grunt
I too used to do this, until I needed more complex things, or am trying to find a bug in my code and have to make a few small edits, save, run `npm run build` then refresh my browser, make changes, repeat step 40 times in a 15 minute timespan.
Or I can create a couple gulp tasks (which honestly, is easy as heck) then a watcher using livereload, and run `gulp watch` then just be done with it.
Or I can create a couple gulp tasks (which honestly, is easy as heck) then a watcher using livereload, and run `gulp watch` then just be done with it.
The very good thing about module bundlers versus transpilers and task runners is that changing a single file doesn't result in a complete rebuild of the project; since the bundler maintains a model of the dependencies between files, it only needs to recompile the files that matter.
The downside is that now you have a whole other ecosystem of tool wrappers that tends to lag behind the tools themselves. They also tend to be JS specific, so if you have any other assets, you'll still need a regular task runner.
That's why I keep everything in JavaScript, including HTML and inline styles.
Another tool that becomes useful as your npm dependency list grows is npm-shrinkwrap. It is too easy to get large projects into a state that the existing developers can build and test, but break in production builds and for new developers. Being able to strictly version dependencies and control minor package updates can save you from debugging bad builds and losing new contributors. It's not a silver bullet, but can save you some frustration when packages deviate from proper versioning practices.
This a good overview of some popular tools for JavaScript development.
The thing that gets me about modern JavaScript development is the amount of modules you download to build your code. Currently I'm going through a PluralSights course for Gulp.js. Just to help me build and test my code, over 240MB of modules were downloaded. I'm starting to understand the benefits of all those modules. The thing that gets me is that the process makes you download all those modules again for the next project.
The thing that gets me about modern JavaScript development is the amount of modules you download to build your code. Currently I'm going through a PluralSights course for Gulp.js. Just to help me build and test my code, over 240MB of modules were downloaded. I'm starting to understand the benefits of all those modules. The thing that gets me is that the process makes you download all those modules again for the next project.
> This process is called transpilation and there are tools called transpilers which takes care of it for you.
The process is called compilation, and the tools are called compilers!
The process is called compilation, and the tools are called compilers!
Web scene likes inventing new words for old concepts.
In my opinion Ember JS is the best framework out there. It's instantly productivity and everything just works out of the box. No worry about tooling and such. If you are coming from Ruby on Rails or similar platforms, ember JS is your best bet.
Very useful. This will be required reading for all our students :)
I created a react/grunt/browserify/babelify (+bootstrap) starter repo to clone from github for them but think it's still confusing. This provides much needed background information in one bundled place (even though the stack is slightly different and only mentions grunt).
I created a react/grunt/browserify/babelify (+bootstrap) starter repo to clone from github for them but think it's still confusing. This provides much needed background information in one bundled place (even though the stack is slightly different and only mentions grunt).
That repo sounds like a good candidate for replacement with a Yeoman generator!
Yep pretty much a planned project but for now I'm keeping everything as sort of a learning exercise. master is ES5 and I have an es6 branch. The idea is to have students look at the ES5 version first to appreciate the ES6 changes.
[actually a basic git primer is the first step :D]
The more practical solution would indeed be yeoman (imo)
The more practical solution would indeed be yeoman (imo)
Does webpack started to be more popular than browserify?
I'm starting to see people talking more about webpack than the former...
I'm starting to see people talking more about webpack than the former...
The React world embraced WebPack after a modularity-kerfuffle back in January[1]. Pete Hunt followed that with his webpack-howto repo [2] which kind of turned the tide.
I really like Gulp/Browserify/Watchify/BrowserSync, but I'm starting to feel left behind and need to give WebPack an honest try.
[1]: http://blog.namangoel.com/browserify-vs-webpack-js-drama
[2]: https://github.com/petehunt/webpack-howto
I really like Gulp/Browserify/Watchify/BrowserSync, but I'm starting to feel left behind and need to give WebPack an honest try.
[1]: http://blog.namangoel.com/browserify-vs-webpack-js-drama
[2]: https://github.com/petehunt/webpack-howto
Reading the page then the comments, even as a senior developer who only touches JavaScript when necessary; I don't see much unification in the JavaScript world today compared to 12 to 15 years ago.
React seems to be a theme, if I want to develop a modern (is Web 2.0 still the term) single-page site (is that still a phrase?) using HTML5/CSS3/JavaScript...what environment exists that is cohesive and complete as either Eclipse for Java or Visual Studio for .NET?
Here's my answer, as an outsider, Java dude who only suffers brief interludes with JavaScript...I'd pick jQuery Mobile or DART.
The thing is...whenever these JavaScript tooling articles comes up I don't see those listed. I see names like React, Meteor, Gulp, Grunt, Webpack and maybe 3 dozen more.
React seems to be a theme, if I want to develop a modern (is Web 2.0 still the term) single-page site (is that still a phrase?) using HTML5/CSS3/JavaScript...what environment exists that is cohesive and complete as either Eclipse for Java or Visual Studio for .NET?
Here's my answer, as an outsider, Java dude who only suffers brief interludes with JavaScript...I'd pick jQuery Mobile or DART.
The thing is...whenever these JavaScript tooling articles comes up I don't see those listed. I see names like React, Meteor, Gulp, Grunt, Webpack and maybe 3 dozen more.
[deleted]
Lost in the Bazar...
A popular opinion seems to be that none of these tools are necessary-- if you don't use any tools then how do you write unit tests?
[deleted]
Bad. Please don't use any of these tools except if it is necessary. And it is not.
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 your page load times.
Write ES5 and time how long it takes you to complete projects of a given size.
Write reactjs code but use the JSXTransformer. Watch page performance. Watch how many times you reload the page in a given sitting.
It's really only when you find yourself with a problem that you can quantify that these tools start to make sense.
Discover for yourself why these tools exist or you'll waste a ton of time learning the newest thing and in the end not have gained much at all.