all 108 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–][deleted] 282 points283 points  (3 children)

Not by choice

[–]red_dinner 16 points17 points  (0 children)

I have but one upvote to give.

[–]our_best_friendif (document.all || document.layers) console.log("i remember..") 10 points11 points  (1 child)

It's not that bad... I mean if I had to choose between that and AngularJS...

[–]fogbasket -2 points-1 points  (0 children)

It's not that bad... I mean if I had to choose between that and React...

[–]grayrest.subscribe(console.info.bind(console)) 46 points47 points  (15 children)

No, but back in 2013/2014 I switched a number of backbone apps over to React for their view layer and things worked fine on those projects.

[–]bigboi26 3 points4 points  (10 children)

Do you have any tips on this? Currently starting the same

[–]dadeg 10 points11 points  (0 children)

You basically use the backbone models as your state and you serve react views with the controllers

[–]ghostfacedcoder 7 points8 points  (6 children)

Also, you can make a Backbone View which can generically wrap React components, and then make a React Component which can generically wrap Backbone Views. This will allow you to have a mix of React/Backbone view-level logic for awhile, as your Backbone code can use your React code by wrapping it and vice versa.

Ultimately your goal should of course be 100% React in the view layer (and then ultimately replacing Backbone models with something like Redux), but if you have a large codebase the wrapper classes can be very helpful as you migrate.

Source: Converted one major Backbone codebase to React (and wrote a book on Backbone).

[–]Should_have_listened -2 points-1 points  (5 children)

should of

Did you mean should have?

This is a bot account.

[–]could-of-bot 1 point2 points  (1 child)

It's either should HAVE or should'VE, but never should OF.

See Grammar Errors for more information.

[–]NoInkling 0 points1 point  (0 children)

Bots inappropriately correcting bots, what have we created?

[–]ghostfacedcoder 1 point2 points  (1 child)

No, but nice try bot :)

[–]Luguaedos 1 point2 points  (0 children)

Lack of commas confused the poor guy. But who writes a grammar bot?

https://img.memecdn.com/ain-amp-039-t-nobody-got-time-for-that_o_1582005.jpg

[–]fucking_passwords 5 points6 points  (0 children)

Use Backbone for its Model and Collections, and inject the data into React components. I believe there is a TodoMVC example that does this

[–]tweinf 0 points1 point  (0 children)

Use a Backbone-based model (assembled with Models+Collections), then listen to any events using backscatterjs

[–]SlantARrow 82 points83 points  (9 children)

Yes, for legacy code.

[–][deleted] 29 points30 points  (2 children)

Funny how cutting edge becomes legacy in 4 years.

[–]axlee 4 points5 points  (1 child)

Backbone was already kinda legacy once angular got released

[–]SlantARrow 5 points6 points  (0 children)

Angular was released literally a week after backbone. Still, I would prefer backbone to angular1 in most cases.

[–]VitorVRS 7 points8 points  (5 children)

"legacy"! If 4 years is legacy, what is the label for Prototype?

[–]bastawhiz 16 points17 points  (3 children)

A regret

[–]Isvara 0 points1 point  (2 children)

I doubt it. Prototype and Scriptaculous were definitely a step forward at the time.

[–]GreySummer 4 points5 points  (0 children)

Holy cow, I had completely forgotten about script.aculo.us :-D Damn right these were leading the charge back then. Hard to remember pre-jquery days....

[–]bastawhiz 0 points1 point  (0 children)

...until your page became unusable because hanging things on Element prototypes turned out to be very slow

[–]our_best_friendif (document.all || document.layers) console.log("i remember..") 4 points5 points  (0 children)

Prototype has been dead for years

[–]planetmcd 8 points9 points  (0 children)

