Which javascript MVP framework to use?
February 14, 2016 7:45 PM   Subscribe

I'm the main frontend dev at my somewhat small SaaS company. Most of the front end is written by me using html/css/js (jquery). And it works, and will probably continue working. I think though that I might want to drag us into this decade and start looking into using a modern MVP framework.

Problem is, I'm not sure which one. I took a code academy course for AngularJS, which looks interesting. But there is a 2.0 version coming out so I'm not sure if that's the best thing to jump into right now. There seems to be a number of other similar things out there (react, ember, etc).

I'd like to figure out which one I should push for. Back in 2008, I correctly choose jQuery over mooTools and Prototype, but now I'm not so sure I'll be as lucky. So I'm turning to the Green. Any suggesting, cautions or rave reviews? Bonus points for your favorite learning resource for your suggestion (or general MVP/testing concepts).
posted by pyro979 to Computers & Internet (18 answers total) 9 users marked this as a favorite
 
I haven't decided, but the article linked here and discussed talks well of the differences and what reasons you might want to choose for.

https://news.ycombinator.com/item?id=10836236
posted by nickggully at 8:12 PM on February 14, 2016


anecdata...

I switched my teams/stack to AngularJs from jQuery last year, even though I know a newer version with breaking changes is arriving soon. The productivity surge has been measurable. AngularJs + Bootstrap + KendoUI + homegrown REST endpoints is working out for us. Chutzpah + Jasmine for client-side unit test.

I know I'm in for some legacy maintenance issues, but at least the team is fluent in the AngularJs paradigm and energized to adopt the new version.
posted by j_curiouser at 8:12 PM on February 14, 2016 [1 favorite]


I work for a company that just rebuilt the frontend of its .NET web app with react/flux. Asking the lead dev for a talk about how it went, I said I'd like an answer to the question "if you did it again, what would you do differently?" He said nothing different, that they were successful and very happy with the outcome.

My experience is with Backbone on one hand, and Meteor on the other. Backbone is minimal scaffolding to set the basic MVC pattern and nothing else, and still a viable choice if what you want is something lightweight. I would avoid Angular until it's settled post-2.0, just as I'll avoid new projects in Meteor until their transition to react/graphQL is settled as well. If you want a richer stack, react/flux (or redux or one of a hundred alternatives) looks like a very serious option--in part because Facebook is behind it, in part because React seems to have the same heat that Angular did when it was fighting it out with Backbone and Ember, only there's nothing else competing with React. All the JS community energy right now seems to be around the toolchain leading up to React/Flux and the flavour of Flux you choose.
posted by fatbird at 8:24 PM on February 14, 2016 [1 favorite]


I really like React if you want to do something a little more lightweight and not go full-on front-end framework. You can modularize components and get a really nice front end experience without having to abstract the entire presentation layer away. You can just keep whatever templating you are currently using and plug in the components as needed. It's a good way to move slowly into a more user-friendly set of interfaces. You can probably continue using whatever integration tests you have as long as you use a driver like Selenium or Poltergeist. I've also heard that Backbone is lovely for similar reasons to React, although I haven't tried it myself at all.

Ember is pretty cool if you like Rails, but it's a full on framework and you could even use it full-stack with a NoSQL db. You can also just set up endpoints on your backend and use it as a front-end. It's the closest thing to Rails in the JS framework land that I have seen. That said, I find some of its paradigms a little frustrating and it seems like it's not yet stable despite a few years of releases. I wouldn't like the idea of using it for the front-end of a relatively small application; the bloat would be irritating and work would be routinely duplicated. There's very good native unit and integration testing in Ember.
posted by araisingirl at 8:30 PM on February 14, 2016


If you're already using custom jQuery, Backbone is likely a good fit, since it's basically MVx scaffolding around jQuery and a template library of your choice. It's especially a good fit if your backend is pretty RESTful and your endpoints more or less correspond with a frontend view.

