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 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.
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.
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
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
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).
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)
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'.
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.
[+] [-] danielweber|12 years ago|reply
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|12 years ago|reply
[+] [-] gits1225|12 years ago|reply
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.
[+] [-] Touche|12 years ago|reply
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|12 years ago|reply
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.
[+] [-] jonahx|12 years ago|reply
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.
[+] [-] remotesynth|12 years ago|reply
[+] [-] nekopa|12 years ago|reply
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|12 years ago|reply
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|12 years ago|reply
> Web Development Reading List (WDRL) http://tinyletter.com/wdrl
> Sidebar
and FountForge
[+] [-] bigd|12 years ago|reply
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/"
[+] [-] remotesynth|12 years ago|reply
[+] [-] iamthepieman|12 years ago|reply
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|12 years ago|reply
[+] [-] raverbashing|12 years ago|reply
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|12 years ago|reply
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.
[+] [-] rjknight|12 years ago|reply
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).
[+] [-] nekopa|12 years ago|reply
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)
[+] [-] remotesynth|12 years ago|reply
[+] [-] notastartup|12 years ago|reply
[+] [-] Joeri|12 years ago|reply
[+] [-] jaegerpicker|12 years ago|reply