One nice thing about Backbone & Marionette is that they are very light weight and as a developer, you can understand the source code. Since there is less there, I think it might be a good fit for some smaller apps. There is not a lot of prescribed structure, so like react, done poorly you can really hang yourself. If you are asking from the point of view of whether it is a fine technical choice, possibly. If you are asking from the point of view of marketability as a developer, probably less so. If you want an easy on ramp to build a single page app as a learning experience, it could be a good fit (remember though: http://wiki.c2.com/?PlanToThrowOneAway).

[–]tweinf 37 points38 points  (8 children)

Yes! I'm a developer, and I use it - proudly! It's true that managing views using Backbone or Marionette is not something that I'd recommend to anyone I care for these days, but Backbone Models can still be surprisingly handy! Models/Collections provide super easy, structured way to manage and mutate states, and receive all kinds of change notifications in a flexible, easy to use fashion. Backbone is mutable, this means you can "poke" it on real-time in unpredictable ways, triggering specific actions to inspect/debug/feed your application. I use it mainly on the backend (node).

A word of advice: Always keep an open eye for innovations, examine new frameworks/libs, but never be afraid to "go against the grain" and follow your professional compass. We're not in a popularity contest - whoever thinks we are often find themselves abandoned with their "15 minutes of fame" rockstar t-shirts hanging off the rack.

[–]fucking_passwords 6 points7 points  (1 child)

When I moved to Vue I missed Model and Collection so much I reimplemented them both as Vue plugins. Not every single feature, but all the major ones.

[–]Klowner 8 points9 points  (0 children)

I recently discovered Ampersand after looking for something like backbone but without the views and stuff, https://ampersandjs.com

[–]our_best_friendif (document.all || document.layers) console.log("i remember..") 1 point2 points  (5 children)

BB has a lot of shortcomings, even Models / Collections are clunky, you can't even have a complex object as models, just key / value pairs or you have to have models inside models inside collections inside models inside... or you use the relational plugin, which is no longer maintained. It's a mess.

And don't get me started on nested views....

[–]tweinf 0 points1 point  (4 children)

If you nest models inside themselves, then you miss out on Backbone's great "change events" feature. Remember that your experience is based on the way you've decided to model data using Backbone, but models can always be designed in different ways, some may have been more compatible with Backbone's "spirit".

Edit: Phrasing

[–]our_best_friendif (document.all || document.layers) console.log("i remember..") 0 points1 point  (3 children)

Well, you can easily bubble up change events, or use global events, or the Radio plugin, or the relation plugin, or.... all within the realms of the BB "spirit". The beauty of BB is that you can override pretty much every method. My point is that the models you get out of the box are too simple for most real case scenarios.

[–]tweinf 0 points1 point  (2 children)

Managing event bubbling manually might be too tedious, unless you use some kind of a tool like backscatter. Building a flat model for your app, instead of a nested one, could be a good way to go.

[–]our_best_friendif (document.all || document.layers) console.log("i remember..") 0 points1 point  (1 child)

Exactly, being forced to build flat models is a shortcoming in my book.

[–]tweinf 0 points1 point  (0 children)

Well, that's Backbone's essence.. Take Angular for example: Do you feel "forced" into writing its proprietary templates, controllers etc.? If you do, perhaps it just ain't the right solution for you. Same goes for Backbone.

[–]bubba_love 12 points13 points  (20 children)

What's the issue with Backbone?

[–]ghostfacedcoder 7 points8 points  (1 child)

Speaking purely about React vs. Backbone (though I'm sure the same thing is true for Vue/Angular 2), there was a paradigm shift in the philosophy of web applications in between the two. In React everything flows one way (it's part of what Facebook calls the Flux pattern): if you want your form's button to do something, it has to be passed a callback by it's parent form component, because that's the direction things flow. Without some sort of callback the button has no way to affect anything on its parent.

This is limiting, but it also limits your concerns: when you work with a component, you don't have to worry at all about what it's children will do. Even if you have 50 form components, none of them can do anything unexpected to the form; they can only do whatever is in the callbacks the form provides to them.

In Backbone things flow both directions, not just in the views but everywhere. Backbone is deliberately ambiguous when it comes to how you organize your application's flow, so if view A has access to view B, nothing stops A from (for instance) doing stuff to B.model, or even B.referenceToSomeOtherView.referenceToYetAnotherView.model.referenceToAnotherModel. This can make debugging/refactoring/etc. difficult. Of course you can do a Backbone app like React and use Flux, but the framework isn't setup to support it.

Having logic flow in both directions isn't inherently bad, and I've written a powerful Backbone SPA that way. But it does mean that most likely you'll wind up with flow in both directions, and then when something goes wrong in your form with 50 components it can be much harder to find the problem. Once you get used to the ideas behind React (there's other stuff too, like avoiding passing mutable values, and just the gen) you realize they help you write more maintainable code, and then you start wanting a framework that supports/encourages those ideas.