Caveats though: It's older and therefore no longer sexy; if your data model isn't terribly RESTful then you're in for a fair amount of pain twisting it to Backbone's model (this is the pickle we're currently in at my day-job); there is no real two-way data binding so you have to handle this yourself.

I haven't used it much, but React seems to be very nice if your views are nested with a lot of state, since you don't have to worry so much about which view will clobber what other sub-view when you render.
posted by neckro23 at 8:59 PM on February 14, 2016


For whatever it's worth, my company is going all in on React.

... our most recent project is built on Ember. Overall, it's turned into a pretty good framework -- especially since they started providing a CLI version -- but I dunno if I'd recommend it. It's hard to say why, except that the learning curve was kind of high and our ability to keep up with version changes has been something of an issue. Basically, if you like doing stuff the way they intend, it's pretty solid, but it gets ugly if you deviate from their chosen path.
posted by ph00dz at 9:42 PM on February 14, 2016


If you want a quick and dirty MV* library to add to your toolkit, I've found Knockout.js (which uses the MVVM model) is small, works pretty well, and is more likely to play nicely with existing code than a lot of frameworks. I don't have as much experience as I'd like with other JS MV* libraries, but I think React is what I'd be most interested in for new development. I don't think I'd look outside of React or Angular at the moment, as those seem to be the options people are gravitating to.
posted by Aleyn at 9:54 PM on February 14, 2016


What does your frontend need to do? Is it just an interface for signing up for your service? Is most of the actual usage handled via an API? I'd be hesitant to do a rewrite just because I am always, always hesitant to suggest a rewrite. If your frontend works with HTML/CSS/vanilla JS and a smattering of jQuery, don't rewrite it just to be on trend (unless you just want to pad your resume, which is a totally legitimate case in my book, and in which case sure, it totally needs to be rewritten, go for it).

At the consultancy where I work, we mostly use Angular for our front-end (but we aren't really wedded to anything, it was just convenient and it fits most of our use-cases). React with Redux/Flux is, I think obviously, the most trendy option. I've worked with both. They're...fine, mostly? Also Knockout is great. I'm not in love with any of them. They do a job, they occasionally irritate me. Really dig into why you're rewriting your app. There's no inherent value in fixing something that isn't broken.

Oh, and Egghead.io is my go-to when I've been learning these frameworks. I pay for a subscription, you don't have to, but it's been money well spent for me.
posted by protocoach at 10:15 PM on February 14, 2016 [4 favorites]


I agree that you need to define your goals/needs here before you can make a smart decision. But I will say that it doesn't make a lot of sense to start using Backbone in 2016. I used Backbone.Marionette for a year+ at my last job, then we started a new project with React/redux. This is a very popular stack in the JS world right now, and for good reason IMO. When I moved to SF last year and interviewed at a bunch of startups, I heard the same story at most of them -- they had originally built their web app in Backbone or Angular, and were now transitioning to React.
posted by ludwig_van at 10:18 PM on February 14, 2016


ph00dz makes a good point: a lot of how well a framework works depends on how much Koolaid you're willing to drink, and it might be a good idea to sit down and think beforehand how much you like doing things your own way vs. how much you're willing to do what the authors want you to do. Angular, Ember, and Meteor are "opinionated" frameworks, meaning they make strong choices and offer you a framework sized shortcut to making the same choices. Backbone and React/Flux are relatively unopinionated helpers except for the basics they settle on--they're less constraining but also less help.

It's probably worth doing a couple prototypes with your shortlist to get a feel for how it'll work. Meteor has left a bit of a bad taste in my mouth largely because its opinions don't much agree with me, so coding in it feels like wrestling. If Angular feels right to you, don't worry about the upcoming transition. Regardless of what you choose, this is JavaScript: your framework will be an unfashionable senior citizen long before you hit your release date :)
posted by fatbird at 10:22 PM on February 14, 2016 [2 favorites]


Response by poster: To answer a recurring theme - our frontend is fairly heavy. We're B2B in the HR space. I'm sure I could keep using what I'm using now for some time, but some of the reasons I'd like a rewrite are:

* I need something that makes it easier to write MVC. Mostly because I'd like to learn how to do it the right way, as opposed to the presentation and behavior mishmash I write now.
* I wanna set up some automated testing
* Two-way data binding (kinda sick of reinventing the wheel each time)

So to recap, I'm not necessarily trying to chase the "hot" new trends, just upgrade my technology to something that's solid and will improve the development experience and code maintenance.
posted by pyro979 at 5:08 AM on February 15, 2016


Two way data binding was one of the main attractions of Ember, but in the end, I'm not convinced it's all that important. I mean, how often do you really update the model from the interface directly anyway? I'm sure there are some apps like that, but for the most part, we discovered that one way binding is a lot less problematic.

I guess, the question is - do you want to rewrite the entire app all at once, or do you want to transition over to something new?
posted by ph00dz at 7:44 AM on February 15, 2016


Two-way data binding's pitfalls are why Flux got invented--and there are pitfalls. Given what you've said, I'd look more closely at React/Flux. React definitely brings magic to the table, but it's also pretty flexible about how you organize things in the end, so probably more easily mapped to what you have now. More importantly, Flux is a very strong pattern governing data flow that came along after two-way binding's problems began to surface, so there's a lot of real-world lessons in their. Start with Redux, a simpler variant of Flux.

I'd read through the Backbone docs (they're short) because they're actually a pretty good description of classic frontend MVC, so you'll get an idea of what's the textbook approach.

