Join 3,495 readers in helping fund MetaFilter (Hide)


$(framework).stop();
May 25, 2014 6:08 PM   Subscribe

Stop Writing JavaScript Frameworks! And stop using them too!
posted by blue_beetle (45 comments total) 19 users marked this as a favorite

 
Nah, bah, what we really need is a 3D visual application builder integrated with all the best frameworks and with a haptic debugging interface!
posted by sammyo at 6:12 PM on May 25 [1 favorite]


This blog post is cute, but isn't rooted in the real world. "Oh hey, browsers are perfect! No more need for abstraction" is a lovely idea and is false. Re-re-rewriting basic utilities to build more sophisticated tools is not the answer.

To say that, I don't, other than jQuery, really use a JS framework and probably for many of the reasons exposed, but the main one is, I don't quite understand why I would, as jQuery is enough for me. That doesn't mean I'm right - it could (as I assume myself) that I'm missing something really, really important.
posted by alex_skazat at 6:17 PM on May 25 [18 favorites]


Frameworks aren't for solving browser inconsistencies, that's just a side benefit. Frameworks like Angular and Ember are for reducing code complexity in large projects. They also make it easier to introduce unit testing, which as JS 'apps' become more complicated, is very necessary.
posted by jzed at 6:24 PM on May 25 [22 favorites]


Could we get a for dummies explanation of why this is obtusely witty or brilliantly perceptive or wittily obtuse?
posted by Sebmojo at 6:28 PM on May 25


Hm, just the other day, I listened to the entire set of Polymer / X-Tags panels from SFHTML5 on the Google Developers channel at YouTube, while I was building some bookshelves, and one point they mentioned a couple of times was that you might still use a JavaScript framework around your web components. So this guy, although he works at Google too, seems off-message compared to the folks on the Polymer team.

Other takeaways I got from the panels included the idea that web components might eventually become common on web sites like Squarespace or, say, Metafilter, where you could develop more and more custom tags you could safely allow users to include in their HTML, e.g. a spoiler tag. They also mentioned that Polymer and X-Tags were 100% compatible with each other and indeed used the same underlying polyfill library. And I recall two web sites being announced or recommended: Webcomponents.org for learning more about them and Component Kitchen for finding existing ones you might like.

But note that I haven't used either Polymer or X-Tags, so I dunno, really.
posted by Monsieur Caution at 6:34 PM on May 25 [5 favorites]


I can understand the "wouldn't it be great if UI development were more like Enterprise Java, said NO ONE EVER" reflex (you get that more in the "You Ruined Javascript" rant than here), but, that's probably a caricature of what the fine folks in front end land are doing with these platforms.
posted by thelonius at 6:35 PM on May 25 [2 favorites]


browsers got better. Their support for standards improved, and now there are evergreen browsers: automatically updating browsers, each version more capable and standards compliant than the last

I believed that until iOS 7 came out.

Where I work we wasted at least a man month on a bug introduced with that version of mobile safari, before we more or less ran out of ideas of what to do next gave up even though it presented a significant problem.

That's one bug. There's others we found quicker fixes for, and we're still trying to figure out how to deal with some of the changing chrome/viewport-size issues.

iOS is, of course, a veritable paradise compared to the Android web browser, where there are thousands of unique devices, emulation ranges from difficult to impossible, there's limited material out there about what standards are supported, and appears to be no such thing as any kind of guide for how to reproduce a bug given a set of device stats. As far as I can tell, the most sensible thing to do is serve Android users lightly styled static HTML. Maybe this will get better as Chrome becomes the default web browser, but I'm not holding my breath.

The iOS 7.1 update fixed the bug that iOS 7 introduced, but it didn't do a thing to repair my confidence that we're in a future of monotonically improving browsers.

And this is before you take into account corporate clients who still want IE8 support. Or, for that matter, the continued limitations of even the "modern" versions of IE.