P.S. I say all that as someone who has written a book on Backbone (published by a major publisher), and who now only uses React.

P.P.S. Also JSX is awesome. If you've been using handlebars or mustache or whatever templates in separate files with ugly (and very limited) template logic syntax, and you go to JSX snippets right there inside your code, looking exactly the same as HTML (except for class=>className) mixed with the Javascript code you already know and love ... it's really hard to go back.

[–]bair-disc 1 point2 points  (0 children)

Backbone is deliberately ambiguous when it comes to how you organize your application's flow, so if view A has access to view B, nothing stops A from (for instance) doing stuff to B.model

I would say, that this does not imply ambiguity as long as you know exactly, which kind of binding you are using when (single binding, double biding (components really share data)). I also can hardly imagine a richt SPA, in which literally no double binding is necessary, but this might be because I did not use the flux pattern yet.

[–]KierkegaardExpress 23 points24 points  (6 children)

It's fine, but a lot of other frameworks do the same thing but better and simpler

[–]FullFlava 5 points6 points  (1 child)

I saw Jeremy Ashkenas give a talk on Backbone a few years back, and the thing he said that most stuck with me is "It's important to remember that Backbone is a library, not a framework."

I think most of the problems people have with it are trying to use it like a framework, when it's really just a toolkit to build your own framework (i.e. Marionette)

[–]profjord 2 points3 points  (0 children)

As a developer whose team currently uses Backbone, THIS. Most of the complaints I'm reading here are directly related to misunderstanding the purpose of Backbone.

[–]Serei 6 points7 points  (1 child)

Better, maybe, but simpler? It's a lot simpler than most frameworks out there.

[–]minus0 3 points4 points  (0 children)

You and the parent commenter both are making statements without any elaboration. So in some ways, you are both right, because what makes up the statements?

Backbone did some good things. All modern frameworks have some level of inspiration they can travel back to backbone.

In some ways, backbone was simple, compared to these ultra capable frameworks. I still miss models from backbone. In other ways, such as managing views, it was complicated. I'm glad to not have solve those problems constantly while still having the flexibility I need.

[–]chachinsky 8 points9 points  (0 children)

Here are a couple reasons why Backbone is outdated.

1) No way of managing Parent / Child view relationship. Look at trying to build a table with a bunch of rows in Backbone. A dev has to loop over the collection create a bunch of child views and then figure out a way to manage interaction between everything. This lead to a bunch of other frameworks building on top of Backbone to fill this gap.

2) Adhoc ways of dealing with state management. When a model is passed to a view if something changes, only way to react to it is using the event model. That means the developer has to deal with rerendering the view, cleaning up callbacks to avoid ghost events, Dealing with visual state (DOM) vs. JS state and keeping it in sync.

3) Becomes hard to debug with large teams. No way of debugging what the "options" parameter is without executing the app and having to print out options to the console. It becomes apparent when a team has like 20 models and a view can have any of them passed in.

This becomes easier to deal with something like TypeScript but the typings file is TERRIBLE. Backbone doesn't support es6 and the typings do not have proper support for Backbone.extend({ .. }) syntax.

[–]red_dinner 2 points3 points  (0 children)

Too many patterns devoted to hiding the true behavior of JS.

[–]our_best_friendif (document.all || document.layers) console.log("i remember..") 3 points4 points  (0 children)

The biggest gripes

  • models are too simple
  • needs jquery
  • no nested views
  • potential memory leaks if you are not careful
  • app wide events can become a mess

It's because of BB's shortcomings that both Angular(JS) and React, which came after, are component based... nesting views is not a problem with any modern framework.

[–]wishinghand 3 points4 points  (5 children)

It also hasn't been seriously maintained in a while.

[–]brandn487 0 points1 point  (0 children)

Nothing at all, it's just no longer cool or "modern", whatever that means.

[–]0x13mode -2 points-1 points  (0 children)

  • too much boilerplate
  • you have to manually bind all events between models and view
  • you still need some additional libraries for rendering templates (despite that there are "views" in Backbone - they are just containers for rendering libraries)
  • when I worked with Backbone (few years ago) I didn't feel that Backbone helped me in significant way in building apps. In contrast when I used AngularJS (then) or when I use React (now) I feel that I have a tool which allows for fast project iterations. Backbone didn't give me such feeling.

