Gulp is really great and better, than Grunt, but sometimes make seems to be a good choice that people forget about.
Make doesn't work on windows. Its not cross platform, while Node, and all technologies built on top of it, are.
The Hitchhiker's Guide to Modern JavaScript Tooling
71–80 of 120 posts
Re: The Hitchhiker's Guide to Modern JavaScript Tooling
#72Earlier quoted context omitted.
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 'innova…
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.
Re: The Hitchhiker's Guide to Modern JavaScript Tooling
#73"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…
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?
Well the question is why bother with those other tools if one tool (Webpack) can do everything you need?
Re: The Hitchhiker's Guide to Modern JavaScript Tooling
#74Earlier quoted context omitted.
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 '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 wouldn't help you there either.
Re: The Hitchhiker's Guide to Modern JavaScript Tooling
#75"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…
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.
Re: The Hitchhiker's Guide to Modern JavaScript Tooling
#76Earlier quoted context omitted.
> * 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 ( 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 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 )
Re: The Hitchhiker's Guide to Modern JavaScript Tooling
#77There 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
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)
Re: The Hitchhiker's Guide to Modern JavaScript Tooling
#78A 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?
Re: The Hitchhiker's Guide to Modern JavaScript Tooling
#79Earlier quoted context omitted.
> 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…
> 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.
Like debugging broken build tools? Or what about inter-tool incompatibilities? Those are always fun to figure out.
Re: The Hitchhiker's Guide to Modern JavaScript Tooling
#80Earlier quoted context omitted.
> * 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…
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.