Paralyzed by Choice in Front-end Development | Hacker News Reader

Paralyzed by Choice in Front-end Development

flippinawesome.org

53 pointsremotesynth37 comments

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

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

http://html5weekly.com/ is one quality newsletter. Then there is 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/ and 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.

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.

   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.

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

And for the virtual DOM concept, there is not only React but also ractivejs, and mithriljs, and I'm sure many others. And just in this one little example, each of those libraries I mentioned are very good, and it's not at all clear which you should be using, especially if you are new to all three.

The OP is talking about a real problem. Unfortunately I don't see any good obvious solution, and I agree that everyone agreeing to use Framework X is not one.

I don't think I am saying this is a bad thing either. However many people find it overwhelming causing them to react negatively. My goal was, in fact, to turn it into a good thing by helping with strategies to cope.

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.

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.

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

> Sidebar

and FountForge

Thanks! I wasn't aware of those.

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/"

"CSS Weekly","http://css-weekly.com/"

"Web Design Weekly","http://web-design-weekly.com/"

"Responsive Design Weekly","http://responsivedesignweekly.com/"

"The Sass Way","http://thesassway.com/"

"Sass News","http://t.co/j0fMGWu9ng"

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

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

"HTML5 Weekly","http://html5weekly.com/"

"JavaScript Weekly","http://javascriptweekly.com/"

"Node Weekly","http://nodeweekly.com/"

"Web Tools Weekly","http://webtoolsweekly.com/"

"DailyJS","http://dailyjs.com/"

"ng-newsletter","http://www.ng-newsletter.com/"

"Ember Weekly","http://emberweekly.com/"

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

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.

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

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

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.

If those were the only choices that need to be made, then perhaps it would be easy.

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)

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

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.

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