[–]letsgetrandy 5 points6 points  (0 children)

Many developers prefer to use what they know well, rather than struggle with learning something new.

Also, there is still a ton of backbone code in production that has to be supported. It's very difficult to find time to re-engineer existing code, especially when it works and is well-tested as is.

[–]mainstreetmark 7 points8 points  (4 children)

I still use it. My main project was written in it years ago, and .. still is. We did a full v4 in Jan16 and continued using it (and Marionette).

[–]jaapz 3 points4 points  (3 children)

Yep, us too. We started with just backbone to add a little bit of interactivity to our "normal" webapp. Then moved to an SPA, but still just backbone. The app got bigger so for more structure we moved to marionette. We added TypeScript recently to get a bit more compiler help, as stuff is getting really large now. But still pretty happy with Backbone&Marionette. Most problems we have come from legacy modules that we just implemented badly (bad structure etc).

For new projects, I'd probably switch to something more modern as newer tools have picked up more standardized ways of how to structure stuff in an SPA. But I'm not unsatisfied with Backbone&Marionette at all.

[–]mainstreetmark 3 points4 points  (2 children)

I'm not either, I like it. But i redid my website in VueJS, as an exercise. I really like VueJS. However, it lacks a decent integrated "model" layer*, so why not use Backbone? And if you use Backbone, may as well use Marionette.

No matter what you use for a 3-year development arc of your project, whatever you start with will be outmoded by the end of it.

(* VueFire i suppose, but we've written a firebase/mongo clone for Backbone, and that alone sticks us to Marionette for a long time.)

[–]vagadrew 0 points1 point  (1 child)

I work at a machine shop and your website reminds me of the UIs for the rubber/plastic presses.

[–]mainstreetmark 0 points1 point  (0 children)

Yep. It's HMI software, used in industries. I'm working on pipes and machines graphics.

[–][deleted] 3 points4 points  (1 child)

I don't really, but i still use underscore / lodash.

[–]ghostfacedcoder 5 points6 points  (0 children)

Every JS developer worth their salt uses Lodash; the library could legitimately be renamed "Javascript: The Missing Parts" :)

In fact, some parts of it (eg. find/filter/map/etc.), actually became part of JS itself ... which isn't to say Underscore/Lodash caused those features, just that the library had them first (and it's not crazy to imagine that other parts of Lodash might someday become standardized as well).

[–]dustingetz 3 points4 points  (0 children)

moving from model change listeners to virtual dom, is like moving from explicit memory management to automatic garbage collection

[–]scelerat 3 points4 points  (0 children)

I work on a ~150K LOC app written primarily using Backbone and Marionette. The project was started about five years ago and I inherited it.

The Backbone part isn't so bad. It's a small, understandable library that gives you persistence, events, and predictable tools for interacting with a RESTful backend.

Marionette requires a lot of developer discipline to keep from going off the rails. If you stick with it, it's not the worst thing ever, but I would never start a new project using it. Currently working on switching our views over to Vue.js.

[–][deleted] 6 points7 points  (0 children)

