8 ms·

How to Pick a Front End Web Framework

78 points by g4k 11y ago

galfarragem 11y ago
IMHO, as an outsider, I reduce the less risky choices to 3: - javascript -> meteor + react - whatever language -> whatever language most popular framework + react - ruby -> elixir -> phoenix + react Feel free to criticise.
andrew_wc_brown 11y ago
I use MithrilJs with Coffescript. Small and Fast.
- naknode 11y ago
  What about RuniteJS? Or maybe AdamantJS? I still use Browserify for almost everything.
RodericDay 11y ago
Need to do something? Have a framework! Here, more frameworks. Frameworks for everyone!
woah 11y ago
Why would you want to include grunt or gulp? Shell scripts do the job just as well and can be run from npm. Bash is streaming, parallel etc etc. You can do everything you want with &, &&, |, and >
- andy_ppp 11y ago
  Do you have a demo repo so we can learn from this, sounds pretty great. How do I watch files with bash and recompile changes (for example)? I'm certain it's all possible, and while grunt and gulp have lots of examples I never really like them.
  - techterrier 11y ago
    Here's a couple of articles if you are interested in the gulp free approach: http://blog.keithcirkel.co.uk/why-we-should-stop-using-grunt/ http://blog.keithcirkel.co.uk/why-we-should-stop-using-grunt... http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/ http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool...
  - idonthaveaname 11y ago
    The Keith Cirkel articles, mentioned earlier, are great. I also found this one, today: http://beletsky.net/2015/04/npm-for-everything.html http://beletsky.net/2015/04/npm-for-everything.html It's less detailed, but also shorter and easier to digest.
- paulojreis 11y ago
  My shell scripting skills aren't really that good. I feel that this might be true for most front-end developers. A JS based task runner is nice for me, as a I can harness the language I use on a daily basis (as well as the community with jobs similar to mine). Maybe if I used more bash than JS I would have a different opinion. Language preferences/fluency aside, I feel that there's much to gain from the JS "hash-based" way of expressing objects which are used as configuration objects (which can be dynamic) in task runners. I'm not aware of an easy alternative to this in shell scripting, but this is probably due to my ignorance on the subject).
- freshyill 11y ago
  Yeah why would anybody want to use this convenient thing thing when you could just write some shell scripts.
- dimgl 11y ago
  Up until recently I would not have agreed with you. However, recently I've skipped on Gulp and Grunt and it has helped me with various things: * Saves me time so I don't need to figure out why a Gulp/Grunt script is behaving erratically, such as a watch that crashes even though exceptions are being caught for it * Reduces my development depenencies, which helps with the following two things: * There's less of a chance that there will be a package that needs to be built that will crash and burn on Windows * I don't need to download a shit ton of stuff from NPM every time I clone from Git * Helps me think about my architecture critically as I don't want to do anything too complicated outside of Gulp/Grunt * I don't need to wait for someone to make a plugin for a test runner
- tehbeard 11y ago
  Can shell scripts do the same job? yes. Do I want to deal with writing the code / instructions to: * Explain how to setup/install the build tools. * Account for differences in shell env. * Explain to windows users to get cygwin/whatever, or make a separate set of scripts for them. No. Grunt/Gulp have the benefit of having a consistent cross OS package manager (npm), in a language that the coder is likely to be familiar with should they need to tweak it.
rco8786 11y ago
How did this even make the front page? There's nothing of value here.
- nickthemagicman 11y ago
  As a person not very experienced with JS there's literally no where that I know of that combines and explains modern day JS infrastructure.
  - Diederich 11y ago
    Agreed. I'm a backend person who ends up writing UI from time to time, and this kind of material is gold.
jevgeni 11y ago
> Full Stack EngiNerd. I use magic to make IT things work and keep people happy. Keeping people happy is a good thing[1]. But all those words make me cringe so hard. -- [1] - unless they are serial sex offenders.
- sotojuan 11y ago
  If that kind of bio bothers you, stay away from Quora :-)
  - jevgeni 11y ago
    I've trained myself to mentally block those on Quore, like I've trained myself to mentally block ads.