The framework explosion and the fashion-driven nature of the tech industry makes it worse, so I appreciate the author for trying, but mostly I'm starting to think the smart thing to do is simply get out of front-end development entirely and move into something else that isn't inherently so predominately about learning the ephemeral arcanum of the day.
posted by weston at 6:47 PM on May 25 [8 favorites]


On the one hand, I agree. I recently spent a week learning the basics of Meteor.js for a project, but it turned out to be unsuitable for what I wanted to use it for. And I got this distinct feeling that besides being able to add a buzzword to my resume and knowing about a technology I could use for future real-time web projects (as opposed to content-heavy, largely static sites like the ones I usually build), Meteor knowledge was largely useless to me. It doesn't help me much with what I build now, and what I build in the future may not even be with Meteor.js, given how fast frameworks have been evolving as of late. So something that actually ties us back to standards, however imperfect they may be, is totally welcome.

On the other hand, the author spends essentially no time explaining how Object.observe, Promises and HTML templates can replace the various frameworks out there. That's fine if you already know what those technologies and standards are, and even though I don't, I have some idea of what those things might be just based on the names (Object.observe is probably something that lets me watch a Javascript object for changes and alters the DOM to suit?). But there are plenty of people who either don't have the time, the energy, the knowledge, or all of the above to connect the dots in their head. More importantly, precious little effort has gone into helping people understand how these standards might help. The author probably doesn't even disagree with this, but it needs to be stated clearly: if we are to move people off Angular/Ember/Meteor/MyShinyToaster, we need some basic primers on how all this stuff fits together and how they can replace the above frameworks and more.

And then there's the issue of standards compatibility. We already fought a huge war over web standards with Internet Explorer on all fronts, and in some ways we're still fighting now. jQuery has let us live the big lie that all browsers have similar Javascript implementations, but a little persistent poking is enough to tell you it's not true (hello Image.onload). But now we're talking about removing frameworks that hundreds, nay, thousands of people have worked on to smooth over those inconsistencies, and replacing them with a bunch of polyfills that may or may not be stable. I guess Modernizr can help us there but it's not exactly ideal, either, especially now that we're talking about enabling bleeding-edge standards (and by "bleeding-edge" I mean standards that haven't been around for at least a decade, because that's how long it seems to take for everyone to stop using poorly supported legacy browsers).

Finally, frameworks give us some syntactic sugar that I personally am loathe to give up. Excuse me if I don't want to go back to the bad old days of instantiating an XMLHttpRequest. And if your suggestion to THAT is to build your own shortcuts, well, at what point do we finally decide, hey, maybe we DO want a framework after all, even if it does far less than we ask them to now?
posted by chrominance at 6:52 PM on May 25 [9 favorites]


chrominance: "...MyShinyToaster..."

Please, please, please tell me that's the real name of an actual JS framework that I somehow haven't heard of!

<checks>

Darn it.
posted by double block and bleed at 7:04 PM on May 25 [2 favorites]


I believed that until iOS 7 came out.

Where I work we wasted at least a man month on a bug introduced with that version of mobile safari, before we more or less ran out of ideas of what to do next gave up even though it presented a significant problem.


I remember a bug in Chrome on OSX that broke anchor hash tags and event firing days before a site launch. Good times.
posted by ryoshu at 7:06 PM on May 25 [1 favorite]


Use of the word "framework" in the JS front-end community confuses me, since Angular and so forth don't seem like they embody the traditional sense of "framework" as referring to the fact that the implementor largely supplies called code rather than calling code, as you would do with a library. Is that the case and I'm just missing it?
posted by invitapriore at 7:10 PM on May 25


Use of the word "framework" in the JS front-end community confuses me, since Angular and so forth don't seem like they embody the traditional sense of "framework" as referring to the fact that the implementor largely supplies called code rather than calling code

I'm not an expert, but I think Angular might actually be a good example of the framework-as-inversion-of-control situation, in that Angular uses dependency injection extensively, as many (all?) IOC containers do. But it seems like in practice, when people say JavaScript Framework, they often mean "a way to structure and abstract my site's code that is not JQuery."
posted by swift at 7:34 PM on May 25 [1 favorite]