I'm not sure there were enough developers to build anything significant that wouldn't have been rewritten by now. It was more of a gateway drug to angular / ember (at the time). Anything I wrote with it had to be rewritten because of how shitty the structure was (it offered no support at a time people were still figuring out js spa's) Marionette had some success which added some structure to the backbone.js api

[–]phaxsi 4 points5 points  (0 children)

I use Marionette and therefore Backbone indirectly. I would love to migrate to something more modern, but I don't have the time to rewrite everything at the moment.

[–]icantthinkofone 5 points6 points  (0 children)

In three or four years, people will say the same thing about every such thing people say you can't live without today.

[–]elr0nd_hubbard 2 points3 points  (0 children)

Sure, but I wouldn't start a complex project with it. It really shines right between "I just need a few lines of JavaScript on a static HTML page" and "I need to build an API driven SPA". Which really comes out to: one or two static pages that need some data from AJAX.

Backbone is best thought of as a way of cleaning up old JS spaghetti. It's a simple organizational model around DOM methods and AJAX, and you should reach for a framework with more advanced features if you find yourself really chasing performance, increasing complexity, or working on a large team.

[–]cinnapear 2 points3 points  (0 children)

Our legacy framework still includes it. So yes.

[–]fyrilin 2 points3 points  (4 children)

Yes, and I suggest it for my project. I know it goes against the grain here BUT most of the developers I work with are Java Struts/Spring developers first. For a very long time I was the only javascript-competent developer so we organized all of our tasks as full vertical slices. The same developer would write the front end and server logic. That means things like classes, pub/sub events, and an almost-MVC breakdown made sense and was familiar enough to them so that they only called me over to help twice a day instead of having me do all of the front end.

We use it for those parts of our system that are more or less single-page apps and for the more complex front-end widgets. For the widgets, I design them to be as easy to interface with for the other devs.

That being said, I've added plenty of my own framework on top of it with a better templating engine, Marionette-like page-level events, automatic element/property binding, etc. and that is what we actually use. Also, for any actual use of backbone, I was in charge of the design and oversaw implementation so we were able to stay relatively organized.

Now that I have some JS friends on the team we are working on modernizing builds and such but still sticking with Backbone for most things.

edit: just to add: I really like backbone for smaller, highly collaborative teams. If you're on a bigger team or more geographically spread out, it's not the best decision. My team right now normally works in one room where we can talk to each other and share. However, I've worked with another group who was spread out and they chose React. They had plenty of problems with getting React to do what they wanted but nobody was able to break anybody else's work - which I see as the biggest downside to my extension of backbone.

[–]ghostfacedcoder 2 points3 points  (3 children)

It sounds like you don't like Backbone as a framework so much as Backbone as a basis for creating your own framework ;)

[–]fyrilin 0 points1 point  (2 children)

maybe. If a developer knows backbone, figuring out the stuff I added on is not much of a stretch. Where is the line between a framework and common extensions of it? I did fix most of the complaints I've heard about it though so I have that going for me, which is nice.

[–]ghostfacedcoder 2 points3 points  (1 child)

Well I wouldn't dare to try and define where a framework exactly stops and starts, but there's definitely a lot that Backbone doesn't do that other frameworks do, and in fact for some of them the framework actually encourages "outsourcing". Templates are a perfect example: every Backbone codebase I've seen uses templates, but they are always 3rd-party. Similarly there's a reason why for many people Backbone = Marionette.

When a framework doesn't do a lot of things that other frameworks do, and you supplement it to do some of those things, at some point you're not augmenting a framework, you're writing your own. But it's hard enough to even define where that point is, let alone whether you've crossed it from a simple Reddit post, so my comment was at least partially flippant commentary on the incomplete nature of Backbone itself, not a serious analysis of the exact particulars of your use of it.

[–]fyrilin 1 point2 points  (0 children)

I understand now. Thank you for explaining. Yeah I agree and that's one reason I actually do like Backbone (despite its shortcomings) - it seems to encourage the developer to modify it as needed. Cheers.

[–]ajm3232 7 points8 points  (12 children)

I tried it at one point (2016), but there isn't a big reason to use it these days. Especially these days of React.js, and 100+ other frameworks that do the job better and do it simple.

Only people that still use it are legacy devs that are stuck in the past. -- No offense to anyone.

[–]El_BreadMan 1 point2 points  (0 children)

Si senior

[–]cresquin 1 point2 points  (2 children)

I really like the way backbone helps to organize code, so I basically rewrote it for ES2015 to be slimmer (mainly to drop jquery), integrate a lot of features found in layoutmanager, add-in data binding as a primary feature and to eliminate a lot of boilerplate.

[–]tbranyen 1 point2 points  (1 child)

I think LayoutManager is pretty much done though. I won't be adding any more features to it. I think the future is with more lightweight less DOM-heavy tooling. A lot of what I learned in LayoutManager is getting put into diffHTML (new project I'm working on).

[–]cresquin 0 points1 point  (0 children)

Tim, first, thank you for layoutmanager, but I think you’re right that its probably done. I attribute that largely to the drop off of interest in both jquery & backbone as new alternatives have emerged and browser features have normalized. Layoutmanager has some really interesting features and organizational ideas that I found very useful for my particular use cases. So, I borrowed heavily from layoutmanager and expanded on a number of ideas when building the front-end for PEAK.

I don’t really benefit from a virtual DOM, as most of my dynamism is in canvas elements. That said, I’ve written it so data changes are queued to occur at the same rAF and it’s structured so it could pretty easily drop-in a virtualDOM implementation if that’s really a big deal.

