What JS MVC library is least full of bullshit?


  • I survived the hour long Uno hand

    At my company, we're really not liking Backbone. The inability to stitch together pieces of information from multiple discrete models nicely into the same view is the most obvious complaint, since it's the place where I feel our ways are not like Backbone's ways. Is there a better replacement we should look at? Some of our devs are inherently opposed to the idea of a dumb frontend to a smart server, wanting to AJAX a lot of data and do the view processing on the front; one of our mobile sites is a pure JS one-page app. So I'm just looking at javascript libraries here.



  • I know I'll get some hate for this, but if it's for enterprise applications and you don't care much about looks, Sencha is the least bullshit one I've used. ExtJS is an excellent MVC with a clear separation of concerns, with a great model system backed by a REST back end. Also, it's been around for a good while, so it's very stable and has great support and documentation. Bad thing might be that everything is JavaScript code, no HTML, so themeing is very hard. At least in my case it has been the fastest, easiest way of getting a SPA running and doing quite hard stuff.

    Oh! And it's the only MVC framework I found where localization wasn't fucked up.


  • I survived the hour long Uno hand

    I should probably add that we'll have to bastardize the persistence layer since The Powers That Be don't like REST or JSON. They like XML-based services which respond to POST parameters. We've overridden Backbone.sync() on a platform level to handle it at the moment.


  • FoxDev

    @Yamikuronue said:

    They like XML-based services which respond to POST parameters

    ..... did the powers that be work at M$ at any point. because that really sounds like M$ koolaid....


  • I survived the hour long Uno hand

    We do use SQL Server on IIS machines..... >.>



  • But... you've already written it in Backbone? So... you're going to start over? Or do you do like a bunch of small projects?

    My recommendation would be to throw the frameworks in the trash and write your own damned code to do what you want. Especially if you do a bunch of small projects. The entire MVC concept is strange and dumb, and I've never once worked on a project simple enough to fit into its rules. If you like it, fine.

    If you don't have anybody on your team competent to write such a basic bit of code in JavaScript, you got bigger problems.

    @accalia said:

    ..... did the powers that be work at M$ at any point. because that really sounds like M$ koolaid....

    How is that "M$ koolaid"? That's how REST always worked, before JSON came along.

    If they're still using goddamned SOAP (which actually is a Microsoft invention, IIRC), then you got bigger problems. Nobody uses SOAP no more. Microsoft itself hasn't used it in a decade.


  • I survived the hour long Uno hand

    @blakeyrat said:

    So... you're going to start over?

    We've got a few big new projects coming up, and we're looking really hard at our past choices to decide if we want to continue making them.

    @blakeyrat said:

    That's how REST always worked,

    We don't use HTTP verbs properly, so I don't call what we're doing REST :/ Everything's a POST request, even when it's data retrieval. We also have endpoints per-service, not per-item, so there's no canonical URI for a given object



  • @blakeyrat said:

    nobody uses SOAP no more.

    people stinks.



  • My issue with MVC is that I'm always writing reporting apps with the flexibility to allow people to write their own schemas. So I never have a "model", or at least nothing worth calling a "model" since the data object changes based on the query the user sent in. Usually you end up having to dummy-up a pointless model to make your MVC app happy, which does nothing but confuse everybody involved.

    And then it gets worse because there's also no "view" because I'm retrieving the data to build the chart from a REST API call and nothing goes on the screen, the view is all in JavaScript. If you even call that a "view", it's usually just a chart inserted into another view. So I have a MVC app which consists of nothing but a million controllers and nothing else, or everything else dummied-out to make some idiot framework assumption happy.

    I think it's safe to say I've never worked on a web application where the MVC philosophy made sense. Even if you did, you'd need something like a MVCC, because it's makes no sense for the model to be in the JavaScript code, the model is always on the server. But then you need two controllers, one for the server to communicate with the front-end and one for the front-end to do the reverse and... anyway just write your own. Buzzwords suck.

    EDIT: oh and when you do write your own, don't write that bullcrap "hey let's pretend JS works best as a functional language kinda" crap that all the Git-hosted JavaScript libraries love. It's not any faster than traditional code, it's not any easier-to-read than traditional code, but the real selling point is it means whenever you hit "break" in the debugger every stack frame is (unnamed function) usually at least 10 functions deep. I love me some code that's impossible to debug.


  • I survived the hour long Uno hand

    Here's the basic idea of how I'm picturing a good use of Backbone or a Backbone-replacement would go:

    1. We have well defined output from our services, which can be validated using an XSD. Therefore, when we call a service to retrieve logical objects from the database, we should store them in actual objects which are well-defined and encapsulate the logic of calling the service to update or fetch themselves. This is in line with Backbone's philosophy, and is the part that works well for us. Add self-validation to that and you have a good model layer. In javascript.

    2. We are in the process of building out re-usable components for commonly used view objects across multiple apps. These would be the view layer. As you mentioned charts, I'll run with that: the view code takes our product models and what have you and displays them in charts. This part is pretty much self-evident.

    3. We need a place to store the logic of the actual application, which would be the controller. Things like "Once you selected a widget from the chart that has to get passed to the next page, and update your session with five or six parameters in case you wander off and we want to prompt you to resume your cart when you return." There's no real good place for that in Backbone, we ended up with a gigantic "cart" model that has a billion non-cart things in it because that was convenient. Or something.

    4. Sometimes we want to display multiple models in the same view. For example, in a hallway dashboard I maintain, I want to show both test results (sourced from the Jenkins API) and linting results (a different part of the Jenkins API) and build number (a different endpoint altogether). I could build a model of a build, which contains a model of test results and a model of linting results, but models don't contain other models in Backbone, that's just "not done".

    So all of this is going on in the Javascript layer, quite aside from the service layer and the front-end server-side layer (which is doing less and less every day, for whatever reason, our devs are mostly javascript devs I guess) and the persistence layer.


  • I survived the hour long Uno hand

    @blakeyrat said:

    I love me some code that's impossible to debug.

    God, that shit is hell. 100% agree.

    Part of my frustration in this role is that I've never been on the JS hype train, but since I was hired in I've seen our server-side devs move on and our front-end guys pretty much take over the web team, and they're huge on the JS. Any day now I expect to hear from the Powers That Be that we're embracing Node.JS, since when they asked about changing languages for our next big platform project that was "our" recommendation. I'm not sure I've ever seen GOOD Javascript. It's all some degree of terrible.



  • Well number 1 is super-easy, you don't need Backbone for that. It's like, maybe 10-15 lines of jQuery + JS and then whatever it takes to validate.

    Number 2 is just a templating engine like handlebars. Those work fine on their own, you don't need backbone.js for that, either. That's trivial. I think Handlebars can do views-in-views, but if it can't you might have to write a few lines of code there. As an added bonus, handlebars is small and not full of slow idiot code.

    Number 3 is confused confusion. "some place to store the logic of the application"? I don't even get that. The logic of the application is the application, right? You just ... write it. It's "stored" in the DOM. Right? I don't really get the need there. Or are you just talking about reducing the usage of the window namespace?


  • FoxDev

    @blakeyrat said:

    How is that "M$ koolaid"? That's how REST always worked, before JSON came along.

    hmm.... the misuse of HTTP verbs, the love of XML (and worse XSLT (or even worse, NESTED XSLT)) just to get started.

    now don't get me wrong XML is a nice tool, and XSLT can be a slick tool, but it's not the only tool you need in your toolbox.

    in particular if i'm passing data to JS i'd much rather use JSON than XML because there are enough DOM parsing bugs in browsers these days i don't want one of those in MY data.

    but to each their own.


  • I survived the hour long Uno hand

    "some place" being some file organized in our filesystem that will be included in the finished page. Our models go in the /models folder and our views go in the /views folder; in our oldest apps, our page logic goes inside the page itself, then in newer ones, it goes in a pagename.js file right beside the page itself. Theoretically it could go in a /controllers folder if we were using controllers, but Backbone doesn't have those.

    We use handlebars, but it can't do much in the way of display logic other than "if key exists, display this". I'm talking about various animated or otherwise interactive widgets. Handlebars is also fucking impossible to debug. It just doesn't work. Why not? some random error deep inside handlebars.min.js. Okay, use the expanded version. What line? Some random if statement deep in the bowels of the application is choking on a null pointer exception. WTF? What's wrong with my input? No idea. The gods of Handlebars don't like me today.

    Number 1 is a lot easier with Backbone. It makes it about 2-4 lines of code and bam, usable model. No logic required, just point it at an api and go. Except for all the exceptions. Those are messy.



  • @accalia said:

    in particular if i'm passing data to JS i'd much rather use JSON than XML because there are enough DOM parsing bugs in browsers these days i don't want one of those in MY data.

    Well duh, but what you're missing is that JSON is a thing that needed to be invented and popularized by somebody. That's like the Raymond Chen question, "why didn't they use the Space Shuttle to rescue Apollo 13?"

    If you're writing a web service before JSON was popularized, you used XML. That's all there was. The fact that this company is still using it just means that they haven't rewritten working code. Well, big whoop. Not rewriting working code is smart, not dumb.


  • I survived the hour long Uno hand

    @blakeyrat said:

    The fact that this company is still using it just means that they haven't rewritten working code.

    Nah, we've been ordered that all services MUST return XML. Finally someone pointed out "It says the have to return XML, not that they can't also return JSON", so some of the newer ones return both depending how they're called. Our architecture team is afraid of change.



  • @Yamikuronue said:

    "some place" being some file organized in our filesystem that will be included in the finished page. Our models go in the /models folder and our views go in the /views folder; in our oldest apps, our page logic goes inside the page itself, then in newer ones, it goes in a pagename.js file right beside the page itself. Theoretically it could go in a /controllers folder if we were using controllers, but Backbone doesn't have those.

    Put it where ever. Just come up with a standard way of naming it, and there you go. It's your app.

    @Yamikuronue said:

    Handlebars is also fucking impossible to debug. It just doesn't work. Why not? some random error deep inside handlebars.min.js. Okay, use the expanded version. What line? Some random if statement deep in the bowels of the application is choking on a null pointer exception. WTF? What's wrong with my input? No idea. The gods of Handlebars don't like me today.

    Yeah well, welcome to EVERY FUCKING JAVASCRIPT LIBRARY ON GITHUB apparently all of which are written by dumbshits who don't know what debuggers are. Or maybe there's some open source conspiracy to make people want to actively hate debuggers and think they are useless.

    Handlebars is a million times better than D3.js and Raphael.js.

    @Yamikuronue said:

    Number 1 is a lot easier with Backbone. It makes it about 2-4 lines of code and bam, usable model. No logic required, just point it at an api and go. Except for all the exceptions. Those are messy.

    I don't see 2-4 lines as being significantly "easier" than 10-12 lines, all of which you understand clearly. But hey whatever; tear that bit out of Backbone and use it without the rest, then.


  • I survived the hour long Uno hand

    @blakeyrat said:

    Handlebars is a million times better than D3.js and Raphael.js

    Agreed. I was hoping there's some library that isn't full of undebuggable bullshit, and if anyone knew of one, it'd be someone on here... :/

    D3 has forced me to learn how to hand-craft SVG files. I never thought I'd need that skill set. But D3.js is approved while chart.js is not, and I needed a pie chart.



  • @Yamikuronue said:

    D3 has forced me to learn how to hand-craft SVG files. I never thought I'd need that skill set. But D3.js is approved while chart.js is not, and I needed a pie chart.

    Seriously?

    You work for idiots. D3 is the worst choice for something like a pie chart. Unless you want to animate it in 47 different ways.

    D3 is for making stuff like this.


  • I survived the hour long Uno hand

    yeah, it was approved for some really cool floating-bubble response time visualization someone needed in the operations room, and then when I asked about chart.js, they said "Can you use d3? We already approved that."

    I have the bubble thing open on the monitor next to my information radiator project. WebGL crashes at least once a day.


  • FoxDev

    @Yamikuronue said:

    "Can you use d3? We already approved that.

    .... this sounds like it's time to start quietly planning an exit strategy if you ask me.


  • I survived the hour long Uno hand

    This post is deleted!


  • Look if stuff has to be "approved" I don't know how to advise you. It sounds like you can't use anything except what you're already using, so they'd probably say the same thing about any alternatives to backbone.js. It would be one thing if they approved a specific license, like "all GPLv2 code is ok", but approving a specific library? Nasty.

    I'm with Accalia, get out of there. If your company doesn't trust you to make simple decisions, then you don't want to work for them and they don't deserve your talents.


  • FoxDev

    huh... if you have your edit history visible and withdraw the post after the ninja edit period closes we can see your post without flagging to have it undeleted.....

    is that supposed to happen?


  • I survived the hour long Uno hand

    I have no idea. I decided it was a hopelessly optimistic thing to say around here, but there's no ninja delete period XD

    My company is getting better. Slowly. But surely. I can't make a recommendation if I don't have anything to recommend. If I could make a case for something to replace backbone, I could probably get enough support to push it through, but replacing it with nothing is a non-starter.


  • FoxDev

    @Yamikuronue said:

    If I could make a case for something to replace backbone

    i don't do much MVC work....

    boss swears by AngularJS

    boss+1 wants us to use KnockoutJS

    accounting just wants us to shutup and give them their reports.

    don't know why i thought that was relevant....

    anyway googling found this site which might help?



  • Yeah sorry, I can't help you. Like I said, I usually just try to avoid stuff like huge complicated MVC frameworks. Knowing you have to have your schoolmarm tell you which code is ok and which will get you rapped with a ruler, I doubt they'd let you say "we'll write our own". Because OMG RISK!!!


  • I survived the hour long Uno hand

    Sometimes "we'll write it our own damn selves" is honestly easier than getting things approved.



  • Right; and the other thing is they don't have to know you're not using backbone.js still. It's not like the guys who approve that shit ever go back and say, "hey we double-checked and you're not actually using it!"

    EDIT: I always wanted to be the guy at a big stodgy corporation who approves stuff. Although I'd probably be fired after I just said yes to fucking everything, because goddamned. If you can't trust your own employees, it's your hiring that's the problem, not the code libraries you use.



  • @blakeyrat said:

    If you can't trust your own employees, it's your hiring that's the problem, not the code libraries you use

    These types of companies tend to use a lot of short term contractors. Often the rigidity of "only use these things" is their to attempt to make the things that fifty different people did kind of look the same. Essentially they gave up on the idea of selecting the right people and instead choose to use a lot of cheap people.

    The last place I worked kept the list of approved applications and strove to keep the list as short as possible. They were very proud when they got it down under a thousand. We did our part by taking every piece of custom code we had and giving it one product name - problem solved.



  • @Yamikuronue said:

    If I could make a case for something to replace backbone, I could probably get enough support to push it through, but replacing it with nothing is a non-starter.

    The only one that I have seen that is not full of bullshit is Mithril. Note I have not used it in Anger yet.



  • @blakeyrat said:

    Nobody uses SOAP no more. Microsoft itself hasn't used it in a decade

    Oh please, you're so full of ignorance that I couldn't ignore it any more. SOAP is alive and kicking in every freaking enterprise, bank and financial system. About your BS that MS isn't using it, their top of the line streaming software uses SOAP and that's the only software from MS I'm exposed this days. A quick search should bring me more results easily.

    And yes, MS invented SOAP but it was so full of propietary shit that it had to be pretty much rewritten by IBM so it could be interoperable.


  • Discourse touched me in a no-no place

    @accalia said:

    accounting just wants us to shutup and give them their reports.

    Sounds like the sensible move. Users don't give a shit about what libraries you use. If they care, they're no longer true users…



  • "We want our reports, and make them with Crystal Reports"

    "But, but..."

    "C-R-Y-S-T-A-L-R-E-P-O-R-T-S"

    Note: IDK anything about CR, but it gets some hate and is pretty known.



  • @blakeyrat said:

    Although I'd probably be fired after I just said yes to fucking everything, because goddamned. If you can't trust your own employees, it's your hiring that's the problem, not the code libraries you use.

    Yup, and then you end up with a clusterfuck where everybody uses their pet language and framework. C#? Sure, go ahead. VB? Yeah, it's the same as C# anyway. IronPython? Oh well, you wanna be a special snowflake, you can have it. TI-82 BASIC? If you can interface it with the rest of the app, you're golden.

    Which might not be bad in itself... but then the original devs move on, and suddenly you're looking for a TI-82 BASIC professional.



  • @Yamikuronue said:

    D3 has forced me to learn how to hand-craft SVG files. I never thought I'd need that skill set. But D3.js is approved while chart.js is not, and I needed a pie chart.

    I have never had too much trouble with D3, but I have needed it for dynamic user controlled visualizations where its fine grain control was perfect.

    @accalia said:

    boss swears by AngularJS

    I wouldn't swear by it, but it is what I would/have picked. I think it is the best option available right now. However, IMO, these libraries are being way overused. I don't think EVERYTHING should be a single page JavaScript app...


  • FoxDev

    @jaming said:

    However, IMO, these libraries are being way overused. I don't think EVERYTHING should be a single page JavaScript app...

    QFT


  • Discourse touched me in a no-no place

    @jaming said:

    I don't think EVERYTHING should be a single page JavaScript app...

    Yet you're here, using Discourse…


  • I survived the hour long Uno hand

    Don't get me wrong, I like learning new things, but how to craft an SVG wasn't high on my list for this year.



  • @Eldelshell said:

    SOAP is alive and kicking in every freaking enterprise, bank and financial system.

    It's alive and kicking in enterprises that use 1970s technology. Gotcha.

    @Eldelshell said:

    About your BS that MS isn't using it, their top of the line streaming software uses SOAP and that's the only software from MS I'm exposed this days.

    I don't know what "streaming software" you're talking about (does it have a name?), so I can neither confirm nor deny this claim.

    @Eldelshell said:

    And yes, MS invented SOAP but it was so full of propietary shit that it had to be pretty much rewritten by IBM so it could be interoperable.

    You should probably spell MS with a dollar sign.


  • Fake News

    @blakeyrat said:

    It's alive and kicking in enterprises that use 1970s technology. Gotcha.
    ... And also at least one that started a couple years before the dot-bomb. I should know; I work for them.



  • The dot bomb was in 2000, so I find that extremely believable. I don't know what other than SOAP even existed then.


  • Java Dev

    Ah, yes. The joys of SOAP. In PHP. Using the builtin SoapServer class. Least we're allowed JSON when talking to anything other than $ENTERPRISE_PARENT_PRODUCT.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    It's alive and kicking in enterprises that use 1970s technology. Gotcha.

    What's the business case for rewriting all that code that still works[1]? This is one of the things people bitch about about Microsoft. "If I rewrite my application in .Net, that's a year of time I could instead spend on writing new features." That was an actual complaint, sometimes followed with "and also time Microsoft's competing product could add new features, thus gaining on us."

    [1] for the purpose of this post.



  • MS PlayReady™.

    Most of, if not all OLTAs use SOAP with their providers (Hotels.com, Expedia, Galileo, Amadeus) so every time you search for a flight online, you're using SOAP indirectly.

    Thinking that SOAP, Corba, RMI are being replaced by REST is stupid.



  • The problem with a lot of these JavaScript MVC frameworks is the performance or the lack of it. Also the page weight is a no go if you are planning on supporting mobiles (some of the older Android and Blackberry devices are just no goes with these frameworks).


  • Discourse touched me in a no-no place

    @Eldelshell said:

    Thinking that SOAP, Corba, RMI are being replaced by REST is stupid.

    There's quite a long way to go on that front. It's not that it's impossible to express the operations (though some map more easily than others) but rather that the state of metadata about what's going on in REST is nothing like as mature. What's more, there's a bunch of REST Advocates about who think that publishing such metadata is wrong and evil, and that clients should just have to adapt. Also known as “service automation by outsourcing the workflow to India”.

    REST is quite nice. Many of its proponents need a damn good slap with a clue-by-four.



  • The original question. Frontend javascript framework. My experiences so far were mostly dealing with admin panels, so take this for what's it worth.

    • Everything custom written in javascript (a la blakeyrat).
      Unless you're a world class expert, skip. Even if you are a world class expert, skip. You won't make a better framework than a team working on it full time. Maybe OK for a simple or highly specific site (eg. not an admin panel).

    • Dojo
      Supposedly a "hidden gem". I was drawn because it comes with a huge library of decent looking graphic widgets. But I could never get into it. Trying to learn it was torture. Also, at the time I was investigating it, they were in some kind of transition phase (AMD loading, new mobile-friendly view layer), so things were in flux documentation-wise. Things might be better now, although by the missing "buzz factor", I doubt it.

    • Ember.js
      I did a project in this. It's pretty much what you see on Discourse. It's actually nicely designed and well suited for large applications. Unfortunately, view layer is slow (which HTMLBars might or might not fix) and code is inscrutable and difficult to get into.

      Also they have this thing called "ember data" that's a bit of a mess. Both I and Discodevs steered away from it and wrote our own.

      Still, from the two major MVC frameworks, I'd say this is the better one.

    • Angular.js
      The second major MVC framework. Played around, finished tutorials and shit. Looks nice. View layer is definitely faster than Ember. Dependency injection is nice, although fatally flawed for minified sources (what a momentous fuckup that was).

      Unfortunately, due to their complete reliance on dirty checking, it seems their performance issues are there to stay. Also recently they announced Angular 2.0, which will basically be completely different. So if you start ang1 app now, it will become legacy by the time you finish.

      What can I say. It's a Google' dev tool, which means it's shiny on the surface, but smelly underneath. I could see myself doing an angular project, but I'm not in love with it.

    • Knockout
      Very brief look at an existing project. It's basically ember-like object model, without router and other cruft. If you want to pick and chose, there's supposedly some "knockout + x + y" combination that gets you the full MVC stack. Overall: nothing against it, nothing for. Don't know.

    • React
      This is the latest fashion. Facebook-s "Anti-MVC" framework. I played around for a bit. Seems pretty thin, basically just the view layer. So there's another thing that wraps it, called Flux. I haven't had the time to look into these, so if someone has, I'd appreciate some insight.

    Overall, if I had to do a SPA project right now...

    • ...if for company, I'd go with Ember again, because I know it the best, it has solid mind share (no. 2) and seems to be going somewhere in terms of development (frequent updates, htmlbars)

    • ...if for me personally, I'd go with angular 2.0 or react, depending on availability and initial research. Based on the coolness factor + market share + job prospects.



  • Overall, I agree with most of your points, but I am curious why you think Angular DI is fatally flawed for minified sources?



  • Basically, they had the bright idea to inject stuff using variable names.

    var myController = function($scope, $http) {
    }
    

    So angular does myController.toString(), extracts names like "$scope" and inject appropriate objects as arguments. All very nice and elegant.

    That is, until you minify the sources and that function turns into this:

    var fn1=function(a,b) {}
    

    .... ups!

    So in any kind of production environment, you're forced to do crap like this:

    myModule.service('serviceName', ['$http', '$location', function($http, $location) {
    }])
    

    Terrible. Just terrible.

    More info:


Log in to reply