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?
I agree, I can't keep up, I just finished learning backbone.js and now I've
found out on HN that it's old news, and I should use ember.js, cross that, it
has opinions, I should use Meteor, no, AngularJS, no, Tower.js (on node.js),
and for html templates I need handlebars, no mustache, wait, DoT.js is better,
hang on, why do I need an HTML parser inside the browser? isn't that what the
browser for? so no HTML templates? ok, DOM snippets, fine, Web Components you
guys? yuck, oh, I just should write it with CofeeScript and it will look ok,
not Coffee? Coco? LiveScript? DART? GWT? ok, let me just go back to Ruby on
Rails, oh it doesn't scale? Grails? Groovy? Roo? too "Springy?" ok, what about
node.js? doesn't scale either?? but I can write client side, server side and
ok, what about PHP, you say it's not really thread safe? they lie?? ok, let me
go back to server coding, it's still Java right? no? Lisp? oh it's called
Clojure? well, it has a Bridge / protocol buffers / thrift implementation so we
can be language agnostic, so we can support our Haskell developers. Or just go
with Scala/Lift/Play it's the BEST framework (Foresquare use it, so it has to
be good). of course we won't do SOAP and will use only JSON RESTful services
cause it's only for banks and Walmart, and god forbid to use a SQL database it
will never scale
I've had it, I'm going to outsource this project... they will probably use a
wordpress template and copy paste jQuery to get me the same exact result
without the headache and in <del>half</del>quarter the price
http://www.zemanta.com/blog/i-bet-you-over-engineered-your-s... (2 years ago, in the comments)
https://news.ycombinator.com/item?id=5206578 (1 year ago)
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.
But props to a pun-intended use of the word "spent".
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.
I have a firm suspicion its what writing a framework, cms, or blogging platform used to be.
In time the leader will show itself and people will get the message that this project is no longer fun and trendy.
I have to agree makefiles are pretty much the be all and end all when it comes to building projects. It offers pretty much all the power you could need.
The only plausible reason for makefiles to not be suitable for a culture brought up on shiny macbooks and "GUI's" would be that not many people want to deal with the complexity which comes from having that much power.
Take this for example. Its pretty hard to look at let alone understand. That scare is probably reason enough alone for a bunch of wheel2.0s to be created. The 183 page plain text manual doesnt help much either. Its too daunting for today's culture.
Its just not about being correct and feature complete anymore, its about having the path of least resistance. Simple makefiles are simple, but nobody upvotes a hacker news article about how amazingly easy makefiles are.
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 are still actively learning, all this new stuff starts looking very much like mere variations of old things.
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.
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.
Reading your comment I get the feeling the impression that testing these pages is time consuming and difficult.
What kind of QA automation do you have in place?
Devote 2% of your time and try out some of the things once in a while; don't bet on them but at least be a small part of the community which will make them either better of fail.
One mod: 5 years is a very long time in this space. Node itself is but 5-years old.
Couple years ago when Google+ was the new kid on the block, I made a tiny userscript that hooked into their DOM and cleaned the UI up a bit. You'd think this was an easy task and you'd be right except it was quite a pain in the rear to maintain the extension. Google kept changing the classes and IDs, and moved the DOM around so frequently (sometimes within hours of the previous change) that my extension was constantly broken, and all my time was spent tweaking my code to keep pace with the changes propagating from an entire team of Googlers and their automated commit bots. It wasn't long before I gave up on the effort.
Following front-end trends today feels exactly like that experience; there's a whole host of prolific authors, even teams, coming up with new approaches for almost every nut and bolt in the stack. I think for the time-constrained it's best to wait for the wheat to rise above the chaff, even it means falling behind the curve a bit.
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.
Other than a simple declarative API for all of your build tasks and a huge ecosystem of tasks.
Grunts clarity has a ton to offer. With Gulp, while there are some speed increases, that clarity and DRY mentality disappears.
I think JS is an interesting case study as well because it's historically with such an impoverished standard library/distribution.
One thing that comes to mind is cross-platform builds, which in some scenarios is very useful.
What a heavy wrapper. ;-)
In general I think we're heading towards better things... you just have to watch out for the warts along the way.
I deliberately hang back on investing time in something unless it's immediately, drastically simpler than what's there now.
- My 47-line Gruntfile became a 23-line gulpfile, and I understood it better, so I learnt gulp.
- I don't see any huge advantage in using browserify, just syntactic difference, so I'm sticking to RequireJS right now.
- After reading about ractive and how simple it was (have an object, have a mustache template, you have bindings) I started using it in place of Angular.
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.
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.
No. The goal is to find the right abstractions - the right libraries/frameworks/patterns etc. If your tools end up costing you time then the tools are flawed - not the concept of using tools.
I'm simply saying when we have better way to package up software on the frontend there will be less reliance on monolithic libraries and frameworks, the right abstractions will be easier to write, find, and maintain. One of the greatest things about Unix is the modularity and compose-ability and Node.js adopted that philosophy, that's why I recommended Browserify and Component. They are a way to package and distribute the abstractions you speak about.
In a world where people relentlessly defend good enough (generally, engineering advice on HN is often straight-up amateur hour), it's telling that great sometimes requires abandoning the tools that hipsters clamor for.
All you need is a great UI design, good architecture, and a keen eye for details.
For what it's worth, we're about to go through another generational shift in frontend tech. There are a few major developments in the pipeline: ES6 generators and Web Components. Generators allow for different async flow control patterns  which greatly changes the feel when writing JS. Component systems (Ember, Angular, Polymer, React) offer significantly improved state control and huge code savings. If you aren't already using one, you will be in the near future but it's still early enough that it's unclear which will come out on top. There's a set of emerging standards work around enabling self-contained Web Components (shadow DOM, template tag, scoped CSS) but these don't dictate how you structure your code so there's still room for conflict.
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.
Look, there will always be a new tool|library|framework|language|paradigm that is cooler and better. If you pick the coolest language available today, you will be "so 2014" in a few years.
We need to be more pragmatic and use the tools that make our mission easier. Sometimes that mandates a complete rewrite in a new language|framework, but that is rare.
What the article calls "revolutionizing" is really not that big a deal. Maybe it makes things a bit easier, faster, prettier -- but it won't make or break your company.
For this OP, the move from grunt to gulp for instance is a simplification of the build process. It requires some refactoring of the build process, but shouldn't impact the application code, the two libraries can coexist (not cooperate I guess, but at least you can set up both and use one or the other as you want), and can be tested with simple use cases first and expanded to the whole app afterwards.
The barrier to entry is low, it doesn't require much commitment and can be done on the side. I'd try to keep up as much as possible with new available tools, as long as they match the above criteria.
For libraries and frameworks closer to the UI and application structure, I have the feeling they generally need more time to pickup, learn the strengths weaknesses, deal with the quirks and bugs. Even with reasonable documentation, most of them seem to need at least a few dives into the source code to really get how they work and what they expect to be doing.
Trying Ember or Angular on a somewhat realish project takes enough time to make it a chore to try a few alternatives, I'd guess most devs would want to wait months or years to see which libraries die in infancy. I think for this space, trying more than one or two picks here and there a few months apart is just insanity, except if you really enjoy it or it's part of your job. As time goes by I feel the timespan I wait for something to see if t sticks goes longer. I remember a Jeff Atwood post , about how ruby is now mature enough to be taken seriously.
I think the same thought process can be applied to big enough frameworks.
Personally I'd tend to go for the libraries that are simpler or with the least 'magic' to avoid getting in situation where I invested weeks doing something and there's bug I don't know where it comes from and need to spend days on it because of the amount of abstraction going on. That's a way to mitigate risks when trying out random libraries.
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.
I would recommend you specialize / try and learn whatever you are good at.
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).
My analogy is one of the best in the history of ill-advised programming analogies, the more I think about it the better it gets (of course it may be lost on people who aren't mountain biking full-stack developers). Your comment on the other hand doesn't have a snarky leg to stand on.