The Hitchhiker's Guide to Modern JavaScript Tooling
reactkungfu.com
reactkungfu.com
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.
Three exercises along the lines of the parent that I found particularly valuable:
1. Compare VanillaJS TodoMVC to your framework of choice
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)
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.
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.
Rather than blaming the user we should probably recognize there are quality problems that are the root cause of user confusion.
Good point. Another reason to be careful is that there are too many half-assed solutions to problems that might not even be real.
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.
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.
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?
[1] https://github.com/pluma/literalify [2] https://github.com/substack/insert-css/blob/master/index.js
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..)
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.
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.
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.
I haven't found a better IDE for any language yet.
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 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.
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.
Be sure to post anything awesome you create to HN!
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.
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.
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.)
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
Here's an interesting tool for that: http://www.graspjs.com/ (structural search/replace)
Flow is also great.
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.
>You don't know that there's no good reason to do what I do.
Exactly. Show us.
The OP may not be talking about editing files line by line.
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.
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.
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.
Sure, but there are better things I could be doing with my time.
> people who just don't have enough problems in their lives already.
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.
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.
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 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.
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.
Anything extra was very easily managed by some simple 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.
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.
Takes no time at all and there is no interface that can break like in gulp or grunt
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 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 process is called compilation, and the tools are called compilers!
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).
The more practical solution would indeed be yeoman (imo)
I'm starting to see people talking more about webpack than the former...
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
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.