Ahh, finally, a flow-based build system for Javascript. Now if they would just port it to NoFlow and hook it up to a GUI…
Grunt and RequireJS are out, it's all about Gulp and Browserify
51–60 of 163 posts
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#52This 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…
Interesting question, I feel that if you are good in a particular area (Say php / css / js / html) then you will find each new component / framework actually simplifies your life or makes it easier. The trouble is if you are more of a heavy js developer and are typically labelled as a web developer. Then you feel like you have to know about SASS (css) / HTML5 video standard / Scala and everything else related to the…
> I feel that if you are good in a particular area (Say php / css / js / html) then you will find each new component / framework actually simplifies your life or makes it easier.
I disagree. Frameworks/components are written by human beings; some are a good idea, others a bad idea, and any a complete mix. I would hazard a guess (stats was never my strength) that 50% of new frameworks are a bad idea and/or complicate matters down the road.
> I think that as web development grows and matures, it will finally have multiple experts who need to work together and with each expert having no problem in catching up or using the latest paradigm in their area.
We're there already. But the pace of change means keeping up is still an issue (esp once you have partner/family and don't want to spend evenings/weekends playing/learning) and actually you need to see across areas for some topics (front-end performance being one).
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#53This 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…
be realistic, this is akin to your team changing a few lines in a makefile,
sigh, javascript people,
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#54Author of gulp here. I've rewritten the example from the blog post to follow gulp best practices. https://gist.github.com/Contra/8780398
The code from the post is misleading/outdated.
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#55I've been using a different strategy lately: no explicit build process at all, just use middleware (like browserify) to automatically compile/compress/concatenate, and an HTTP cache in production to store the results (either middleware, or external such as nginx/Varnish/CloudFlare/whatever). This helps with the principle of minimizing divergence between development and production environments. It's worked well for me…
You can totally use gulp plugins outside of gulp. Since they are just streams, you can do some really cool stuff. I would love to see an http wrapper so you can do wrap(req).pipe(uglify()).pipe(res)
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#56This 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…
I am a full stack developer and spend a fair bit of time on the front end. Like you I feel a lot of this work will be made obsolete very soon but I am resigned to the fact because it has been going on like this for years.
I find the best strategy is to wait for wider adoption and hedge your bets. Gulp looks great but depending on the amount of time you can spend on it, it's best to wait for the ecosystem to mature (more plugins, more framework support, migration of existing Grunt plugins etc). I would give it another year or so because community migration can take time (backward compatibility, dependencies, endowment effect, etc).
The other thing that works for me is to adopt frameworks with a lower learning curve even it requires more manual plumbing. Plumbing is cheap and you can always refactor. Backbone JS was easy and I am looking forward to Riot JS because it has no learning curve as long as you have a good familiarity with writing robust JS.
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#57And 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.
Autocompletion of make targets in the shell.
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#58This 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'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 getting past 1.4.2 on our product. We have over 400 complicated web app pages that need testing to make sure we haven't broken any edge cases.
The learning curve is tough, the maintenance is tougher and the churn is terrible. It's a living hell on a large project. It makes me long for WPF or even Win32 where 20 years without significant reengineering is a good bet.
On the web, the basic DOM API is the most stable. Sacrificing convenience for maintenance these days is what I'm for. Screw the frameworks.
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#59This 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…
Full-stack dev that came up through the front-end ranks here - I'm in my early 30s and have been doing this in some form or another for 17 years. I started with Perl and C CGI scripts, worked with Java Swing (on the desktop) for a while, had a brief foray into MFC, did a whole bunch of PHP in college, switched to Django/JQuery while working on my startup, and now use a whole bunch of Google-proprietary techniques along with the native browser APIs.
I've found that the best way to stay sane is to ignore the hype. After having worked with a dozen or so technologies, I can say that knowing your preferred toolkit well matters a whole lot more than which toolkit you know. Nowadays I usually tend to prefer whatever is native to the platform (vanilla JS for web, Java for Android, Objective C for iPhone), because it will perform better, there are fewer opportunities for bugs to creep in, and you can access more of the platform functionality without waiting for frameworks to catch up.
It was actually uTorrent (remember that?) that caused a major shift in my thinking: before that came out I was all like "Yeah, frameworks! Developer productivity! I want to squeeze every inch of convenience out of my computer!", but then here was this program that was a native Win32 app, no MFC or Qt or Python or anything, and it blew the pants off the competition because it didn't use a framework. I didn't want to deal with Win32 at the time, but Web 2.0 was just getting started, and within a couple years I was doing a startup with Javascript games, and I found that if I wanted acceptable framerates in a game I couldn't use JQuery and had to learn the native browser APIs, and the difference between them was incredibly stark (this was pre-V8, when no browser shipped with a JIT, and I was getting about 2 fps with JQuery and about 15 with native browser APIs). And once I'd used the native APIs for a bit, I found they weren't actually that bad; they were more verbose and less consistent, but not in a way that seriously slowed me down.
I think it does take a certain amount of security and confidence in one's own abilities to do this, because it definitely makes you uncool. I've been in Hacker News threads where people are like "No. What the hell are you smoking?" when I suggest that you might not need a JS framework. But the folks who matter to me respect my abilities enough to pay me generously for them, and not staying up-to-date with the latest and greatest gives me time to cross-train in other fields like compilers, machine-learning, data analysis, scalability, UX design, management, and other skills that I've frankly found significantly more useful than yet another MVC framework. If I need to use a framework I'll learn it on the fly; I've done that for several projects, and (after I learned my first half-dozen MVC & web frameworks) it's never taken me more than a week or two to become proficient in another one.
Re: Grunt and RequireJS are out, it's all about Gulp and Browserify
#60Earlier quoted context omitted.
Believe it or not there are people in the world who aren't technical enough to use Grunt or Gulp, because they are much more complicated than Make... Mindblowing, I know.
Really no. The makefile syntax is obscure and hard to maintain. We've been there. We don't need to go there again. The stories of 'recursive makefile dependency hell' deserve to stay back in the dark ages of the 90s where they belong. There's a reason lots of people are inventing new systems for doing these sorts of tasks (for example, spawning a local webserver to work with after compiling less and coffee files and…
Yes, Makefile syntax gets somewhat obscure after the simplicity and power of target definitions and variables (e.g. http://mrbook.org/tutorials/make/).
Yes, Make does a poorer job at some of the tasks (although spawning a webserver process isn't one of them).
But I don't think having to write a plugin for EVERYTHING (http://gratimax.github.io/search-gulp-plugins/) is a sustainable answer.
P.S. I am sorry, I searched for "recursive makefile dependency hell", but I didn't find an explanation of what that is. It would be useful if you could provide some stories. I have been using Make only for two years, so maybe I haven't run into the exact problems yet.