- andrewl-hn 11y ago
  The author is a non-native speaker. I doubt there's anything behind this bio except a wordplay.
  - jevgeni 11y ago
    Yeah, it's just goofy. But feels ... overused?
- netaustin 11y ago
  Cringing was my main reaction too, but it was more about the use of the "all the things" meme and the "kitchen sink" advice. Clearly the author is a very smart guy, but he seems to be in early-career discovery mode. What I want my early-career developers to learn is to be great at one or two core things, not to throw a dozen hot new tools at every problem.
  - jevgeni 11y ago
    Yeah. It kind of reminds me of photography: when people just get into it, they tend to be obsessed with all the different gear, until 20 years later they are content with a simple manual view-finder camera.
paulojreis 11y ago
I liked the article, but there's something I need to point out regarding CSS preprocessors. It's way more important than making CSS "a bit better". Preprocessors allow you to achieve modularity and DRYness. They allow you to move the object-composition duty from the browser to the build process - hence avoiding overloading the browser with composition (i.e. composing a class with SASS mixins or extends, instead of plugging many classes in a single HTML element). They allow you to easily express relationship through class names instead of relying on DOM hierarchy (separation of concerns). And, obviously, they allow variables! Common and centralized palettes, sizing definitions, typography definitions; also, "computable" definitions (e.g. deriving a shades/tints palettes via the built-in color management functions, or computing a typography scale from a base size). If you have the time to learn CSS and a preprocessor adequately (and think about how to tackle common architectural issues having these characteristics in mind, isntead of borrowing solutions from e.g. OOP), then you might have clean, elegant and maintainable CSS (instead of a hairy jungle of rules that nobody in your team would want to mess with).
- intruder 11y ago
 Do you have a resource for the last point you mentioned?
 - paulojreis 11y ago
 Not exactly, it's something I've been noticing from my experience with CSS and many teams with many members which were experienced programmers but without any CSS experience. I've shared these ones with my team, however: http://philipwalton.com/articles/css-architecture/ http://philipwalton.com/articles/css-architecture/ http://philipwalton.com/articles/side-effects-in-css/ http://philipwalton.com/articles/side-effects-in-css/ http://philipwalton.com/articles/extending-styles/ http://philipwalton.com/articles/extending-styles/ http://benfrain.com/the-ten-commandments-of-sane-style-sheets/ http://benfrain.com/the-ten-commandments-of-sane-style-sheet... P.S. A good heuristic I'd like to point out (and hard-code in any CSS newbie's brain) is that if you're relying on DOM structure (e.g. styling X if he is a descendant or sibling of Y), then you're doing it wrong. Very, very few exceptions to this. Structure (HTML) is a different concern than styling (CSS) and it might change frequently; it should have minimal impact on styling. P.P.S. Another good notion is that CSS is truly like Tetris. Errors do pile up. If you are over-specific when defining a selector, soon you'll have to do a even-more-specific one to override it. If you are too confident and define a leaky rule (e.g. all `` elements inside a given widget), soon you'll have to create code to override it.
sgdesign 11y ago
Rather than evaluate every framework under the sun to try and find the one that's perfect for your specific situation and needs, I would probably focus on finding something that's widespread, well-documented, has a lot of momentum behind it, and an active community. Right now that would probably be React or Meteor.
- mattmanser 11y ago
  Seems odd to include Meteor, which is pretty controversial and might never take off, but not Angular, which has much, much higher usage than both of those two combined.
anjc 11y ago
I hate modern Web dev so much.
- sotojuan 11y ago
  This is something I've struggled with... most of the stuff I do is in JavaScript and I think the web is cool, but I hate most modern bloated websites and prefer simple text-based ones (like HN!).
- lojack 11y ago
  I love it. It wasn't even that long ago that I used to spend countless hours building everything with the sliding doors method and doing weird hacks to make things work in IE6 or (gasp) IE5. There was a lot less to know, and things were certainly simpler back then, but it was also extremely tedious. Nowadays I can focus my effort on problems that are actually interesting. There's been an explosion, and with the variety, things have gotten complexed. I understand that it can be cumbersome to those entering the field, and a lot of the time it's total overkill for the problem. But... once you get over the hump, there's now a lot of really cool shit you can do on the web that was completely unrealistic or unimaginable just a few years ago.
  - anjc 11y ago
    Do you not find that you spend far more time now wrangling with new implementations of new frameworks for new concepts, only to discover later that you should've researched more, because you have a problem which an even newer implementation of a newer concept has solved and blah blah blah. The amount of time I've wasted in my life learning things to keep up with Web dev trends...
    - at-fates-hands 11y ago
      Came here to say this. Frameworks are great, but you have to spend a lot of time wading through the documentation and architecture. Why this is different than that framework and why this does something different than that framework, and why this framework solves something this other framework fucks up. For a time I just started putting together my own stuff and then realized it was so custom, it was totally useless outside of a particular project. I've come around a little bit, but its frustrating when the whole industry jumps on a bandwagon, promotes the shit out of it and then some time later, they're onto something else and the cycle repeats itself. The best example for this is Backbone. It was one of the first JS frameworks I started fooling around with, along with Node and Express. Everybody thought this was the greatest thing ever. Now, less than a year or so after I first started dabbling with it, you can't find anybody still talking about it (even though its still a rock solid framework). Everything is now Angular, React and various other shiny toys. I would say the same thing about Knockout. People thought this was the next big thing, and now I can't find anybody promoting it anymore.
tdees40 11y ago
I'm unique in that I've never done any web development whatsoever (all my work is in finance and HPC), so I know zero Javascript, no CSS, and only the most rudimentary HTML. This article reminds me why I stay away from the web dev space.
deleted 11y ago
[deleted]
onewaystreet 11y ago
Or skip all that and go use React and Webpack.
- dimgl 11y ago
  How about...no...? React isn't the solution to every problem.
  - mawburn 11y ago
    Not with that attitude it isn't.
- weavie 11y ago
  No. It's Clojurescript and Om you should be using.
- ryanSrich 11y ago
  Does the React + Webpack stack essentially give you all of the same functionality that Angular does?
- josai 11y ago
  React is a library, not a framework. What's your router? What's your model? What's your buildchain, how do you deploy, how do you do ajax requests, etc etc etc? Facetious comments like this help nobody. There's not a site in the world "just" using react + webpack. And I say this as someone who works with a react and webpack site.. oh and backbone, and gulp, and rsvp, and requirejs, and another 70 lines in package.json.
onion2k 11y ago
No matter how good you are now, your code when you've spent a year with a framework will be better. Consequently you should pick a framework (or language, or tool) and stick with it until you actually have a good reason to move on to something else. The benefits of jumping to whatever someone else recommends because they claim their choice is better for X, Y and Z reasons are likely less than the benefit of your own experience with a framework you've learned and understand. 90% of the speed of your code in terms of both writing and execution are a function of how well you write it, not the libraries you're using. Writing better code comes from practising (and thinking).
- mr_mig 11y ago
  To be honest, I think the person who has spent a year with a framework and who is ok to use it on a day-to-day basis won't simply trust a random guide in a random blog.
gotchange 11y ago
I find it odd that he didn't include Jade in this long list of tools and technologies of modern web development as it's IMO the best tool hands down out there when it comes to HTML modularization/componentization and I can't imagine now developing websites or even web apps without it in my workflow.
ryandrake 11y ago
As someone with an embedded C and C++ background, I have to admit, the world of web programming seems bewildering and alien with all its frameworks and workflow engines and module bundlers and virtualization and containers. Does anyone even write code anymore, or has web programming simply become a systems integration problem? It's a testament to how awesome and diverse this field is that you can take two people, both think of themselves as professional programmers, and chances are each will be mystified by what the other person does day to day.
- porker 11y ago
  > Does anyone even write code anymore, or has web programming simply become a systems integration problem? Now we program in frameworks, not languages. The language just happens to be the framework's chosen expression.
- mrits 11y ago
  I almost think the author's intent was to show all the different things he knows about. There isn't too much difference in the tools in this list than what you use everyday. The problem is they aren't bundled together and the flexibility adds to confusion. Package management, compilers, linkers, nothing new.
- baldfat 11y ago
  I still believe that web programming is one giant hack built upon other hacks with a right and "wrong" (hack) way to implement everything.
deltaprotocol 11y ago
After reading the article I think what the author meant is: How to get even more confused with the insane plethora of Front End stuff out there and give up life. But I can't blame him. I've also tried to create lists, to reason it all. Several times, and to no avail. One thing he got right, an image at the very beginning with the word chaos in the middle. Good luck!
awjr 11y ago
The way I chose in the past. Use a jobsite (in my case www.cwjobs.co.uk). Type in framework. Count number of jobs. If one is significantly bigger in the job market, this gives me more flexibility and job security going forward. This has resulted in me going with AngularJS as there are 7-10 times the number of jobs advertised vs other frameworks. My current role also uses typescript and was using it before the Ang 2 announcement. I do watch where the various technologies are going within the whole stack. I also find articles like this interesting as they show movements in the technology stack that I should be aware of http://angularjs.blogspot.co.uk/2015/09/angular-2-survey-results.html http://angularjs.blogspot.co.uk/2015/09/angular-2-survey-res... I am currently using grunt, but feel I need to get into gulp.
arenaninja 11y ago
I can confirm that the explosion of package managers (npm/bower), task runners (gulp/grunt), UI frameworks (foundation/bootstrap/skeleton), pre-processors (sass/less), JS frameworks (...), etc., that you can waste entirely too much time deciding between them. As an aside, I've been working on a project that uses Angular 1.3, and I'm not entirely sold yet. I do like that modules are usually contained, but the dependencies are hard to reason about (plus there's all the black magic I'm convinced they had to use to get this to work). Everything about the application feels sluggish, because there's a ton of other JS frameworks being pulled in. So whatever you do, don't mix and match 10 of them. It's painful as a user
verusfossa 11y ago
I recently tried to explain my setup to a friend and realized this is getting out of hand. I like the do one thing/pluggable UNIX philosophy as much as anyone, but saying "Typescript,tslint,gulp,jspm,Karma,mocha,chai,sinon,nightwatch,stylus,stylint,istanbul,react,skeleton,jsx,editorConfig,babel,Cordova" makes your head spin. Also getting them all to work together and play nice with sourcemaps and gulp tasks is a pain. Just setting up the tooling for the project BECAME the project. Sure it's IDE independent, pluggable and makes for clean development, but next week another thing will be shiny and I'll be doing more boilerplate. sigh
- cozuya 11y ago
  Yes, it can take a while to get things set up. But you really only need it once. I've used the same core gulpfile for at least a year across multiple projects. And when new things pop up that are useful to your workflow you can integrate them pretty easily. To me the benefits far outweigh the cost of learning or at least integrating most build tools and concepts.
Lawtonfogle 11y ago
Shouldn't the meme be: AUTOMATE ALL THE TASKS I feel like memes should be left out of serious write ups because if you do it wrong, or if you have an audience who doesn't normally consume memes, you will end up with what happened to me, which is my attention being focused on the wrong place.
SchizoDuckie 11y ago
> Language Checklist > > When you have answered those high-level questions, it's a good time to talk to your teammates and pick up a language! No, No and No. Please, just use something that's as close to plain javascript as possible. Your client will thank you because you don't have to reinvent wheels for the sake of programmer porn...
fenomas 11y ago
I'm surprised that the "nothing complex / hack up a quick prototype" recommendation is Angular. I get that it's powerful, but there's so much deep magic inside angular [1] that I find even simple stuff takes significant forethought and wrangling. As a substitute, why not Ractive.js? It's simple and does what you'd expect. You put {{#each foo:i}} {{foo[i]}} {{/each}} in one place, and ractive.set({ foo: ['a', 'b', 'c'], classname: "output", }) in another, and things just work. No messing with insanity like: angular.element(myDomElement).scope().$apply(); /rant. Maybe I'm missing something deep here. [1] Introspecting the parameter names of the callback function I passed in? Really?
- mr_mig 11y ago
 No, you don't miss anything. Angular is pretty bad in my opinion. You can check out my rant here: http://www.fse.guru/2-years-with-angular http://www.fse.guru/2-years-with-angular In my experience, those people who have tried it as a framework for "some web-related stuff we need urgently" find Angular really attractive. When they need to dive deep in the magic they just hire a consultant...

78 points by g4k 11y ago

IMHO, as an outsider, I reduce the less risky choices to 3: - javascript -> meteor + react - whatever language -> whatever language most popular framework + react - ruby -> elixir -> phoenix + react Feel free to criticise.

andrew_wc_brown 11y ago

I use MithrilJs with Coffescript. Small and Fast.

naknode 11y ago
What about RuniteJS? Or maybe AdamantJS? I still use Browserify for almost everything.

RodericDay 11y ago

Need to do something? Have a framework! Here, more frameworks. Frameworks for everyone!

woah 11y ago

Why would you want to include grunt or gulp? Shell scripts do the job just as well and can be run from npm. Bash is streaming, parallel etc etc. You can do everything you want with &, &&, |, and >

andy_ppp 11y ago
Do you have a demo repo so we can learn from this, sounds pretty great. How do I watch files with bash and recompile changes (for example)? I'm certain it's all possible, and while grunt and gulp have lots of examples I never really like them.
- techterrier 11y ago
  Here's a couple of articles if you are interested in the gulp free approach: http://blog.keithcirkel.co.uk/why-we-should-stop-using-grunt/ http://blog.keithcirkel.co.uk/why-we-should-stop-using-grunt... http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/ http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool...
- idonthaveaname 11y ago
  The Keith Cirkel articles, mentioned earlier, are great. I also found this one, today: http://beletsky.net/2015/04/npm-for-everything.html http://beletsky.net/2015/04/npm-for-everything.html It's less detailed, but also shorter and easier to digest.
paulojreis 11y ago
My shell scripting skills aren't really that good. I feel that this might be true for most front-end developers. A JS based task runner is nice for me, as a I can harness the language I use on a daily basis (as well as the community with jobs similar to mine). Maybe if I used more bash than JS I would have a different opinion. Language preferences/fluency aside, I feel that there's much to gain from the JS "hash-based" way of expressing objects which are used as configuration objects (which can be dynamic) in task runners. I'm not aware of an easy alternative to this in shell scripting, but this is probably due to my ignorance on the subject).
freshyill 11y ago
Yeah why would anybody want to use this convenient thing thing when you could just write some shell scripts.
dimgl 11y ago
Up until recently I would not have agreed with you. However, recently I've skipped on Gulp and Grunt and it has helped me with various things: * Saves me time so I don't need to figure out why a Gulp/Grunt script is behaving erratically, such as a watch that crashes even though exceptions are being caught for it * Reduces my development depenencies, which helps with the following two things: * There's less of a chance that there will be a package that needs to be built that will crash and burn on Windows * I don't need to download a shit ton of stuff from NPM every time I clone from Git * Helps me think about my architecture critically as I don't want to do anything too complicated outside of Gulp/Grunt * I don't need to wait for someone to make a plugin for a test runner
tehbeard 11y ago
Can shell scripts do the same job? yes. Do I want to deal with writing the code / instructions to: * Explain how to setup/install the build tools. * Account for differences in shell env. * Explain to windows users to get cygwin/whatever, or make a separate set of scripts for them. No. Grunt/Gulp have the benefit of having a consistent cross OS package manager (npm), in a language that the coder is likely to be familiar with should they need to tweak it.

rco8786 11y ago

How did this even make the front page? There's nothing of value here.

nickthemagicman 11y ago
As a person not very experienced with JS there's literally no where that I know of that combines and explains modern day JS infrastructure.
- Diederich 11y ago
  Agreed. I'm a backend person who ends up writing UI from time to time, and this kind of material is gold.

jevgeni 11y ago

> Full Stack EngiNerd. I use magic to make IT things work and keep people happy. Keeping people happy is a good thing[1]. But all those words make me cringe so hard. -- [1] - unless they are serial sex offenders.

sotojuan 11y ago
If that kind of bio bothers you, stay away from Quora :-)
- jevgeni 11y ago
  I've trained myself to mentally block those on Quore, like I've trained myself to mentally block ads.
