Javascript framework fatigue (article)



  • Excellent article that accurately captures the current state of frontend framework landscape.

    Studies show that a todo list is the most complex JavaScript app you can build before a newer, better framework is invented. Luckily, there’s an excellent site called TodoMVC dedicated to comparing JavaScript frameworks by way of todo sample projects. There, you can see how 63 JavaScript app frameworks’ todo examples compare to just jQuery or vanilla JavaScript. If you think 63 frameworks are a lot, you ain’t seen nothing yet: the TodoMVC team gets multiple pull requests weekly from people flogging new JavaScript frameworks.

    Yup.

    When SproutCore and Cappuccino appeared in 2007, I was totally sold by the amazing demos. I’d thought Moore’s law had finally delivered stable, featureful JavaScript frameworks for building beautiful desktop-like apps in the browser. Then I spent two years shipping stuff with SproutCore, dealing with megabytes’ worth of somebody else’s JavaScript, wrestling with weird technical choices necessitated by horrible DOM performance on IE7, and somehow cramming the whole thing into the iPad’s 256MB of RAM. Meanwhile, the documentation never caught up to the pace of breaking changes, and performance was a constant battle. Before long, the dream felt more like an evolutionary dead end.

    SproutCore is the predecessor of Ember, BTW.

    Yes, Angular,js, the framework that I initially described in 2009 as “unreasonably weird” seems to have achieved a level of popularity that no JS app framework ever has. Between serious support from Google, an easy ramp-up path, and a rich community, Angular looks poised to finally settle the…

    Wait, what’s that? The Angular team has decided that Angular 2 will not be compatible with Angular 1.x, and there will be no easy upgrade path?

    Developers familiar with the Angular 1.X will encounter a drastically different looking framework and will need to learn a new architecture.

    Oof.

    Yup. Angular 1.x is just now starting to lose steam, as react is eating its lunch and ember is struggling to catch up.

    Overall, I agree almost completely with what the guy says. The only thing missing are the downsides of the micro-framework Frankenstein approach he's advocating - mistakes in architecture, steep learning curve for new people, time investment etc.

    So what's the solution? There isn't one. Just grit your teeth and pick your poison.



  • Stop writing web applications where a thick client will suffice.

    Seriously how often does it happen that, "This internal thing that is uber-customized to us will maybe possibly make sense to not-us and generate revenue" occur?


  • Discourse touched me in a no-no place

    @MathNerdCNU said:

    Stop writing web applications where a thick client will suffice.

    That ship has sailed. Every dumb shit wants a web app now. We're probably going to have to suffer with "everything's a web page" for another 10-15 years.



  • Or don't use a framework at all. Talk about unnecessary.


  • The Cold Doesn't Bother Us Anyway

    That is the reason I have to wade through the codebase I have at work. IN PHP.



  • We're talking about JavaScript.



  • In my experience, you get the same thing with javascript too.


  • The Cold Doesn't Bother Us Anyway

    So what? The devout 'we don't need a framework' mentality is the reason we have a production application that currently sits in the 1mloc category that is completely unmaintainable.

    The only difference is that JS frameworks come and go faster than the winds change.



  • "devout"? WTF.

    Anyway, fine. Whatever. If you think a JS framework is necessary for some reason, knock yourself out. Personally, I think it's stupid to rely on some other moron's 80k of unmaintainable buggy JavaScript which won't even have compatibility with the next version so you'll have to write it all over again.


  • The Cold Doesn't Bother Us Anyway

    You do seem to preach it a lot.

    Yes, for what we do in my job, we don't need frameworks (PHP or JS). And yes, frameworks do have bugs.

    But given what I've seen in the last two weeks, I think I'd rather have a framework handle a lot of common cases more sanely than the hotch-potch of code I currently have to deal with. That's the reality of frameworks in my experience: it prevents the worst levels of stupid by making it so they don't have to do rewrite things over and over badly.



  • At my job the hotch-potch ("hotch-potch?") is due to the framework. Because the makers of WebAPI2 apparently didn't think it was necessary for a REST API to ever have need to accept a file upload, and it doesn't support multipart/form-data, so we have one and exactly one controller in our codebase that is a nasty mess of bullshit to cover for the incompetent idiotic framework. And our poor front-end has to do TWO AJAX requests if a file is required, with all the additional complexity in error-handling that implies.

    And WebAPI2 is a framework from Microsoft! I can't even imagine how godawful ones from open source developers are.


  • The Cold Doesn't Bother Us Anyway

    I don't know WebAPI but if it does the whole REST thing, doesn't it support PUT?


  • The Cold Doesn't Bother Us Anyway

    30 seconds on Google, and I found an example of file upload using Web API 2:

    The form uses multipart/form-data, and the REST code has attributes and method calls that show that Web API 2 does in fact support that MIME type.



  • @Arantor said:

    I don't know WebAPI but if it does the whole REST thing, doesn't it support PUT?

    Yes. What does that have to do with anything?

    @RaceProUK said:

    30 seconds on Google, an

    Oh Goddamn you fucking idiots, now I have to go into the whole technical thing because GOD FORBID you just take what I type at face value. Fucking ass. You know what? No. I'm not going to explain it because despite the fact that I spent like 3 weeks on this problem (and another co-worker gave up and handed it to me after 2 weeks), you're all just going to ask every tiny little possible question and annoy the fuck out of me for like a month.

    I'll say this much: WebAPI2 does not support multipart/form-data if you're using its auto-hydrate feature.

    Other than that, you'll just have to trust me when I say "in the configuration our company is using, WebAPI2 does not support multipart/form-data" and fucking TRUST ME ON THAT. And if you don't trust me, then fine. Just go away and leave me alone. Look if you're so fucking interested in proving me wrong so you can try to feel smarter than me, then:

    1. You lead a sad pathetic life and
    2. Do it without fucking annoying me about it.

    Although you'd fit in well with the idiots at StackOverflow, where I got that exact example despite explaining IN THE QUESTION ITSELF why that example doesn't work for our project.

    Oh and look I happened to randomly reply to IconWhateverUK so now I'm going to get MOD WARNINGS as an extra super bonus.


  • The Cold Doesn't Bother Us Anyway

    No, you ass, it struck both of us as a fairly typical situation - the kind of problem a framework might have solved, and especially in the case of something like that it occurred to both of us that you might be Doing It Wrong but I forgot that actually you're Never Wrong, pardon me for speculating out loud about something that you might possibly have overlooked that might possibly have been useful.



  • @Arantor said:

    No, you ass, it struck both of us as a fairly typical situation - the kind of problem a framework might have solved,

    Yeah, I fucking agree. Who are you trying to convince? I'm also fucking pissed that WebAPI2 doesn't handle this blatantly obvious problem. Did you not just read how we wasted like 5 weeks of programmer man-hours trying to fix this bullshit the "correct" way before having to implement a giant code ass and cope with it?

    Look, whatever you think of me, if I say the fucking framework doesn't work, it doesn't fucking work, ok? I'm not an open source hack who builds shitty bullshit by gluing together other people's code and then failing to even test that it does, I'm a software developer. But I'm not going to waste my time going into all the subtle details of why it doesn't work, because that's irrelevant to the point I was making, and I sure as fuck didn't ask for help from anybody on this forum on the issue! so don't give me any.

    @Arantor said:

    pardon me for speculating out loud about something that you might possibly have overlooked that might possibly have been useful.

    What is the relationship between the PUT method and whether the framework supports multipart/form-data while making use of the auto-hydrator?


  • The Cold Doesn't Bother Us Anyway

    I don't know, maybe because my understanding of REST was that PUT was designed to be the method for that kind of thing?



  • @Arantor said:

    I don't know, maybe because my understanding of REST was that PUT was designed to be the method for that kind of thing?

    Ok well FYI, there's no relation between the HTTP Method and the Content-Type. Any method can send/receive any Content-Type.


  • The Cold Doesn't Bother Us Anyway

    Thanks for the clarification.


  • The Cold Doesn't Bother Us Anyway

    @Arantor said:

    I don't know WebAPI but if it does the whole REST thing, doesn't it support PUT?

    It does, but generally (IME anyway) file uploads are done via POST. Either way, the HTTP verb isn't really relevant here.
    @blakeyrat said:
    I'll say this much: WebAPI2 does not support multipart/form-data if you're using its auto-hydrate feature.

    Not sure I buy that, but I have limited experience with any version of Web API, let alone v2.
    @blakeyrat said:
    Other than that, you'll just have to trust me when I say "in the configuration our company is using, WebAPI2 does not support multipart/form-data" and fucking TRUST ME ON THAT.

    Now you've explained it's a fucked-up config, I will trust you on that ;)
    @blakeyrat said:
    Oh and look I happened to randomly reply to IconWhateverUK so now I'm going to get MOD WARNINGS as an extra super bonus.

    If you do, it would be unfair.


  • I survived the hour long Uno hand

    @blakeyrat said:

    I'm not an open source hack who builds shitty bullshit by gluing together other people's code and then failing to even test that it does, I'm a software developer.

    At my job, the people who call themselves software developers are actually hacks who build shitty bullshit by gluing together other people's code and failing to test. Which is why I like the idea of sticking with a framework: I don't want to see the code they'll write to handle common use-cases that have plagued every developer since the web was invented.

    If the whole office was staffed with people like me and Blakey and Arantor, I'd be 100% in favor of throwing frameworks out the window.



  • I think even simple math says "if you spent 5 developer-weeks figuring out how to do a file upload to a REST controller without anally-raping the framework's assumptions" makes the framework not worthwhile.

    Even considering all of the security issues around a REST API framework, I've written by own from scratch in less than 5 weeks. And it did the exact same amount of work as WebAPI2. And if we had been using that, and had needed file uploads, I could have just written them into the framework because mine isn't a huge sealed DLL.

    I honestly don't think the math for using frameworks ever adds-up. Because the first instant you hit a snag (and you always hit a snag), you've lost whatever time savings you gained by choosing the framework in the first place. Especially a framework for something as damned simple as a REST API over HTTP, the easiest protocol.

    Now to be clear: I'm not saying re-implement .net's System.Web from scratch, that would be stupid. But System.Web and System.Net already give you 90% of a REST API "framework", adding the rest is trivial.

    Frameworks save time for the guy who wrote the framework. That's about the only clear assertion you can make for them. (Remember the thread about Enlightenment? There was a guy in there who thought his GUI framework was awesomesauce. When you adopt a framework, you're doing it at the say-so of someone like him.)


  • The Cold Doesn't Bother Us Anyway

    If there were competence everywhere, I could agree with you. Though having something well tested and ready to go is a fairly nice-to-have thing, especially when dealing with crap like incoming data, sanitisating, auth, sessions, where having a ready-to-go solution that's proven and works is a major asset.

    On the other hand, people who don't use frameworks when they should... result in the kind of mess I've been writing up in the Lounge.

    I don't need a framework myself, per se, I could write one in PHP... but the reality is that I do like having all the really boring-ass stuff done for me so I can concentrate on the domain specific stuff. But my domain seems to be a little different to yours where opening great big wide holes in the system is trivially achievable.



  • @blakeyrat said:

    you just take what I type at face value.

    Oh ... the kind of thing you do with what others say all the time?



  • @Arantor said:

    Though having something well tested and ready to go is a fairly nice-to-have thing, especially when dealing with crap like incoming data, sanitisating, auth, sessions, where having a ready-to-go solution that's proven and works is a major asset.

    I assume that was the impetus for picking WebAPI2 in the first place. Who would have imagined that while it did all that shit correctly and bug-free, it was missing such a basic fucking feature as HANDLING FILE UPLOADS?

    Even worse, the classes in WebAPI2 are all sealed, so if you want to write custom code to get it to handle file uploads well... fuck you!

    @Arantor said:

    I don't need a framework myself, per se, I could write one in PHP... but the reality is that I do like having all the really boring-ass stuff done for me so I can concentrate on the domain specific stuff.

    Well you're using PHP so.

    I'm talking about C#, a good language.

    In any case, all I'm saying is: do the math. Did the framework save you time? Can you prove it?

    @Luhmann said:

    Oh ... the kind of thing you do with what others say all the time?

    If you ever see me provide unsolicited advice (that isn't an obvious joke), you can punch me right in the gut. You have my permission. Unsolicited advice is the fucking worst.


  • I survived the hour long Uno hand

    Yeah, but I'm talking about JS frameworks, we don't use C#. We don't even use Coldfusion as of this quarter, we're switching to Node.js. We don't have the benefit of a well-thought-out System.Web and System.Net; we have jQuery, maybe, sometimes, when we're not using YUI. And some of my coworkers are talking about going frameworkless for our newest product.



  • @Yamikuronue said:

    we're switching to Node.js. We don't have the benefit of a well-thought-out System.Web and System.Net;

    Well you could pick good tools in the first place, instead of the open source shit. JavaScript in particular has no base libraries to build off of. Except a few simple math functions and a bunch of half-broken date functions.

    I guess I need to add a disclaimer to my advice: "NOTE: Blakeyrat assumes you're using technology that doesn't suck ass when providing this advice".



  • If it was only for web. The place I work at has its own framework and the BBC also has one for multiple TV devices (TAL)


  • The Cold Doesn't Bother Us Anyway

    @blakeyrat said:

    Well you could pick good tools in the first place, instead of the open source shit. JavaScript in particular has no base libraries to build off of. Except a few simple math functions and a bunch of half-broken date functions.

    Node.js <> Javascript.

    NodeJS provides a large and extensive base library on par functionality wise with C# or Python.

    But then you already knew that.



  • @MathNerdCNU said:

    Stop writing web applications where a thick client will suffice.

    Seriously how often does it happen that, "This internal thing that is uber-customized to us will maybe possibly make sense to not-us and generate revenue" occur?

    Never, but that doesn't stop "the executives" from thinking it will happen because they are "experts" in the industry. So it doesn't matter because the boss wants a web app that could be sold to others even if it's a stupid idea to jury rig an internal app like that.



  • That's because HTML5 is a proper application platform, multiplatform and open, something that I would argue is THE final goal of computer engineering, and that nobody else has managed to do before.

    Don't blame HTML for succeeding, blame everyone else for not building something better before.

    @blakeyrat said:

    auto-hydrate feature

    That's an hilarious name.



  • This post is deleted!


  • @accalia said:

    NodeJS provides a large and extensive base library on par functionality wise with C# or Python.

    But then you already knew that.

    Functionality wise... sure. Quality wise? Nope.



  • @cartman82 said:

    Excellent article that accurately captures the current state of frontend framework landscape.

    There are too many of them, and they either suck, suffer from ADD development, or both.

    No shit, Sherlock.



  • @anonymous234 said:

    That's because HTML5 is a proper application platform, multiplatform and open, something that I would argue is THE final goal of computer engineering, and that nobody else has managed to do before.

    Don't blame HTML for succeeding, blame everyone else for not building something better before.

    Although there are already pundits who are predicting the fall of the open web and the rise of walled garden apps as the next big thing. And I must say, they sound pretty convincing, at least as far as the commercial user-space is concerned.



  • @cartman82 said:

    If you think 63 frameworks are a lot, you ain’t seen nothing yet: the TodoMVC team gets multiple pull requests weekly from people flogging new JavaScript frameworks.

    That's nothing exclusive to frameworks though. Look up how many wiki software there are: hundreds. Same with media players, text editors, and plenty of other stuff. People set out to write their own one because they're bored, or to practise their programming skills, or because they're stupid. You just have to learn to focus on the 5 or 10 most popular and ignore the rest.


  • The Cold Doesn't Bother Us Anyway

    @cartman82 said:

    Functionality wise... sure. Quality wise? Nope.

    i'd argue quality wise as well. the standard library that nodejs uses is extremely well documented and behaves beautifully. the local GUI libraries are third party and a piece of crock, yes. but that's not the design intended use of nodejs, hence why they're not part of the core library.

    NodeJS also suffers the same problem that C# and Python suffer, in that while the core library is rock solid and nice (with a few rough edges (i'm looking at you /urllib(2|3)?/)) the third party libraries are not curated for quality, nor are the lesser known but potentially superior ones likely to be maintained long in the absence of a large userbase.

    NodeJS shows that problem more than the other two because of NPM and culture which encourages gluing together third party libraries until you have what you want. a Lego(tm) approach to coding if you will. This leads to subpar code but is not the fault of the language or the core library, rather it is how that core library is used as glue between different third party libraries of undetermined quality.



  • @accalia said:

    i'd argue quality wise as well. the standard library that nodejs uses is extremely well documented and behaves beautifully. the local GUI libraries are third party and a piece of crock, yes. but that's not the design intended use of nodejs, hence why they're not part of the core library.

    Standard node.js library is an abomination that's not following its own supposed standards. Case in point: http.listen.

    @accalia said:

    NodeJS also suffers the same problem that C# and Python suffer, in that while the core library is rock solid and nice (with a few rough edges (i'm looking at you /urllib(2|3)?/)) the third party libraries are not curated for quality, nor are the lesser known but potentially superior ones likely to be maintained long in the absence of a large userbase.

    NodeJS shows that problem more than the other two because of NPM and culture which encourages gluing together third party libraries until you have what you want. a Lego(tm) approach to coding if you will. This leads to subpar code but is not the fault of the language or the core library, rather it is how that core library is used as glue between different third party libraries of undetermined quality.

    NPM is a victim of its own success. It has a super low cost to entry and super-comfortable usage pattern. Thus people who'd never dream publishing a library in something like C# are publishing stuff like crazy to npm, and other people are actually using their stuff. It's both the best and the worst feature of the node.js ecosystem.

    The best because it raises the programming level in general. Anyone who has ever open sourced a piece of code knows there's no better incentive to improve your practice than having a bunch of strangers digging through your stuff. Coders who'd otherwise keep churning out crap siloed on some corporate svn are suddenly thrust into the open and forced to give their practices a second thought. And anything that motivates people to become better coders is a net positive in my opinion.

    The worst because, well, you get stuff like the awful redis driver and similar crap.


  • The Cold Doesn't Bother Us Anyway

    @cartman82 said:

    Standard node.js library is an abomination that's not following its own supposed standards. Case in point: http.listen.

    In what way doesn't it meet the standards?
    @cartman82 said:
    NPM is a victim of its own success. It has a super low cost to entry and super-comfortable usage pattern. Thus people who'd never dream publishing a library in something like C# are publishing stuff like crazy to npm, and other people are actually using their stuff. It's both the best and the worst feature of the node.js ecosystem.

    It also works like this:
    @cartman82 said:
    NuGet is a victim of its own success. It has a super low cost to entry and super-comfortable usage pattern. Thus people who'd never dream publishing a library in something like C++ are publishing stuff like crazy to NuGet, and other people are actually using their stuff. It's both the best and the worst feature of the C# ecosystem.

    The only reason there's more garbage available via NPM is because Node is 't3h nu h0tn355' and because it's truly multiplatform.



  • @RaceProUK said:

    The only reason there's more garbage available via NPM is because Node is 't3h nu h0tn355' and because it's truly multiplatform.

    I never published anything to nuget and have no idea how I'd even go about doing it.
    Haven't heard of any great rush of C# libraries, nothing like the npm goldrush.



  • @RaceProUK said:

    In what way doesn't it meet the standards?

    Ugh, don't have the time to rant right now.

    Here's the task, see if you can code this:

    Create an express API (or any kind of http.listen app) wrapper that you can start and stop at will, and that handles all errors.

    So no letting a thrown error crash the app, properly handling "port busy" sort of stuff.

    You'd think you could just do something like this:

    var server = http.createServer(expressApp);
    server.listen(port, function (err) {
      if (err) {
        // Ooops, better examine the error and determine the fail condition.
      }
    
      //...
    
      server.close(function (err) {
        if (err) {
          // failed to close the server, let's log this
        }
      });
    });
    

    You know, the standard node way to do things, that node itself advocates. But no, because native node API was written by fucking monkeys, who are throwing, returning error codes and calling callbacks however they want, with zero regards to their own best practices.

    There I ranted. No time to go into details. Just try it and find out.


  • The Cold Doesn't Bother Us Anyway

    @cartman82 said:

    I never published anything to nuget and have no idea how I'd even go about doing it.

    It's more long-winded than strictly necessary, but it's nothing your average VS codemonkey can't do.
    @cartman82 said:
    Haven't heard of any great rush of C# libraries, nothing like the npm goldrush.

    It helps that MS provided quite an extensive framework for C# (and .NET in general), meaning there are a lot less gaps to plug.


  • The Cold Doesn't Bother Us Anyway

    @cartman82 said:

    Create an express API (or any kind of http.listen app) wrapper that you can start and stop at will, and that handles all errors.

    Someone already did :stuck_out_tongue:



  • @RaceProUK said:

    Someone already did

    You can't do request callback with socket.io as far as I know (just blind send).

    Also, I actually did create a wrapper for an express http + https API. And it's 500 lines of defensive code I wish I didn't have to write and maintain.


  • The Cold Doesn't Bother Us Anyway

    @cartman82 said:

    You can't do request callback with socket.io as far as I know (just blind send).

    I believe the intention is you don't need request callback, as you can get the same results with emit and on.


  • I survived the hour long Uno hand

    @anonymous234 said:

    focus on the 5 or 10 most popular and ignore the rest.

    Great! What are they?

    If I google "wiki software", MediaWiki shows up real high on that list. TWiki's the only other actual wiki software on the front page, beside all the "compare all the wiki software ever" sites. It's obvious who's winning that war.

    If I google "blog platform", I'd find Blogger, Wordpress, and something called Ghost pretty high up the list. Nice narrow choices.

    On the first page alone for "node framework" I have Express, Koa, Hapi, Sails, Total.js, Mocha (which isn't even the right kind of framework" and Chai (which isn't even a framework). Page two gets me into Geddy, Locomotive, Loopback, and Sleek. The first comparison article on page 1 lists 13 frameworks. The next lists 35.

    So which of these are the top five?

    • Meteor
    • Express
    • Sails
    • Mean
    • Koa
    • Connect
    • Hapi
    • Socket.io
    • Socketstream
    • Spine
    • Wintersmith
    • Generator-meanjs
    • Tower
    • Compound
    • Total.js
    • Express.io
    • Flatiron
    • Locomotive
    • Bone.io
    • Frisby
    • Stapes
    • Sane
    • Diet
    • Zappa.js
    • Turtle.io
    • Grasshopper
    • Twee
    • Coke
    • Raddish
    • Webjs
    • Spludo
    • Sleekjs
    • Trinte
    • Kissjs
    • Genji
    • Geddy


  • @Yamikuronue said:

    ...Express, Koa, Hapi, Sails, Total.js, Mocha (which isn't even the right kind of framework" and Chai (which isn't even a framework). ..Geddy, Locomotive, Loopback, and Sleek. ...

    "Framework" developers need to stop playing drunk scrabble before they come up with names for stuff. As silly as I think the Java world slapping J-infront of everything is, I can usually tell by the name what the framework/library does.


  • I survived the hour long Uno hand

    My favorite is Twee. It's like, "I thought about using a framework, but the ones I looked at were so twee I gave up."


  • The Cold Doesn't Bother Us Anyway

    @MathNerdCNU said:

    As silly as I think the Java world slapping J-infront of everything is, I can usually tell by the name what the framework/library does.

    And you can tell the ones that got ported to .NET because they change the J to and N and that's it.

    NHibernate, NUnit, yes, I am looking at you… Oi! Don't look at me like that! You know you're just ports of Java frameworks… Fine! Then you can just sit on the naughty step for five minutes! Go on, get outta here!

    Right… where was I…


  • Discourse touched me in a no-no place

    @anonymous234 said:

    Don't blame HTML for succeeding, blame everyone else for not building something better before.

    I don't (as much). I blame the browser makers, mostly for providing such a shitty operating environment.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.