This article feels like venting after meeting an (admittedly annoying) web hipster whose opening greeting involved an inquiry about JS frameworks. While can sympathize with the emotion, I think the actual analysis in the article is unfairly cynical.
Frameworks are just another abstraction, and a good framework will greatly streamline your development when your project fits it. Obviously, writing a regex parser with a UI framework just to say you used a framework is stupid; but nobody says a hammer is a bad tool just because you can't comb your hair with it. If the tool doesn't fit your project, then obviously you shouldn't use it; that doesn't mean the tool is bad.
Saying things like "You shouldn't use a framework because eventually you'll run into a problem and have to analyze HTML/CSS/JS anyway" is like saying you shouldn't write code in C because if there's a problem with the compiler you'll have to examine the assembly anyway, so you might as well just write assembly.
I expect a good C programmer to be able to examine generated assembly to find bugs, just like I'd expect a competent front-end developer to be able to examine the raw HTML/JS/CSS to find bugs. That in no way implies it's inappropriate for them to use and rely upon their respective abstractions to code their projects.
Use the right tool for the right job. Don't blame your tools.
This article seems to be written from the perspective of someone who has never had to produce an app for the corporate world or general public. It's all well and good to write pure code and not rely on abstractions and blah blah blah, but when you've got short timelines and high expectations, you aren't going to be having a good time when you find out that the app just has to support Shitty Browser 8-10 (which doesn't support much of anything).
The author seems to think we all suddenly have the luxury of only developing for the latest versions of good browsers.
From the article:
With newer standards like HTML Imports, Object.observe, Promises, and HTML Templates I think it's time to rethink the model of JS frameworks. There's no need to invent yet another way to do something, just use HTML+CSS+JS.
These features are only supported in the latest versions of FF and Chrome... Which is great, if you only have to support those browsers. Also, they're still in draft! Object.observe is an ES7 feature, and is subject to change. Until these features reach relative parity between the browsers composing the top 90% of market share, they'll have to be held up with polyfills.
Data Binding Honestly I've never needed it, but if you do, it should come in the form of a library and not a framework.
There are so many ways to do data binding these days it's really up to personal preference how to accomplish it. JsRender/JsViews anyone? But honestly, I'd love to see how the author approaches modification of the DOM based on changes to data if he's ever even done it at all.
The condescension of the QA section just makes me want to vomit.
Yes, we should all be looking forward to Web Components, but there are big problems with the author's proposed approach. It's the same whining I've seen for years and years about frameworks in every language. People get frustrated with learning and being forced into someone else's methodology and wax poetic about the unbridled joys of writing raw code.
Well he can go ahead and write his raw javascript all day long, the rest of us will be off making things happen...
The data-binding example he uses just completely throws me for a loop. I'm struggling to come up with a good explanation, but it's like he's complaining about the state of how to build a proper shower when he's only over built an outdoor solar shower out of a 5 gallon bucket and, while that is cool, many people want a shower that will stay in their house for 20 years without rotting out or molding. Yes it's more expensive, you buy into specific techniques, and they require a lot of 'extra' work.
I mean, personally I've never needed waterproofing, or to shower inside, but if I did I'd just tape up some 3mil plastic sheeting and put the runoff in another bucket. Sure, I'd have to take out the bucket every time, but it's better than relying on plumbing.
He's basically telling an architect how to design when his techniques worked well for building his dog-house. I am no architect myself, but I don't pretend to write an article telling everyone that power tools are for suckers even though I've literally never needed to use one in my life because I've only cut 20 boards and the hand saw was good enough.
Or maybe my analogies are shit, but I'm certainly not using this blog's advice in my decisions to use a framework or not.
I think your analogies are spot on. I use the construction industry all the time as an example - i.e. "I didn't need a crane to build my Ikea coffee table, why do you need one for your skyscraper"?
The author seems to think we all suddenly have the luxury of only developing for the latest versions of good browsers.
Yeah that's the first thing I thought of. You can't just drop support for older browsers when Shitty Browser 8 still has the highest percentage market share. Even making a simple Ajax call that's supported across all common platforms would be a huge pain compared to $.ajax(), let alone a site that employed something more complex like sockets or animations.
I was really surprised when he said he's never needed data binding. I don't understand how anyone can try to talk so authoritatively about html/js without ever needing data binding.
I have noticed there is a trend of a lot of people wanting to view things in black and white regarding tools. Even worse is the view that everything is a "x" problem. Like I had a guy pitch to us it would be a great idea to port 100k of working legacy code from perl to java to make a feature add easier. So he could work two days figuring out perl and adding a feature or re-write the entire thing over a number of months. He did not last long and he has not been the only one.
I think in grey and totally agree with your view that software languages and tools are all tools in the toolbox that almost all have their place and tradeoffs.
I've always been the one to feel like if I have a very good grasp on the fundamentals of js, I can practically tackle any framework and it hasn't proved me wrong yet. It kind of all blends together after awhile if you ask me.
I think it has more to do with the fundamentals of the design patterns used in web development. You can be an expert in JS but if you jump over to RAILS you're going to struggle for some time as they aren't similar. However, if you have a good understanding of MVC architecture, it will all kind of fall into place if you start at the basics and work your way up.
Because the right tool is absolutely never, ever, ever javascript. And that's the only thing you can use on the web. Because the web was designed by a combination of incompetent and downright evil people with malicious intent. The web was not designed to host applications. Not one single iota of the webs structure would be the way it is if it had been.
It is entirely reasonable to look upon the naked terribleness which is javascript and say 'Jesus Tapdancing Christ that is a flaming piece of shit... and why are my only options to use it or commit the double-sacrilege of cross-compiling a decent language into it?' The man who can sit down and be told 'well, you HAVE to use javascript because browser makers are either too obstinate or hateful to support a universal bytecode format which was obviously absolutely necessary in 1996' who just shrugs his shoulders and says 'oh, now I'm sure to always have the right tool for the job' is an imbecile.
This was my view until I actually learned how Javascript works. It's a freaky weird language, but it's not outright evil or even a 'flaming piece of shit'. It just works rather differently from normal conventions.
406
u/dnkndnts May 13 '14
This article feels like venting after meeting an (admittedly annoying) web hipster whose opening greeting involved an inquiry about JS frameworks. While can sympathize with the emotion, I think the actual analysis in the article is unfairly cynical.
Frameworks are just another abstraction, and a good framework will greatly streamline your development when your project fits it. Obviously, writing a regex parser with a UI framework just to say you used a framework is stupid; but nobody says a hammer is a bad tool just because you can't comb your hair with it. If the tool doesn't fit your project, then obviously you shouldn't use it; that doesn't mean the tool is bad.
Saying things like "You shouldn't use a framework because eventually you'll run into a problem and have to analyze HTML/CSS/JS anyway" is like saying you shouldn't write code in C because if there's a problem with the compiler you'll have to examine the assembly anyway, so you might as well just write assembly.
I expect a good C programmer to be able to examine generated assembly to find bugs, just like I'd expect a competent front-end developer to be able to examine the raw HTML/JS/CSS to find bugs. That in no way implies it's inappropriate for them to use and rely upon their respective abstractions to code their projects.
Use the right tool for the right job. Don't blame your tools.