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.


  • SockDev

    @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?


  • SockDev

    @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.


Log in to reply
 

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