andrewl-hn 11y ago
The author is a non-native speaker. I doubt there's anything behind this bio except a wordplay.
- jevgeni 11y ago
  Yeah, it's just goofy. But feels ... overused?
netaustin 11y ago
Cringing was my main reaction too, but it was more about the use of the "all the things" meme and the "kitchen sink" advice. Clearly the author is a very smart guy, but he seems to be in early-career discovery mode. What I want my early-career developers to learn is to be great at one or two core things, not to throw a dozen hot new tools at every problem.
- jevgeni 11y ago
  Yeah. It kind of reminds me of photography: when people just get into it, they tend to be obsessed with all the different gear, until 20 years later they are content with a simple manual view-finder camera.

paulojreis 11y ago

I liked the article, but there's something I need to point out regarding CSS preprocessors. It's way more important than making CSS "a bit better". Preprocessors allow you to achieve modularity and DRYness. They allow you to move the object-composition duty from the browser to the build process - hence avoiding overloading the browser with composition (i.e. composing a class with SASS mixins or extends, instead of plugging many classes in a single HTML element). They allow you to easily express relationship through class names instead of relying on DOM hierarchy (separation of concerns). And, obviously, they allow variables! Common and centralized palettes, sizing definitions, typography definitions; also, "computable" definitions (e.g. deriving a shades/tints palettes via the built-in color management functions, or computing a typography scale from a base size). If you have the time to learn CSS and a preprocessor adequately (and think about how to tackle common architectural issues having these characteristics in mind, isntead of borrowing solutions from e.g. OOP), then you might have clean, elegant and maintainable CSS (instead of a hairy jungle of rules that nobody in your team would want to mess with).

