
Paralyzed by Choice in Front-end Development - remotesynth
http://flippinawesome.org/2014/03/31/paralyzed-by-choice-in-front-end-development/
======
danielweber
Unfortunately, we've set up a lottery where the biggest winners are the ones
who write the Great American Framework, and the way people play is by making a
new framework/front-end/library/yet-another-thing and fragmenting the
ecosystem ever more.

Oh, and then employers will say "we demand two years experience in the thing
that came out two years ago -- we need you to hit the ground running!!"

~~~
coldcode
I've had people expect > X years in a technology that was only < X years old.

------
gits1225
[http://html5weekly.com/](http://html5weekly.com/) is one quality newsletter.
Then there is
[http://tinyletter.com/webaudioweekly](http://tinyletter.com/webaudioweekly)
which I have been subscribed to for around 3 weeks now; some really
interesting links there.

From the list in the OP,
[http://webtoolsweekly.com/](http://webtoolsweekly.com/) and
[http://tympanus.net/codrops/](http://tympanus.net/codrops/) looks very very
interesting. Thanks for sharing this.

Edit: Unfortunately, codrops doesn't seem to have a subscribe by email option.
Oh well.

------
Touche
I think the complaints about "too much choice" are overstated. People are not
simply reinventing the wheel over and over, we have legitimate innovations
happening due to "too much choice".

React came out less than a year ago and there are already alternatives built
on the virtual DOM concept, and attempts to port to other libraries.

X-Tag and then later Polymer came out which has acted as test beds for the Web
Components standard.

Those are just two examples off the top of my head. Innovation is unlikely to
happen if we all throw out hands up and agree to just use Framework X.

~~~
camus2

       React came out less than a year ago and there are already
     alternatives built on the virtual DOM concept
    

How is it a bad thing?the virtual DOM should be a library by itself i believe.
So should be angular injector , so is Sizzle ,etc...

Instead of writing big frameworks that mashes up a lot of stuffs, these
libraries should AND will be more modular no matter what, in the future. I
want to be able to create my own library with building blocks ,like in any
other language. The problem today is

1/ javascript lacks of a proper module spec

2/ libraries are too tightly coupled

ES6 module are the answer and will change things.fortunatly.

I dont want to use React,Angular or Vue or whatever. I want to use building
blocks to create my own framework. JS lib maintainers will have to change the
way they write libraries to make them extentable and pluggable.

~~~
Touche
> How is it a bad thing?

I don't. I think it's a great thing, I thought my comment was pretty clear
that I think "too many options" is B.S.

------
nekopa
To remotesynth (who I believe authored the post): Hey, how do I decide what is
noise and what isn't?

Could you possible think about adding a section to the post with actionable
steps similar to the ones you listed for side projects? Those were golden. But
the main part of your article talks about 'finding if it's relevant to your
work' and such.

Do you have a process you use for objectively evaluating a new tech for work
purposes vs side project purposes? Or do you use a funnel such as: >try in
side project >if good, try at work

I'm wondering because I do a lot of work with edutech, and I have a very
specific set of criteria I use when evaluating the 'latest and greatest' new
piece of learning software that crosses my desk. It helps me to weed out the
chaff from the wheat.

~~~
remotesynth
I didn't cover that because I think the criteria changes depending on your
role and the type of company you work for. For instance, when I was at a large
financial company, it needed to be something that was well established, with
solid documentation and with professional support options (so, often this was
something along the lines of professional open source). When I was with a
consulting company, I was much more open to new frameworks as I might
encounter clients using them or they might be suitable for some project.

When I am compiling my weekly update, it ends up being something that appears
to have at least some decent documentation and the description sounds both
useful and makes sense (you won't believe how many libraries/frameworks I come
across that I simply have no idea what they actually do or how they are
different).

Anyway, all that is to say, I don't know that there is one set of criteria
that works for everyone and it is subjective anyway. Sorry if that sounds like
a cop out.

------
bigd
The list of mailing lists very well curated and useful, few of them I did not
knew about. In my digests subscription I also have:

> Web Development Reading List (WDRL)
> [http://tinyletter.com/wdrl](http://tinyletter.com/wdrl)

> Sidebar

and FountForge

~~~
bigd
reporting the links here in csv formats for easy processing -

Warning: the hn parser appends the quotes to the url when you click. sorry
about this

"Collective by
CoDrops","[http://tympanus.net/codrops/collective/"](http://tympanus.net/codrops/collective/")

"CSS Weekly","[http://css-weekly.com/"](http://css-weekly.com/")

"Web Design Weekly","[http://web-design-weekly.com/"](http://web-design-
weekly.com/")

"Responsive Design
Weekly","[http://responsivedesignweekly.com/"](http://responsivedesignweekly.com/")

"The Sass Way","[http://thesassway.com/"](http://thesassway.com/")

"Sass News","[http://t.co/j0fMGWu9ng"](http://t.co/j0fMGWu9ng")

"Web Standards Library Update by Flippin’
Awesome","[http://flippinawesome.org/category/news/best-
of/"](http://flippinawesome.org/category/news/best-of/")

"Best of JavaScript, HTML & CSS by Flippin’
Awesome","[http://flippinawesome.org/category/news/best-
of/"](http://flippinawesome.org/category/news/best-of/")

"HTML5 Weekly","[http://html5weekly.com/"](http://html5weekly.com/")

"JavaScript
Weekly","[http://javascriptweekly.com/"](http://javascriptweekly.com/")

"Node Weekly","[http://nodeweekly.com/"](http://nodeweekly.com/")

"Web Tools Weekly","[http://webtoolsweekly.com/"](http://webtoolsweekly.com/")

"DailyJS","[http://dailyjs.com/"](http://dailyjs.com/")

"ng-newsletter","[http://www.ng-newsletter.com/"](http://www.ng-
newsletter.com/")

"Ember Weekly","[http://emberweekly.com/"](http://emberweekly.com/")

"Today’s Readings by Aaron T.
Grogg","[http://aarontgrogg.com/blog/category/todays-
readings/"](http://aarontgrogg.com/blog/category/todays-readings/")

------
iamthepieman
I see a lot of complaints that employers want X years of experience in a
framework that has been out only X years or even less than X years.

Also see complaints about having to keep up with too many new
frameworks/libraries etc.

Hopefully both good developers and good employers/clients will realize that
frameworks are like cars.

You might be a mechanic who specializes in Corvettes but that doesn't mean you
can't change the tires, do the brakes, or diagnose the oxygen sensor on a
another make or model.

The really valuable skills, in developers or mechanics are knowing your tools
and how to choose the best one for the job, knowing the
diagnostic/troubleshooting process and knowing the underlying systems that
make a program/vehicle run.

Sure there will be little gotchas or time-savers that a specialist will have
developed but those are usually mitigated by joining a team that can point
them out to you or just by working with the new framework/library for a while.
They certainly don't prevent you from being productive.

------
josephjrobison
Has anyone seen a tool or website that shows which technologies were used for
which website or web app? I'm aware of BuiltWith but wondering if there is
anything more framework-choosing oriented. How should I decide whether to use
Angular, Meteor, Node, Backbone, Vanilla, Rails, etc

------
raverbashing
Yes

Some developers have a tendency to overpick tools/frameworks, usually the
latest ones, with incomplete/bad documentation

So there's a new something.js that came out yesterday and they already commit
it into the project when it could be replaced by 3 lines of js in a less buggy
way for what they need it in the project

------
CmonDev
Paralysed by choice:

1) Which client-side scripting language should I choose? Let's see... Only one
supported - JS it is.

2) Which client-side GUI layout language shoud I choose? Hmm... I will go with
the only one supported - HTML.

~~~
nekopa
I am about to dive head first into web/web app programming. Would you suggest
I do it all through plain vanilla HTML/CSS/JS?

I mean I wanted to start with these (I first wrote web pages in the late 90s
with just HTML) as I believe you do need a fundamental understanding of the
foundations to be able to make a good choice regarding frameworks. But would
you say just stay with those, and don't worry about SASS/LESS,
Angular/JQuery/etc..?

Or can the right framework really make you more productive? (I really do
wonder about this because all I see with a lot of frameworks is that they
impose a way of thinking onto your coding)

~~~
doktrin
> * But would you say just stay with those, and don't worry about SASS/LESS,
> Angular/JQuery/etc..?*

What you use should ultimately be up to you, but I would approach it in the
following way :

1\. start with what you _need_ to complete the project

2\. add new components / frameworks / libraries on a must-have basis

I'd be tempted to recommend ditching jQuery while learning JavaScript, but
don't feel that strongly about it. A lot of Stack Overflow answers will be
provided with jQuery syntax - so that's something to keep in mind.

Don't worry about SASS/LESS and client side "MVC" frameworks. Until you need
them, those are just new fiddly things to learn that distract from the actual
point of the exercise.

~~~
remotesynth
I've looked into what it would take just to dump jQuery for DOM traversal and
manipulation. It can be done in plain JS, but you end up rewriting a lot of
methods to fill in the gaps already filled by jQuery. My conclusion was, it's
still easier and more productive to use jQuery.

~~~
doktrin
> _It can be done in plain JS, but you end up rewriting a lot of methods to
> fill in the gaps already filled by jQuery. My conclusion was, it 's still
> easier and more productive to use jQuery._

Of course. That's the entire point of jQuery :/

If your goal is to put up an application - jQuery is basically industry
standard. If your goal is to develop a better intuition about how the DOM
works - then stick to JavaScript.

------
notastartup
I remember a client who wanted to use Node.js and Angular.js for a simple site
that could've just used php, jQuery and ajax but to no avail, he already has
rosy outlooks for this latest technology that will make his website scale like
crazy and with a front end that will be easy to build on. It didn't help that
he had another freelancer telling him that he is 'philosophically against php
and uses javascript only'.

~~~
Joeri
You could have advised the client to use the experimental technology that
facebook uses to build their front-end, something called hhvm ;)

~~~
notastartup
yeah at the time I didn't know it existed. I think hhvm is really important
for php

------
jaegerpicker
I think the paralyzed by choice meme is overstated in a lot of places. Sure
there is a lot of new JavaScript libs and tools being developed but none of
them are needed. A lot of them certainly make your job easier and it makes
sense to learn about the new tools as they come but in general a ten to
fifteen minute glance will tell if it should be in the pipeline or not.

