[deleted]
Grunt and RequireJS are out, it's all about Gulp and Browserify
71–80 of 163 posts
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#72I still prefer bash scripts.
And I think Gulp is much more complicated than necessary for 90% of the builds out there.
My 'bild' module is simpler for most things. Although I will stick with bash.
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#73Hmm, i don't see much difference in configuration between grunt and gulp.
Both do the job.
And Performance? Which Performance? They call tasks that do something, and the task need performance.
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#74This 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…
It drives me nuts. I spend probably 1/5 of my time doing front-end (but have been around through all of the generations you mention) and after re-org after re-org I've finally settled on a build system with a Makefile and browserify to package things up that isn't an enormous monstrosity of 1000 different node packages and bajillion-step build progress.
Frankly, I think that a large part the problems in front-end have to do with how hard it is to write maintainable JS w/ a proper separation of responsibilities, due to the way JS files are loaded/have no coherent module system (on the front-end that is). Because there is no standard module system (and yes I know about CommonJS and AMD loaders, but both have issues), to use a given component you oftentimes have to adapt an entire philosophy of package management that can lock you out of other packaging philosophies. In the end, we have millions of front-end programmers saying, "eh it seems like to much work to integrate this packaging philosophy, I'll just write my own duplicate copy/library." So basically projects silo themselves off and share little code until someone decides on yet another package philosophy (see: http://xkcd.com/927/).
People love to write build system after build system, in every field, a fetish I've never quite understood. Makefiles build some of the most widely used/complicated packages out there.
And as a final note, I'm really excited about emscripten in allowing front-end developers to move away from designing abstractions around JS/DOM in such a way that eventually we can stop relying on JS and rely on more the same primitives we use everywhere else in programming.
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#75This 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…
There's a few things going on here that combine to cause this mess.
First, task runners, like templating systems and module bundlers, are easy to write so there are lots of them. Grunt in particular doesn't bring anything to the table that bash scripts don't.
Second, most open-source projects don't make their value prop clear (I learned this the hard way first-hand and I'm still dealing with it) and most people don't have a good rubric to evaluate technologies so they fall back to crappy ones like gzipped size, number of dependencies, or the twitter account of who wrote it. Increasing the level of understanding of performance and how system complexity evolves over time is an important next step for the community to take.
For example I think the excitement around Gulp is legit because the tasks are composed as in-memory streams which is a scalable way to build a performant system. Browserify not so much, since it doesn't bring anything new to the table except maybe that it's so damned easy to use ("philosophy" does not count as bringing something to the table). Webpack, on the other hand is a whole different story since it accepts that static resource packaging (not just single-file JS modularization) is a problem that needs to be tackled holistically and necessitates a certain level of complexity.
I named specific projects not because I have any vested interest in them (I don't really use Gulp for anything) but because I wanted to show concrete examples of how to evaluate technologies on real merit.
Finally, the web frontend community has a huge problem with NIH (not-invented-here) syndrome which is encouraged by npm. For example, there are lots of copycat data binding systems that claim to be "lightweight" or "simple". They're usually written by people that don't know about all of the important edge cases which necessitate certain design decisions or library size. It goes the other way too -- a lot of people are building monolithic app frameworks without doing due diligence on existing systems to see if they can be reused.
If we can slow down and try to respect what others have done and acknowledge what we may not know, I think we can fix this problem.
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#76This post reminds me of the joke about the Native Americans getting ready for winter[1]
[1] http://voices.washingtonpost.com/capitalweathergang/2008/11/...
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#77This post reminds me of the joke about the Native Americans getting ready for winter[1]
[1] http://voices.washingtonpost.com/capitalweathergang/2008/11/...
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#78Earlier quoted context omitted.
It's all just marginal convergence towards "best", and in real practice, most of this "progress" can and should be ignored. For every tool, wait it out until it's been around and still in active use/development/maintenance for at least 5 full years. But always stay playing. Always try out the new things, because some of them may just scratch a burning itch. Fear not age, because if you've been around long enough, and…
Perhaps I'm just rusty but age has only made me cautious. I'm responsible for a rather large and complicated UI framework that we use internally. The thing I've discovered over the last 5-6 years is that APIs are volatile as are JavaScript libraries, browsers and security concerns. It's terribly hard picking something that you can rely on. Even jQuery has enough breaking changes for me to have a week long task gettin…
The problem with the frameworks is the very definition of the word. Not every problem/process fits in the workable frame, and then you end up with a pentagon shaped framework with dingles off the end, and nobody knows what the hell you did except you. Better to just write straight prototype OOP and use a preprocessor thatll add KVO to accessors/modifiers if you really need events (which most apps do.)
Emscripten is good for that. And there are many languages that have KVO that will compile to JS using emscripten. Really, JS isn't ideal for large projects, and these frameworks are silly, because they're targeting this lowly base for UI when a better language with better standard libs could be used to do lots of the logic, ie. Clojure.
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#79I'm still not sure what browserify really adds over concatenation. Never noticed any speed increases, I guess the one thing would be explicit dependencies, but I've always found you can do that with module patterns anyway, and it breaks half the libraries you want to use.
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#80Hmm, i don't see much difference in configuration between grunt and gulp. Both do the job. And Performance? Which Performance? They call tasks that do something, and the task need performance.
Typical build may look like this: Task 1 passing many files to Task 2, then to Task3, concatenate and so on. It's all about Disk I/O performance. Streams piping reduce files reading/writing.