As far as I can tell, the most sensible thing to do is serve Android users lightly styled static HTML.

Speaking as an Android user: yes please. In fact, please serve me lightly styled static HTML on all devices, mobile or desktop.
posted by haltingproblemsolved at 7:40 PM on May 25 [18 favorites]


Bring 'em on! I look forward to seeing how to mangle and re-interpret your awful objects in Smalltalk with Amber.
posted by Slap*Happy at 7:52 PM on May 25


I can understand the "wouldn't it be great if UI development were more like Enterprise Java, said NO ONE EVER" reflex (you get that more in the "You Ruined Javascript" rant than here), but, that's probably a caricature of what the fine folks in front end land are doing with these platforms.

It might just be my allergy to the term "dependency injection" ("a 25-dollar term for a 5-cent concept"), but its increasing usage on the front-end seems like evidence of enterprise-y infiltration to me.
posted by weston at 8:08 PM on May 25 [2 favorites]


Please, please, please tell me that's the real name of an actual JS framework that I somehow haven't heard of!

Sorry! But maybe one day, if it's very lucky, it'll become a Java interface. (But only if you call it MyShinyToasterCommonAbstractionInterface.)
posted by chrominance at 8:17 PM on May 25 [3 favorites]


I still haven't forgiven those clowns that named their JS framework "Prototype", causing search results for real javascript prototype documentation, samples, articles etc. to be filled with useless noise. That appears to have died out a bit but in 2008 or so it was ridiculous.
posted by George_Spiggott at 8:51 PM on May 25 [5 favorites]


I'm with jzed. This guy is up a tree. AngularJS is not just a bunch of gobbledygook keeping you from the bare metal (ha, is there anything further from bare metal than interpreted javascript in a browser to begin with?). It's a pretty lightweight architectural layer that can help organize big projects by encouraging clean separation of concerns.

Sure, you can do without, but in the end you will probably end up either writing jquery spaghetti or inventing a crappier AngularJS.
posted by rouftop at 9:10 PM on May 25 [6 favorites]