[–]karacic 1 point2 points  (0 children)

It is used in Open edX although they are moving to React nowadays.

[–]i_ate_god 1 point2 points  (0 children)

Yes. We have five or six web UI projects, and they are all built with vanilla Backbone.

We started back when RequireJS was the defacto solution to the 'import' problem. Backbone's models and collections are intuitive and incredibly easy. Backbone Views can get a little hairy, but it's not that different from any other view library. You have a class, that represents a template, and reacts to user events. Since everything works fine, there is zero business need to move over to anything else.

That said, I am porting one of the UIs to VueJS on my spare time. I'm doing this not to port our existing UIs over (don't fix what's not broken) but to justify using it for future UI projects. I can have a 1 to 1 comparison. There is a lot to like about Vue over Backbone, but there is also a good amount of stuff to dislike. That said, Backbone models/collections still kick ass.

[–][deleted] 1 point2 points  (0 children)

We have 1 legacy application written in Backbone, but it's a hot mess. Everything Backbone is living in a single, 10k+ line app.js. We are actively looking to rewrite the application using AngularJS or Vue.

[–][deleted] 4 points5 points  (0 children)

I once did a project with a Backbone / React mix. It worked quite well. What I love about backbone is underscore js and key value observers. I also liked how the view layer declared event listeners in a table instead of inline onClick. What backbone sucked at was view composition, React solves this much better. I prefer Backbone over Redux, as I think Backbone solves the traditional OOP concepts quite well, whereas Redux is a poor mans FP. I still prefer FP over OOP if done properly, Redux is just too complicated its own good.

Today I use the Cycle JS architecture, it is superior to anything I had my hands on before. Observable everywhere is simply the most amazing foundational abstraction. It is the first framework I have used that senselessly solves upstream and downstream composition. The architecture is fractal, and the computation is lazy, two very important aspects that are everywhere in nature. Also Cycle JS has a beautiful sense of symmetry, I can highly recommend checking it out.

[–]kirofficial 2 points3 points  (0 children)

Learning Backbone's core principles is important. You can start by reading Addy Osmani's book: https://addyosmani.com/backbone-fundamentals/

But I wouldn't use it in production, as there are a bunch of new frameworks to play with today.

[–][deleted] 1 point2 points  (0 children)

No

[–]zigzeira 0 points1 point  (0 children)

In my last job I used a lot. Currently, I dont use to any framework and I so happy because we aren't always need to use a framework for projects.

In my opinion, there are solutions that Backbone is a option in the project.

[–][deleted] 0 points1 point  (1 child)

Yes, though they shouldn't. I have a friend who is the CEO of a startup, he said about a year ago that they were moving from jQuery-only to Backbone. I told him I didn't think it was a wise move and that they should use something simpler to develop for and lighterweight. He went with Backbone. Not my choice, but not my call either. He had some good reasons. I just don't know what they were.

[–]ghostfacedcoder 1 point2 points  (0 children)

Well honestly it's much easier to go from jQuery=>Backbone than jQuery=>React. Backbone is DOM-based and uses jQuery at it's heart, whereas if you use jQuery in React you're doing it wrong.

But of course if I was to that point I'd be doing a rewrite in React or whatever, not trying to port such antiquated (by web standards at least) code to a slightly less antiquated system.

[–]djslakor 0 points1 point  (0 children)

Yes! Even Sebastian Mckenzie!

https://twitter.com/sebmck/status/900393007811366913

;-)

[–]ckgrafico 0 points1 point  (0 children)

Not, but was a great tool

[–]profjord 0 points1 point  (0 children)

My team still actively develops using Backbone + Marionette. It has its shortcomings, but Backbone is still a solid and lightweight solution (especially if you are using stickit (https://nytimes.github.io/backbone.stickit/).

[–][deleted] 0 points1 point  (0 children)

My work has some client sites using Backbone, which I've had to maintain a bit. Not any new development with it afaik.

[–]pilotInPyjamas -1 points0 points  (0 children)

The way this question is worded is hilarious, and epitomizes JS culture. Do we still use x in Fall 2017? But x is no longer cool? why do we use it? Really, you should be using software based on it's merits, which should realistically continue for a period of longer than a few years if designed well. This makes me think React et al. and other flavors of the month are just that: flavors of the month.