intruder 11y ago
Do you have a resource for the last point you mentioned?
- paulojreis 11y ago
 Not exactly, it's something I've been noticing from my experience with CSS and many teams with many members which were experienced programmers but without any CSS experience. I've shared these ones with my team, however: http://philipwalton.com/articles/css-architecture/ http://philipwalton.com/articles/css-architecture/ http://philipwalton.com/articles/side-effects-in-css/ http://philipwalton.com/articles/side-effects-in-css/ http://philipwalton.com/articles/extending-styles/ http://philipwalton.com/articles/extending-styles/ http://benfrain.com/the-ten-commandments-of-sane-style-sheets/ http://benfrain.com/the-ten-commandments-of-sane-style-sheet... P.S. A good heuristic I'd like to point out (and hard-code in any CSS newbie's brain) is that if you're relying on DOM structure (e.g. styling X if he is a descendant or sibling of Y), then you're doing it wrong. Very, very few exceptions to this. Structure (HTML) is a different concern than styling (CSS) and it might change frequently; it should have minimal impact on styling. P.P.S. Another good notion is that CSS is truly like Tetris. Errors do pile up. If you are over-specific when defining a selector, soon you'll have to do a even-more-specific one to override it. If you are too confident and define a leaky rule (e.g. all `` elements inside a given widget), soon you'll have to create code to override it.

sgdesign 11y ago

Rather than evaluate every framework under the sun to try and find the one that's perfect for your specific situation and needs, I would probably focus on finding something that's widespread, well-documented, has a lot of momentum behind it, and an active community. Right now that would probably be React or Meteor.

mattmanser 11y ago
Seems odd to include Meteor, which is pretty controversial and might never take off, but not Angular, which has much, much higher usage than both of those two combined.

anjc 11y ago

I hate modern Web dev so much.

sotojuan 11y ago
This is something I've struggled with... most of the stuff I do is in JavaScript and I think the web is cool, but I hate most modern bloated websites and prefer simple text-based ones (like HN!).
lojack 11y ago
I love it. It wasn't even that long ago that I used to spend countless hours building everything with the sliding doors method and doing weird hacks to make things work in IE6 or (gasp) IE5. There was a lot less to know, and things were certainly simpler back then, but it was also extremely tedious. Nowadays I can focus my effort on problems that are actually interesting. There's been an explosion, and with the variety, things have gotten complexed. I understand that it can be cumbersome to those entering the field, and a lot of the time it's total overkill for the problem. But... once you get over the hump, there's now a lot of really cool shit you can do on the web that was completely unrealistic or unimaginable just a few years ago.
- anjc 11y ago
  Do you not find that you spend far more time now wrangling with new implementations of new frameworks for new concepts, only to discover later that you should've researched more, because you have a problem which an even newer implementation of a newer concept has solved and blah blah blah. The amount of time I've wasted in my life learning things to keep up with Web dev trends...
  - at-fates-hands 11y ago
    Came here to say this. Frameworks are great, but you have to spend a lot of time wading through the documentation and architecture. Why this is different than that framework and why this does something different than that framework, and why this framework solves something this other framework fucks up. For a time I just started putting together my own stuff and then realized it was so custom, it was totally useless outside of a particular project. I've come around a little bit, but its frustrating when the whole industry jumps on a bandwagon, promotes the shit out of it and then some time later, they're onto something else and the cycle repeats itself. The best example for this is Backbone. It was one of the first JS frameworks I started fooling around with, along with Node and Express. Everybody thought this was the greatest thing ever. Now, less than a year or so after I first started dabbling with it, you can't find anybody still talking about it (even though its still a rock solid framework). Everything is now Angular, React and various other shiny toys. I would say the same thing about Knockout. People thought this was the next big thing, and now I can't find anybody promoting it anymore.

tdees40 11y ago

I'm unique in that I've never done any web development whatsoever (all my work is in finance and HPC), so I know zero Javascript, no CSS, and only the most rudimentary HTML. This article reminds me why I stay away from the web dev space.

deleted 11y ago

[deleted]

onewaystreet 11y ago

Or skip all that and go use React and Webpack.

dimgl 11y ago
How about...no...? React isn't the solution to every problem.
- mawburn 11y ago
  Not with that attitude it isn't.
weavie 11y ago
No. It's Clojurescript and Om you should be using.
ryanSrich 11y ago
Does the React + Webpack stack essentially give you all of the same functionality that Angular does?
josai 11y ago
React is a library, not a framework. What's your router? What's your model? What's your buildchain, how do you deploy, how do you do ajax requests, etc etc etc? Facetious comments like this help nobody. There's not a site in the world "just" using react + webpack. And I say this as someone who works with a react and webpack site.. oh and backbone, and gulp, and rsvp, and requirejs, and another 70 lines in package.json.

onion2k 11y ago

No matter how good you are now, your code when you've spent a year with a framework will be better. Consequently you should pick a framework (or language, or tool) and stick with it until you actually have a good reason to move on to something else. The benefits of jumping to whatever someone else recommends because they claim their choice is better for X, Y and Z reasons are likely less than the benefit of your own experience with a framework you've learned and understand. 90% of the speed of your code in terms of both writing and execution are a function of how well you write it, not the libraries you're using. Writing better code comes from practising (and thinking).

mr_mig 11y ago
To be honest, I think the person who has spent a year with a framework and who is ok to use it on a day-to-day basis won't simply trust a random guide in a random blog.

gotchange 11y ago

I find it odd that he didn't include Jade in this long list of tools and technologies of modern web development as it's IMO the best tool hands down out there when it comes to HTML modularization/componentization and I can't imagine now developing websites or even web apps without it in my workflow.

ryandrake 11y ago

As someone with an embedded C and C++ background, I have to admit, the world of web programming seems bewildering and alien with all its frameworks and workflow engines and module bundlers and virtualization and containers. Does anyone even write code anymore, or has web programming simply become a systems integration problem? It's a testament to how awesome and diverse this field is that you can take two people, both think of themselves as professional programmers, and chances are each will be mystified by what the other person does day to day.

porker 11y ago
> Does anyone even write code anymore, or has web programming simply become a systems integration problem? Now we program in frameworks, not languages. The language just happens to be the framework's chosen expression.
mrits 11y ago
I almost think the author's intent was to show all the different things he knows about. There isn't too much difference in the tools in this list than what you use everyday. The problem is they aren't bundled together and the flexibility adds to confusion. Package management, compilers, linkers, nothing new.
baldfat 11y ago
I still believe that web programming is one giant hack built upon other hacks with a right and "wrong" (hack) way to implement everything.

deltaprotocol 11y ago

After reading the article I think what the author meant is: How to get even more confused with the insane plethora of Front End stuff out there and give up life. But I can't blame him. I've also tried to create lists, to reason it all. Several times, and to no avail. One thing he got right, an image at the very beginning with the word chaos in the middle. Good luck!

awjr 11y ago

The way I chose in the past. Use a jobsite (in my case www.cwjobs.co.uk). Type in framework. Count number of jobs. If one is significantly bigger in the job market, this gives me more flexibility and job security going forward. This has resulted in me going with AngularJS as there are 7-10 times the number of jobs advertised vs other frameworks. My current role also uses typescript and was using it before the Ang 2 announcement. I do watch where the various technologies are going within the whole stack. I also find articles like this interesting as they show movements in the technology stack that I should be aware of http://angularjs.blogspot.co.uk/2015/09/angular-2-survey-results.html http://angularjs.blogspot.co.uk/2015/09/angular-2-survey-res... I am currently using grunt, but feel I need to get into gulp.

arenaninja 11y ago

I can confirm that the explosion of package managers (npm/bower), task runners (gulp/grunt), UI frameworks (foundation/bootstrap/skeleton), pre-processors (sass/less), JS frameworks (...), etc., that you can waste entirely too much time deciding between them. As an aside, I've been working on a project that uses Angular 1.3, and I'm not entirely sold yet. I do like that modules are usually contained, but the dependencies are hard to reason about (plus there's all the black magic I'm convinced they had to use to get this to work). Everything about the application feels sluggish, because there's a ton of other JS frameworks being pulled in. So whatever you do, don't mix and match 10 of them. It's painful as a user

verusfossa 11y ago

I recently tried to explain my setup to a friend and realized this is getting out of hand. I like the do one thing/pluggable UNIX philosophy as much as anyone, but saying "Typescript,tslint,gulp,jspm,Karma,mocha,chai,sinon,nightwatch,stylus,stylint,istanbul,react,skeleton,jsx,editorConfig,babel,Cordova" makes your head spin. Also getting them all to work together and play nice with sourcemaps and gulp tasks is a pain. Just setting up the tooling for the project BECAME the project. Sure it's IDE independent, pluggable and makes for clean development, but next week another thing will be shiny and I'll be doing more boilerplate. sigh

cozuya 11y ago
Yes, it can take a while to get things set up. But you really only need it once. I've used the same core gulpfile for at least a year across multiple projects. And when new things pop up that are useful to your workflow you can integrate them pretty easily. To me the benefits far outweigh the cost of learning or at least integrating most build tools and concepts.

Lawtonfogle 11y ago

Shouldn't the meme be: AUTOMATE ALL THE TASKS I feel like memes should be left out of serious write ups because if you do it wrong, or if you have an audience who doesn't normally consume memes, you will end up with what happened to me, which is my attention being focused on the wrong place.

SchizoDuckie 11y ago

> Language Checklist > > When you have answered those high-level questions, it's a good time to talk to your teammates and pick up a language! No, No and No. Please, just use something that's as close to plain javascript as possible. Your client will thank you because you don't have to reinvent wheels for the sake of programmer porn...

fenomas 11y ago

I'm surprised that the "nothing complex / hack up a quick prototype" recommendation is Angular. I get that it's powerful, but there's so much deep magic inside angular [1] that I find even simple stuff takes significant forethought and wrangling. As a substitute, why not Ractive.js? It's simple and does what you'd expect. You put {{#each foo:i}} {{foo[i]}} {{/each}} in one place, and ractive.set({ foo: ['a', 'b', 'c'], classname: "output", }) in another, and things just work. No messing with insanity like: angular.element(myDomElement).scope().$apply(); /rant. Maybe I'm missing something deep here. [1] Introspecting the parameter names of the callback function I passed in? Really?

mr_mig 11y ago
No, you don't miss anything. Angular is pretty bad in my opinion. You can check out my rant here: http://www.fse.guru/2-years-with-angular http://www.fse.guru/2-years-with-angular In my experience, those people who have tried it as a framework for "some web-related stuff we need urgently" find Angular really attractive. When they need to dive deep in the magic they just hire a consultant...