
How to Pick a Front End Web Framework - g4k
http://www.fse.guru/how-to-pick-a-frontend-web-framework
======
ryandrake
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
> 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.

------
paulojreis
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).

~~~
dustingetz
I hear what you are saying about clean and elegant css being possible with
preprocessors that add abstraction capabilities. I have never ever seen it in
practice, at least nothing on par with the abstraction abilities of code. Can
you post a medium scale example of clean & maintainable css that we might
study?

~~~
ceejayoz
[https://github.com/twbs/bootstrap/tree/master/less](https://github.com/twbs/bootstrap/tree/master/less)

~~~
paulojreis
Bootstrap is quite the opposite of what I'd consider good CSS architecture
(although it's obviously a great project). Way too much reliance on DOM
structure.

~~~
DougWebb
On a larger scale (overall layout of a page) CSS reliance on DOM structure is
a bad thing. But on a small scale (layout of a component) the cleanest markup
is usually going to require coordination between the CSS and the DOM structure
(and JS if the component has custom behaviors.)

This is true for basic html too. You could create a bullet list by adding a
div with a class for the container and arbitrarily located divs with classes
indicating that they're list items related to the container, and then use
complicated CSS to pull it all together into a visual representation of a
bullet list. Or, you could use a ul element for the container with direct
child li elements for the items. Your visual style relies on the DOM
structure, but overall it's a cleaner solution.

~~~
paulojreis
Why would you create a list with <div> elements? I understand your point; DOM
structure has styling defaults and you have to play with it - 100% decoupling
it's not possible. Still, trying to achieve decoupling between structure and
styles doesn't mean that you should create bad mark-up.

In your scenario, I'd use a list element (<ul> or <ol>, according to the
nature of the data) with a class (e.g. .my-list) and list item elements also
with a class if needed (<li> with e.g. .my-list__item). No complications here.
If somewhere along the way someone wanted to to a navigation area with exactly
the same styles but with a different mark-up (anchors inside a <nav>), you
could reuse or extend those classes to a <nav> element for the container and
<a> elements for items. That's another "level" of DOM independence.

~~~
DougWebb
That's exactly how Bootstrap's classes for lists work. And they are tied to
the DOM structure, though not necessarily to particular elements: .my-list has
to go on a container element, and .my-list__item has to go onto children of
that element.

The point I was trying to make was that at a component level, your CSS classes
are usually going to depend on a particular hierarchy in the DOM elements that
the classes are applied to, or they won't work correctly. How much of a
dependency you have is a tradeoff; you can design your framework to minimize
the dependency, but you're likely to create a more complicated framework in
exchange.

~~~
paulojreis
> That's exactly how Bootstrap's classes for lists work. And they are tied to
> the DOM structure, though not necessarily to particular elements: .my-list
> has to go on a container element, and .my-list__item has to go onto children
> of that element.

Not quite exactly. My solution doesn't require list items to be child elements
of the list. Bootstrap's "list item" needs (by definition/rule) to be a
"direct" descendant - a child element of a given type (a selector with "> li")
of the list. They have classes for lists, and then style the list items via
element and "descendancy" (i.e. .my-list > li).

If somewhere along the way you decide/are asked to change the mark-up in order
to have an element for grouping list items (so, you'd have elements between
the list and list items ), Bootstrap's way of creating rules wouldn't work
anymore - list items wouldn't be child elements of the list, despite you
wanting to keep the styling in them. Independently of how you solved this in
the mark-up, if your rule was like Bootstrap's .my-list > li, then it wouldn't
work anymore because list-items wouldn't be "direct" descendants of .my-list.

This might seem minor or unusual, but I assure it's not - this is the kind of
changes in structure that happen very frequently and make DOM-tied CSS fail.
And bear in mind the Tetris effect on this: your less-than-experienced team
member might solve this with yet another rule, but a even more specific one
(.my-list > .group > li) which will yield harder to maintain CSS (this rule is
very specific; it would need even more specific rules to be overridden when
necessary). If your development rule was "no DOM tying; just use classes), the
problem of escalating specificity would've also been avoided.

> The point I was trying to make was that at a component level, your CSS
> classes are usually going to depend on a particular hierarchy in the DOM
> elements that the classes are applied to, or they won't work correctly. How
> much of a dependency you have is a tradeoff; you can design your framework
> to minimize the dependency, but you're likely to create a more complicated
> framework in exchange.

I understand your point, but I don't agree with the notion that "but you're
likely to create a more complicated framework in exchange" by minimizing the
dependency on the DOM. You're likely, definitely, to create a more verbose CSS
framework, with a way bigger amount of classes. But I don't think this is the
same as complicated; it's more verbose, it may require you to write more
code[1], but I think it's very predictable and easier to follow by team
members with different expertise levels.

P.S. Also, bear in mind that BEM-like solutions also have hierarchy. Elements
which belong to blocks. They just don't depend on a specific hierarchy on the
DOM; DOM hierarchy is independent of styling hierarchy.

[1] I'd argue it will make you write more code _in the beginning_. Traditional
DOM-tied styling will eventually catch-up and the code you have to write to
overwrite "over-specific" selectors and similar issues will grow bigger.

------
onion2k
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
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.

------
tdees40
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.

------
anjc
I hate modern Web dev so much.

~~~
lojack
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
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
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.

~~~
mr_mig
You can use Backbone and Knockout with React. React is not a framework per se.
It just makes things less complex.

I'd encourage you to read this article if you haven't done it yet:
jlongster.com/Removing-User-Interface-Complexity,-or-Why-React-is-Awesome

------
fenomas
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}}
           <span class="{{classname}}"> {{foo[i]}} </span>
        {{/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
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...

------
arenaninja
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

------
deltaprotocol
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!

------
jevgeni
> 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
If that kind of bio bothers you, stay away from Quora :-)

~~~
jevgeni
I've trained myself to mentally block those on Quore, like I've trained myself
to mentally block ads.

------
sgdesign
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
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.

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

~~~
nickthemagicman
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
Agreed. I'm a backend person who ends up writing UI from time to time, and
this kind of material is gold.

------
SchizoDuckie
> 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...

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

------
awjr
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-
res...](http://angularjs.blogspot.co.uk/2015/09/angular-2-survey-results.html)

I am currently using grunt, but feel I need to get into gulp.

------
verusfossa
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
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.

------
galfarragem
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.

------
onewaystreet
Or skip all that and go use React and Webpack.

~~~
dimgl
How about...no...? React isn't the solution to every problem.

~~~
mawburn
Not with that attitude it isn't.

------
gotchange
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.

------
Lawtonfogle
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.

------
andrew_wc_brown
I use MithrilJs with Coffescript. Small and Fast.

~~~
naknode
What about RuniteJS? Or maybe AdamantJS?

I still use Browserify for almost everything.

------
woah
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
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
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/)