So - is this person just trying to hop on board the anti-framework train apparently started by You Have Ruined Javascript which was written last month? (though technically that was more about angular, specifically, and I guess in general about Java/Enterprise devs fucking up Javascript frameworks by shoehorning them into an Enterprise model/paradigm.
posted by symbioid at 9:10 PM on May 25


In the absence of a framework developers invariably write their own, even if they claim they don't have one. And 9 times out of 10 they aren't as smart as the guys who write stuff like Angular and Ember and what they write is terrible. (This is assuming the site we are talking about does something and isn't just displaying static content).
posted by markr at 9:15 PM on May 25 [5 favorites]


I've disagreed with this article, above, because I don't think frameworks are obviated by the solution he proposes, but I do think his ultimate point bears repeating here:
The final pieces that enable all of this fall under the umbrella of Web Components.
He's explicitly arguing for modularity and code re-use based on new W3C standards that among other things support a new way of avoiding jQuery spaghetti.

But something worth seeing is how the Polymer team's QE answers a question about testing web components in the Q&A session at the SFHTML5 meetup. I'm not sure it was a satisfying answer.
posted by Monsieur Caution at 10:32 PM on May 25 [1 favorite]


Web development is still a total ballache compared to native desktop apps, better browsers and frameworks have made it slightly more bearable.
posted by GallonOfAlan at 12:00 AM on May 26


Great, JavaScript kiddies now think they're assembly programmers...

(I've heard the same line of argumentation from an Amiga-diehard in the early '90s. And at least 68k assembly was half way decent)
posted by pseudocode at 12:13 AM on May 26


I have spent the past weekend writing an app with angular. Before I started, I did a quick evaluation of ember, and the docs were just straight up missing stuff. also, the first bug I hit, there was no info about it on the web, and the 17k LOC was too damn scary to dig through. Bootstrap seemed more my speed (only 900 LOC!) but there was a bit too much overhead to get a simple app off the ground.

Angular makes no god damn sense, but at least it works. Like, I understand the problem they are trying to solve with it, but I don't understand how they ended up at that solution. Except for the fact that it would make sense at a giant company, maybe.

I think it comes down to the fact that I have never really met a gui that I liked, until I reimplemented the bits of it that I needed, and ignored the ones I didn't. I had the good sense not to put nice branding on my silly implementations and sell them as the next big thing. Which seems to be the hip thing to do with javascript. I wish people spent more time explaining the functionality of their gui frameworks (see this great tutorial explaining why/how IMGUI), and less time releasing.
posted by jonbro at 2:44 AM on May 26 [1 favorite]


Sometimes I think that if we programmers spent time working as much as we do discussing & dissing other languages & styles we'd already have postsingularity AI.
posted by 3mendo at 4:32 AM on May 26 [10 favorites]


I had a coworker working on a legacy project who felt the same way about this stuff. Old PHP app... no framework, minimal javascript and no great mobile experience. He just got moved to a new shiny thing... he's not singing that song at all anymore. It was weird - he hit me up for advice on frontend testing the other day. He's, like, a new man...

Look. Javascript is kind of weird.... we all know that. There's all kinds of things that you just kinda have to do when you program a lot in JS, just boilerplate kinda shit, that's annoying. Who knows what it does? Ok. Fair enough.

Anyway... that dude has never programmed a big application in a production environment with a whole bunch of other people. In that context, frameworks are a godsend -- even if they create less than ideal code scenarios sometimes, at least you end up with something that's built in some kind of consistent and coherent manner. Stuff is where you expect to find it. That's a big deal, especially as applications become more complex and you're the guy who has to figure out how to change things.
posted by ph00dz at 6:04 AM on May 26 [5 favorites]


I had the good sense not to put nice branding on my silly implementations and sell them as the next big thing. Which seems to be the hip thing to do with javascript.

That's probably the best description of the situation that I've read so far.
posted by gimonca at 7:42 AM on May 26


And 9 times out of 10 they aren't as smart as the guys who write stuff like Angular and Ember

An alternate reading of this is to understand 'smart' as a synonym for 'fashionable' instead of as a synonym for 'intelligent'.
posted by gimonca at 7:46 AM on May 26 [2 favorites]


This, basically: In the absence of a framework developers invariably write their own, even if they claim they don't have one.

Or worse, they don't, and your modern leaderless whatever-the-current-buzzword-for-agile-or-extreme-is team works incoherently and produces a shitstew of unmaintainable copy-paste code and multiple alternative implementations of the same goddamn functions. The latest fashionable framework may not be what you need; but unless you're building something improbably unique, chances are very good there is some framework that's going to help you pull it together decently without frontloading a huge amount of design work.

If your task is to create an application, then get your team productively working on the application, rather than at best, inventing new software infrastructure out of misplaced pride, or at worst, not doing either thing.
posted by George_Spiggott at 10:06 AM on May 26 [3 favorites]


Could we get a for dummies explanation of why this is obtusely witty or brilliantly perceptive or wittily obtuse?

Dummy here to explain why that won't be happening. As a dummy I couldn't really understand much that he said but no explanation would fix that because I did understand the stuff that would be in the explanation and it didn't really help. What he's saying is that in the old days of web development, people used html and css and javascript but there were lots of problems that frameworks were invented to solve. The problems included (but were not limited to) all browsers being different and non-standard and the need to make one's pages consistent across browsers, the idiosyncrasies of individual javascript implementations or even of javascript itself which made dealing with it akin to working on a conceptual level too far removed from that of the page itself, something that programs like Dreamweaver were attempts to overcome, that people needed to work in teams and so understand each others' work which became impossible for the previous reasons. Frameworks both attempted to solve those problems and to add new features that everyone "should" want.

But some of those problems are now (I'm told) gone and they weren't solved in a great way in many cases anyway and there was a conflict between which framework to use, etc.

And people in the comments are saying that either the problems aren't sufficiently gone or that they're not completely gone or that those new features aren't just wanted but are needed and this guy isn't experienced enough in some way to realize this.

And frameworks at least have an existence independent of any individual who would create the equivalent of a private and inferior one.

So, I hope that helped because that's all I understand and it's nowhere near enough to answer your question (which was an actual question, though one step removed from what you wanted.)
posted by Obscure Reference at 10:08 AM on May 26


Sure, you can do without, but in the end you will probably end up either writing jquery spaghetti or inventing a crappier AngularJS.

This times 100.

"JQuery + Awesomest light-weight jquery plugin for lightbox-autodrive-parralaxer" is totally fine if you're building a static webpage that needs a sprinkling of behavior.

If you're writing a webapp, (think single-page-app, trello or something) in a language not much suited for apps, in an environment (browser) that's just barely suited for apps, you're going to need a very serious bunch of scaffolding and infrastructure to forestall the pasta explosion. Writing that scaffolding is a full-time job. When my job is to write a webapp, I'd really rather leave the scaffolding to someone who has the time and motivation to think about that scaffolding really really hard, so I can just write the damn webapp.

I think the challenge is to find the framework whose creators think like you do and like what you like, and I also think that most of the framework-haters have simply been forced to use frameworks that they don't get along with, and have thrown out the baby with the bathwater.
posted by tempythethird at 12:24 PM on May 26 [2 favorites]


George_Spiggott: "I still haven't forgiven those clowns that named their JS framework "Prototype", causing search results for real javascript prototype documentation, samples, articles etc. to be filled with useless noise. That appears to have died out a bit but in 2008 or so it was ridiculous."

I maintain Prototype. I agree with you. Sam Stephenson, who created Prototype, agrees with you. Too late to un-shit the bed, sadly.

Also, Prototype has died out a bit, as have Mootools and Dojo and Mochikit and YUI and everything that isn't jQuery. It's jQuery's world and the rest of us just inhabit it.
posted by savetheclocktower at 1:21 PM on May 26 [6 favorites]


Popular as they are, I suspect that frameworks (like the faddish proliferation of language 'solutions') are useful for newbie (and/or pressured) programmers who want to get up to speed. Javascript frameworks mask the gotchas, and simplify what has become a very complex challenge.

I suspect that seasoned programmers can largely eschew such crutches because they have assembled well-tested strategies of their own to match their expertise. They also know that the farther you get away from native, the bugs evolve to become highly resistant to antibiotics. When your browser says "expected ':' but found ';' " and doesn't give you a line number, good luck.
posted by Twang at 1:38 PM on May 26 [1 favorite]


Also, about the article:

Ten years ago, we realized that Netscape 4.x had fucked off and we could finally start building cool stuff in browsers. But things didn't behave the same way in all browsers (IE's event system), and there were some pretty glaring bugs for things that should be simple (IE's innerHTML bugs), and even if all of that weren't so, the DOM APIs was designed by someone who liked ten-dollar words and hated human beings. That's how we got where we are. Nobody was saying "fuck frameworks" ten years ago because everyone knew that if you didn't use a framework you would be doomed to reinvent one.

It's also true that most of those decade-old issues are no longer issues. And most people who write JavaScript for browsers were not around ten years ago, and have learned frameworks without necessarily gaining a deep understanding for why the frameworks were necessary. I would not be opposed to a week of everyone starting from scratch, relying only on the stuff that's available in modern browsers (say, IE9 and up), and then contemplating at the end of the week whether they missed having frameworks to cushion the experience.

My impression is that most people would miss the frameworks dearly.

The other thing the author argues for is interoperability:
Q: So everyone needs to rewrite dropdown menus, tabs, sliders and toggles themselves?

A: Absolutely not, the point is there should be a way to create those elements in a way that doesn't require buying into one particular framework.
I've heard this sort of thing before, and I find it curious because it seems to imply that people can rally around canonical versions of things — one true dropdown, one true slider — in a way that does not shackle someone to a framework. There are things like that, but they are just as much "frameworks" as jQuery or Ember, in that they make a bunch of opinionated choices that a user must then buy into. Even if you just want to manage your dependencies in a way that isn't just throwing a bunch of script tags into your HTML, then you need to pick between several frameworks that do that, each with their own assumptions and obligations.

There is no way around this. The author isn't mad at frameworks, he's mad at the browser environment for not making these choices for us. "Then let's get the standards bodies to specify this stuff," you might think, and they are — ES6 is going to give us modules and promises and a bunch of other things that will allow frameworks to be less framework-y. Meanwhile, we live in the real world where people still use IE8, and web apps are not academic exercises.
posted by savetheclocktower at 1:42 PM on May 26 [4 favorites]


1. The recent proliferation of front-end frameworks is a natural and encouraging part of a rapidly growing and evolving discipline (web software development). And, really, the backlash is a natural part of it, too.

2. Frameworks are amazing and make my current job possible. We're 3 people writing a very complex web app on a shoestring budget and a super short timeline. We're using Angular; without it, or something like it, we'd be sunk.

3. I hope that people keep developing new frameworks. They drive the field forward and open up new possibilities.

4. The landscape will look totally different in 5 years, let alone 10 or 20. I can't wait to see what's coming :)
posted by wemayfreeze at 1:59 PM on May 26 [1 favorite]


I'm with you, wemayfreeze. Frameworks minimize risk and let you get real work done on time.

I remember way, way, way back in the day some friends of mine bashing the C standard library for instilling weakness in young programmers. I laughed at them, and I laugh at this fellow.
posted by quillbreaker at 2:35 PM on May 26 [2 favorites]


I suspect that seasoned programmers can largely eschew such crutches

One problem is that for every seasoned programmer that can, there are 9 who think they can but really need those crutches.

The other big problem is that if you're in a team and you hire a new dev and say "okay we use angular and bootstrap and $otherthing" he/she knows them already or can learn about them on the web and get productive quickly. If you say "we've written our own thing" even if it is wonderful, there is friction there for new devs.

Now that might not be a dealbreaker for you, it might be worth that friction for the gains doing your own thing gives you, but it's something to keep in mind.

Others have also go to another point, which was best said by a co-worker of mine: "Write the code only you can write". If your company makes health record software, you want to spend as much time as possible using your domain knowledge to right health record stuff and as little time as possible writing the sort of framework code that things like Angular do for you. Because your competitors are using Angular and spending all their dev time adding features.
posted by markr at 3:56 PM on May 26 [6 favorites]


A lot of the new frameworks are like fad diets. Hey, look, I lost weight! The diet itself may be pseudoscience and bunk--but as an indirect effect you put a lot of weird rules on what you can eat, and the end result is that you simply ate less, and so you lost weight.

A lot of people want their projects to be better organized. Use framework X, and an end result may be that your project is better organized. If you're lucky, it won't be organized around multiple layers of abstraction.
posted by gimonca at 5:38 AM on May 27


I've reached a point that when I see an article like this ("Your favorite framework/language/pattern/library sucks!"), I skim to see what sorts of applications the author writes. Usually, he doesn't say, which is a Big Red Flag. He's telling us that in his experience, building the sorts of apps he builds (which he doesn't inform us about), such-and-such is bad or good practice.

"Data Binding: Honestly I've never needed it..."

Okay, but I need it every five minutes. I write huge, complex JS applications for data-driven company intranets.

What does he write? Games? Ads? Blogging platforms?

People tend to think of a language as whatever it is for them, even if other people use it in totally different ways. And if they're not careful, they wind up like a textbook writer telling a poet there's no need for rhyming dictionaries. "I've written two books about auto-mechanics and several articles about where to buy fresh produce, and, honestly, I've never needed a rhyming dictionary..."

Before I started working for my current company, building these massive apps as part of a team of developers, I was a lone developer building small web ads. I used Javascript then and I use it now, but the requirements were totally different. It was almost as if, at the ad company, I was using a different language.

I might feel comfortable writing an article, saying Angular is the wrong tool for X or Ember is the right tool for Y, but before I spouted off about what JS developers should do in general, I'd make sure I'd worked in all corners of the industry. For instance, since I've never written games, I wouldn't feel comfortable pontificating about what game developers should or shouldn't use. What I might do is say something humbler and smaller-in-scale, such as, "I just spent three years developing we ads, and in my experience, the best approach to that sort of work is blah blah blah..."
posted by grumblebee at 7:26 AM on May 27 [4 favorites]


I have a web designer friend who achieved some minor notoriety back in the day via experiments with JS, and he's said JS has changed so much from back in the day in terms of how it's used and that nowadays things are split between back/front end, and the people doing the JS people in general are the developers (at least at the places he's worked)... Is this sort of the thing that's happened? Things have just gotten so complex, that there's a much larger separation of concerns than there was in the early days of the web?
posted by symbioid at 7:53 AM on May 27


In my experience, yes. It's rare, in the corporate world, at least, so see some guy who is both the designer and the developer. Or who is a designer who knows how to hack together some code. Everywhere I've worked, people are hiring full-out programmers for front-end coding.
posted by grumblebee at 8:07 AM on May 27


If you don't use a framework, you're probably writing your own framework without realizing it. A framework is just common abstracted functionality.
posted by the jam at 9:21 AM on May 27 [1 favorite]


I don't really have much of a dog in this fight, but data binding (and reactive programming in general) seems to be so obviously the right paradigm for UI programming that I can't imagine anyone who does UI programming just dismissing it out of hand.
posted by invitapriore at 9:32 AM on May 27 [2 favorites]


If you don't use a framework, you're probably writing your own framework without realizing it. A framework is just common abstracted functionality.

If you say "we've written our own thing" even if it is wonderful, there is friction there for new devs.

For the last year I've been working on giant steaming single-page mobile/tablet app written in 2009. The "own thing" in this case is not even close to wonderful. So I get the standardization angle.

OTOH, I'm about to inherit a brand-new re-write of a parallel desktop-focused project... rewritten using Angular. And at first I was looking forward to this -- it *had* to be easier to follow/understand than the mobile/tablet app, right? I won't go so far as to say that involving Angular doesn't present any benefits, but they're smaller than I was hoping for, and there are some obstacles. There's being familiar with some core of a framework, and then there's being familiar with the broader set of features and the ecosystem of plugins and tools that the people who wrote your project are going to pick.

And there's a saying that the time involved to really understand a program (or what's going on inside an abstraction) is roughly on the same order of magnitude as it would take you to write it. I think there are some exceptions to this, mostly involving thoughtful and well-refined design paired with similarly good documentation. As far as I can tell, the pace of change in the front-end world right now tends to work against both of those things occurring.

So in a lot of ways, I agree with the author. I do not understand how he's gotten away without wanting data binding, but I concur that you don't need any of the frameworks to get it, and my experience tends to be that often you're better off with libraries of composable small abstractions. Preferable ones you can understand top to bottom in a week or so, even if they only give you 2/3 of the benefit.

This Angular app I'm going to have handed off to me is not going to be that. Maybe I'll feel differently about it when I've had 2-3 months to try and grok all the benefits, but at the moment, I'm not getting any kind of a "I know this, it's a UNIX system!" kind of vibe.
posted by weston at 10:23 AM on May 27


If you're not using at the very least something Underscore (or Lodash, or your favorite toolkit that allows for sensible programming), you're wasting your time. You will need functional methods. You will need to work with collections of things. You will need testable and repeatable ways of doing things that work across browsers, and if you're reimplementing everything your own clever way, you are wasting your and everyone else's time. Maybe you don't like Backbone, or Knockout, or whatever, and that's fine. The problem is that even if you like your hand-rolled data binding system on top of plain HTML views better, pretty much everybody else who has to work with your code will hate you.
posted by OverlappingElvis at 10:30 AM on May 27 [1 favorite]


« Older Johnny Cash Has Been Everywhere (Man)...  |  George Harrison passed away on... Newer »


This thread has been archived and is closed to new comments