Lets just say I need HTML/CSS/JS, how do I know which components/frameworks/libraries are a must have? They all use the underlying tech (unless, and this could be true as I'm very rusty, they enable something fundamentally different)

The only comparison I can make is the difference between ASM and a high level language. I could literally (physically?) see the improved productivity in my workload as I switched from x86 to C. Is there the same level of shift between JS and coffeescript?

> Is there the same level of shift between JS and coffeescript?

Opinion :

I've never used coffeescript, nor have I really been tempted to. JS isn't a conceptually difficult language, and the wrapper libraries (e.g. jQuery) make day-to-day work a snap.

Given that, I can't really see the rationale behind a syntactic sugar layer on top of a mature and straightforward ecosystem. Even back when I wrote Ruby full time, coffeescript felt more annoying than intriguing.

> The only comparison I can make is the difference between ASM and a high level language. I could literally (physically?) see the improved productivity in my workload as I switched from x86 to C.

Oh wow, it's nothing like that at all. JS is already a high level language after all. Syntactic sugar won't be that much of a boon unless you're already proficient with the languages that inspired CS.

Personally, I'm orders of magnitude more productive with C than x86. If I thought I'd see even a fraction of that productivity gain by switching to [insert anything here] I would switch to [insert anything here]. I mean that sincerely.

You can do it in vanilla HTML/CSS/JS but you will eventually reach the same conclusions more seasoned front-end developers have reached. Saying that front-end developers should just use vanilla is as silly as telling server-side developers they shouldn't be using any web frameworks.

The right framework absolutely makes you a lot more productive. Particularly when it comes to maintainability. Plain HTML/CSS/JS may be fine on the first write but they don't encourage good DRY habits. I think any toolset imposes a way of thinking, and the way you get from a good framework isn't any worse (in fact it's often better) than what you get from HTML/CSS/JS.

But what happens if you approach your plain vanilla H/C/J writing with these DRY concepts in mind?

One of the reason I would like to use frameworks/libraries is not because of the concepts they introduce, but to basically stop me from going down a rabbit hole and applying the concepts to the extreme. For example, when I am coding something from scratch, and I start to abstract up levels, I just. Keep. Going. I eventually found a soul mate in Knuth with his literate programming, and that has (finally) put an end to the levels of meta abstraction I head into, but I do see (hope) that frameworks will allow me to actually get shit done, instead of traversing the wormhole that is architecture design.

> But what happens if you approach your plain vanilla H/C/J writing with these DRY concepts in mind?

Once you know a technique you can apply it in almost any language and it really doesn't matter which you choose. But that's why it's very important to use good tools when you're starting out. (I'm reminded of an analogous situation where a friend pointed out the irony of personalized golf clubs: a scratch player can pretty much pick up any clubs and play with them, whereas it's the beginners who are still picking up their technique that would really benefit from having personalized clubs).

Frankly, and this is probably not what you want to hear, if you're wanting to learn it right I'd stay away from the web until you've done at least some UI in a well-regarded native toolkit (I'd recommend Qt, whether from C++ or from Python; I've heard good things about the Apple one but haven't used it myself). The web has a lot of legacy cruft and multiple ways of doing something that tend to obscure the principles and make it a poor learning environment, whereas if you've already learnt the basics using something more consistent then it becomes a lot clearer. But by the same logic I'd say that if it has to be the web, you should start with a big, opinionated framework (e.g. Angular) and try to understand its idioms before diving under the covers.

(But then I could never get on with Knuth at all, so your style may be different from mine)

If you are just starting out, do the very basics. Write your HTML and CSS and JavaScript by hand, because you will want to know what your tools are doing, and when its time to switch to a new tool you will know what it's doing, too.

But be aware that most employers will demand, sensibly or not, that you know whatever the latest fashionable toolkit is. Even if you could learn it in 3 days, they'll want you to have already learned it.

I am not quite 'just starting out' more like 're-starting out' I liked to think of myself as a lapsed programmer. I am also not looking for an employer (I just got lucky in that I don't need to work for someone ever again)

But what I do like is your idea of knowing what a new tool is doing. My big reason from learning everything again from scratch is that I've found that 30 years ago, I knew how to make things happen in assembly language. 20 years ago I switched to high level languages. And somehow, about 15 years ago I became a cargo-cult programmer.

So in a way I'm trying to regain my roots, but I also am doing it with an eye on being super productive in the future.

These are becoming less true. For #1, you might also choose CoffeeScript, ClojureScript or Dart. For #2, you've always needed more than just HTML: CSS at least. Now there's Canvas and WebGL, and some frameworks like React are starting to abstract the DOM away somewhat. Programming in ClojureScript with Om/React does not feel much like programming with HTML/JavaScript at all.

Beyond that, there's an explosion of tooling. Build tools, minifiers, preprocessors and compilers; systems for managing dependencies and run-time library loading; shims and polyfills to emulate new functionality on out-dated platforms; and, of course, frameworks which seek to abstract all of this stuff away behind a neat facade, providing a stable platform that you can build on without needing to worry about the details. Nobody has figured out how to do this properly yet, and I'm not hugely optimistic about the future of such projects.

I'm not quite old enough to remember the history of GUI programming from the mid-80s to mid-90s, but I wouldn't be surprised if the proliferation of tools and libraries was similar then. Even starting out doing Windows development in the mid-90s, there were multiple options - at least Visual Basic, Delphi or C++, and there were multiple C++ frameworks (MFC, ATL, varieties of COM-based stuff, and those were just Microsoft's official options, and this completely ignores non-Windows platforms).

It would be interesting to do a retrospective on such technologies, to work out why some survived and others didn't. It would not have been at all obvious in 1995 that Objective-C would be a mainstream language for user interfaces nearly 20 years later, and C++ would have fallen away, and that people would still be using NextStep in the form of Cocoa but nobody would be using MFC. My feeling is that there are some properties of good design which have enabled ObjC/Cocoa to survive for the long-term, and it would be interesting to figure out if any of the current crop of web front-end tools exhibit these properties (fwiw I get a good feeling about a lot of the ClojureScript stuff, especially Om).

The tool and libraries proliferation was a bit similar, but on a much smaller scale, since they were largely proprietary, and customer acquisition channels were things like the Programmer's Paradise ads in Byte magazine.

There is nothing magical about ObjectiveC that led to its current success, except the attachment-at-the-hip to a large and growing lucrative market the growth of which has been aggressively promoted by a deep-pocketed player. The Java ecosystem was in a similar situation before the dotcom crash, with .Net playing catchup.

Windows: QT, MFC, Windows Forms, XAML/WPF, Awesomium.

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

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

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

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.

Reply on news.ycombinator.com