Live data from Hacker News

Grunt and RequireJS are out, it's all about Gulp and Browserify

100percentjs.com

31–40 of 163 posts

Re: Grunt and RequireJS are out, it's all about Gulp and Browserify

#31

And just like that I have one more reason to ignore them both and use Make. Speed? Check. Simpler syntax? Check. No need to "fix" code that isn't broken? Check. No need to waste my attention on every new fad? Check.

Believe it or not there are people in the world who aren't technical enough to use stuff like Make, and are perfectly fine with using tools like Grunt or Gulp to get them through their days. Mindblowing, I know.

Oh, how I long for the days when condescension was a thing reserved for Lisp programmers.

Re: Grunt and RequireJS are out, it's all about Gulp and Browserify

#32
post #28

And just like that I have one more reason to ignore them both and use Make. Speed? Check. Simpler syntax? Check. No need to "fix" code that isn't broken? Check. No need to waste my attention on every new fad? Check.

Why even use Make? I just use shell scripts for automation. The only case where you really need the incremental behavior of Make is C/C++ builds (and arguably it's increasingly inappropriate for this domain as well). For all other kinds of automation I just use shell scripts, since Make is mostly a horribly reinvented shell script dialect.

Build utilities like Grunt or Gulp will be hopefully more compatible across systems than shell scripts will be. I'm not too familiar with Node's support on various platforms, but I'd wager that it's probably decent.

Gruntfiles and Gulpfiles are in javascript too, which lowers the barrier for entry for developers who aren't as versed in linux.

Is there a shell script equivalent to npm? Sidenote, that could be really useful as a service.

Re: Grunt and RequireJS are out, it's all about Gulp and Browserify

#33

And just like that I have one more reason to ignore them both and use Make. Speed? Check. Simpler syntax? Check. No need to "fix" code that isn't broken? Check. No need to waste my attention on every new fad? Check.

I've been using make myself. The main barrier I keep running into is that it's actually quite challenging to :

1. Use make/bash to work with things like JSON, mustache, images, markdown, less, sass, uglifyjs, etc. etc..

2. Do so in a way that is portable to even other unixish machines.

3. Why doesn't make provide an easy way to input a BIG LIST of files into a command? The choices (I'm aware of) are to put them all on one line, work out some wildcard (which doesn't work on arbitrary lists of files you need in a particular order), or--- have backslash escaped line endings! yuck!

nodejs isn't available in the debian stable packages repo. The available mustache command line tools are pathetically bad at this task (I had to write my own). I can make it work beautifully on my machine, but as soon as it hits my co-workers machine, the build breaks because they haven't installed pandoc, or ripmime, or whatever other utility I had to use to get things done.

So, I don't know, maybe I'm doing things wrong. But I haven't got this to work particularly well yet.

And uh.. windows. yep.

Re: Grunt and RequireJS are out, it's all about Gulp and Browserify

#34
I have no intention to throw out Grunt or RequireJS, just because there's a new hype about some new tools. It takes time to adjust things, and I'm perfectly satisfied with them as they perform now. Also I somewhat doubt that they are a 1:1 replacement.

Re: Grunt and RequireJS are out, it's all about Gulp and Browserify

#35

The one thing that keeps me from using browserify or webpack or the likes, is dev time debugging. It's not very useful to find that line 13729 of script.js threw an exception. Source maps may help, but many browsers don't support them, and I want to be able to debug everywhere. Plus, when the browserified js actually came from Coffeescript or TypeScript or the likes, I already have source maps in place. Can browserif…

Well, source maps are usually the solution for me. And yes, browserify supports source-mapping all the way back to coffeescript files using browserify-middleware. In the off case that I need to debug something in a browser that doesn't support source maps, you can turn minifying off and usually it is pretty easy to recognise the code you're inspecting, even if it comes from coffeescript. I've never had a case where I've been completely out of luck (usually this case only happens in IE).

Re: Grunt and RequireJS are out, it's all about Gulp and Browserify

#36
post #28

And just like that I have one more reason to ignore them both and use Make. Speed? Check. Simpler syntax? Check. No need to "fix" code that isn't broken? Check. No need to waste my attention on every new fad? Check.

Why even use Make? I just use shell scripts for automation. The only case where you really need the incremental behavior of Make is C/C++ builds (and arguably it's increasingly inappropriate for this domain as well). For all other kinds of automation I just use shell scripts, since Make is mostly a horribly reinvented shell script dialect.

Make is the easiest way to map all .foo input files to .bar output files and have the outputs only rebuild when the inputs change. This has a ton of applications outside of C and C++, really anything where the build takes time.

A shell script cannot adequately express task dependencies, or one that did would become a build tool like make. As it stands, make has a very simple and light syntax for expressing dependencies and has remained useful with little modification for quite some time.

Make isn't necessarily the best automation tool, but it's a great build tool.

Re: Grunt and RequireJS are out, it's all about Gulp and Browserify

#37
This is a tangential question, but how do front-end people feel about the constant change in the field?

I worked in the front-end and followed the trends for years and have found the changes difficult to follow. In 1997, the rage was VB and lots of cottage companies set up and advertising custom ActiveX widgets, on the web one had to learn ColdFusion and HTML/CSS. In early 2000's, VB6 was retired in favor of .net and a painful migration/learning-curve followed. Meanwhile, PHP was gaining traction so as a front-end person, one had to also start learning the LAMP stack in addition to asp and also CSS hacks to get different browsers to render mocks. Then around 2005ish is when AJAX/Web2.0 started gaining traction, one suddenly had to learn the burgeoning frameworks of the time, jQuery/Mootools/Prototype/Dojo/YUI/Sencha (at the time, no one knew which framework was going to win. I spent a lot of time on Dojo before moving to jQuery which started to gain the most traction); at the same time, web sockets still wasn't secure enough so there was also a lot of demand for Flex/Flash/Silverlight. Then around 2008-2009, when HTML5 started becoming more popular, Flex/Silverlight became obsolete; JS mobile frameworks such as PhoneGap and jQuery Mobile grew in favor but later in 2010-2011, they fell out of favor due to "responsive design" frameworks such as Bootstrap. Not to mention native mobile tech stack such as iOS and Android. In addition, around the same time, next-gen JS MVC built on top of jQuery have popped up such as Backbone.js, AngularJS and Ember.js and it's not certain who is going to win out this time in the year of 2014. On top of those, there are now JS AMD loaders (Require.js) and build/integration tools, Grunt that one needs to set up for a project which it seems may also be falling out of favor. Finally, new video/sound/web-socket standards revolving around HTML5 standards is demanding new learning bandwidth.

I'm frankly overwhelmed of learning and being exposed to new technologies. The physical draining feeling of learning new keywords to fulfill the same urges is as if I have watched 15 years of porn following from the grainy days of Jenna Jameson on VHS to the heady-days of Internet dial-up gonzo porn of the early 2000's that really explored anal (Gauge, Taylor Rain) to the streaming flash videos of Web 2.0 (Sasha Grey) to the now completely splintered and social-mediafied porno-world with all the mind-numbing categories under the sun (reality, high-art, webcam etc). I'm simply drained and spent.

There certainly has been changes in the field in back-end, from Java applets to Spring and Struts to now Scala and Clojure on JVM or transitioning the scripting language from Perl to Python, and adoption of Boost in C++. But I didn't have to re-learn old concepts and the changes were incremental instead of revolutionary; and the whole shift from declarative programming to functional languages is not new as you've learned Haskell/Lisp in undergrad anyways. Whereas what I had learned as a 9 year old on Turbo C doing DOS programming would still apply today, what I learned then for VB4 and HTML/Frontpage is now completely useless.

I'm scared for my brain as I get older as I may not have the time nor the energy to devote myself every year to relearn all of these new tech. I'm wondering for people who are above the age of 30, how do you deal with it?

Re: Grunt and RequireJS are out, it's all about Gulp and Browserify

#38

The one thing that keeps me from using browserify or webpack or the likes, is dev time debugging. It's not very useful to find that line 13729 of script.js threw an exception. Source maps may help, but many browsers don't support them, and I want to be able to debug everywhere. Plus, when the browserified js actually came from Coffeescript or TypeScript or the likes, I already have source maps in place. Can browserif…

Unable to find the link/name at the moment but there is a method (it isn't vanilla source-map) for this which basically wraps the modules into self-executing functions and it shows up in Firefox and Chrome as distinct files. It was related to source-map but not

However, I have found Chrome and Firefox's support to be buggy.

Re: Grunt and RequireJS are out, it's all about Gulp and Browserify

#39

And just like that I have one more reason to ignore them both and use Make. Speed? Check. Simpler syntax? Check. No need to "fix" code that isn't broken? Check. No need to waste my attention on every new fad? Check.

Well, to be fair, make and browserify do completely different jobs. You can't substitute browserify for make, nor vice versa.

But to be honest, if you see learning new things as wasting your attention on new fads, I don't think this stuff is for you. I really like trying new things that people have made and seeing what they can do. If that feels like a chore/hardship to you, you absolutely should just keep using make.

Re: Grunt and RequireJS are out, it's all about Gulp and Browserify

#40
post #17
post #14

One tiny benefit of Gulp - Grunt wasn't packaged on Debian because of JSHint which relied on JSLint which had the "The Software shall be used for Good, not Evil." licence clause http://en.wikipedia.org/wiki/JSLint

The people in that Debian thread[1] completely misunderstand how Node packages work - the 'jshint' dependency is in the 'devDependencies' section of the package, which means it is not installed by default when `npm install --production` is used, which is how it should be packaged in the first place. Refusing to package Grunt for Debian because it has a devDependency on JSHint is like saying that Node can't be package…

> Regardless, it's not a big deal to `apt-get install nodejs; npm install -g grunt`.

Unless of course you have automated the installation of software on your systems. At this point it's somewhere between confusing, mildly annoying and terribly annoying, depending in what route you go.

You could make a Debian package yourself, or you use your configuration management system to install the npm package (assuming it supports npm or there is an npm plugin)

Both have disadvantages: there are tools to automatically create debs from npm packages, but I've seen bugs with them causing various levels of pain. Or you make the package yourself and get blasted by full-on bureaucracy that is the Debian package build tool chain.

Going the configuration management route has the disadvantage that now multiple pieces of software are used to install packages which is a bit inconsistent and might be confusing to other users.

Yeah. Not a big deal, but getting stuff directly from your OS vendor is VERY convenient.

I agree with your reasoning about the devDependency though. That makes not much sense.

Post reply on HN