If you wanted an opinionated framework, I have a colleague who swears by Angular, even with upcoming transition difficulties--and one benefit of Angular at this point is a ton of Stack Overflow answers showing how it works in the real world.
posted by fatbird at 8:17 AM on February 15, 2016


I'm partial to React myself, but with the giant disclaimer that I don't use it via Javascript, but rather via Reagent.

So yeah, I'm a one-way binding fan and a worshiper at the altar of immutability.

That said, if you're looking for something a little more traditional in its Javascript orientation you might also want to look at Mithril. It takes a bit of an unconventional approach in terms of what its minimalism brings, but it does offer quite a bit of flexibility and is easy to integrate with legacy code. A word of warning though: make *SURE* you understand the concepts of data flow within a mithril application, what does and does not trigger component (re)initialization, and how the diffing works. If you don't, you'll have some very, very tough to find bugs later on. (Not that other frameworks don't have this issue -- they do -- just that Mithril doesn't have a lot of "guard rails" to prevent you from introducing subtle bugs if you don't get the core concepts.)

So my recommendation would be this: if you're willing to dig in and try to master a framework, React is a good long-term choice. If you're looking for something lighter that you can get up and running the "right way" without having to spend a month "drinking the kool-aid", Mithril will be a better choice, provided you read and understand the documentation. [1]

Disclaimer: I'm also incredibly biased against two-way data binding, so I can't offer a reasonable review of any framework which embraces it.

---

[1] I don't mean this in a condescending way! I got burned big time when I first used it because I made assumptions about how component instantiation worked and never bothered to check the docs to make sure I was right. This caused me to waste a ton of time later trying to debug state retention issues.
posted by -1 at 9:16 AM on February 15, 2016 [1 favorite]


Response by poster: The app is large, but is fairly modular. I'd likely start with the less used, less critical components to cut my teeth on as far a re-write. I have no illusions that a full re-write would take a long time, which is OK (I won't scare you by telling you which IE version we still have to support). I just want to start the process of the re-write the way I did back when we were still using frames (not iframes, frames). Plus, I think if I do that I can make the whole thing responsive/mobile friendly while I'm at it.

So it sounds like I need to choose between React/Flux vs Angular. Which to me, and correct me if I'm wrong, comes down to "more freedom/less guidance" vs "less freedom/more guidance"? I'm sure it's more nuanced then that.

Any input about testing? Or are they more or less equivalent? I'm sure I'll be asking more questions about the tools and testing and all that once I pick a framework.
posted by pyro979 at 12:16 PM on February 15, 2016


On the major backbone site I work on, it's not full single-page-application, it's a hybrid. We have a requirejs/grunt-driven build process, and backbone-defined MVC going on for all pages, but there's still discrete pages. Some have SPA-ness to them, where we render different views and have lovely reactive interaction, or endless lists, etc. But mostly require and backbone are organizers and builders for a common approach. This has worked really well for us in terms of site stability because we avoid a bunch of SPA issues like memory leaks over time, while still getting REST API separation between front and back end, and whizbang JS zippiness in the browser.

If you take the same approach (and I generally like incremental replacement approaches), you actually have an opportunity to replace a couple pages with react/flux and a couple others with angular, and see which one feels better and looks more scaleable. I'd strongly consider that prototyping approach because the whole JS world these days has the attention span of crack-addled squirrels, and we really don't have a sense of how these frameworks hold up over the long haul--except that backbone has stabilized into a mature framework that's too minimal to consider anymore, while Angular and Meteor both have major breaking changes coming.

By comparison, a significant part of my day job is working on large Django site that's seven years old now, and the code and site are in pretty good shape even after all that time and ongoing development, which speaks pretty well of Django. The only part of the Javascript world with that kind of longevity is jQuery itself.
posted by fatbird at 12:30 PM on February 15, 2016


I started my comment to answer your question, and then got so caught up that I didn't.

Your gloss on react/flux vs. angular is pretty good, FWIW. "Freedom" is very context-defined, and really is about the difficulty doing things that aren't what you're supposed to be doing. Angular has a lot of "here's what you should do", and you don't have to do it that way, but working at cross-purposes with your tool will punish you. React/Flux (or Backbone) has fewer "here's what you should do"s, so you've got more flexibility.
posted by fatbird at 12:36 PM on February 15, 2016 [1 favorite]


+1 for Ember
posted by flippant at 10:21 PM on February 16, 2016


« Older Big problems (temperature differences) with new...   |   Return to Kanto Newer »
This thread is closed to new comments.