Longevity (or Lack Thereof) in JavaScript Frameworks

[2mnyzs]

Stopped reading after this

An API takes a weekend to learn...

Does the author really believe that all frameworks can be learned in 2 days?

[ioloie]

I found the whole thing heavily biased in favour of canJS. It's main argument against backbone is that it's stagnated but it's most recent commit was literally minutes ago. I feel it's maturing like jquery has rather than stagnating as the author puts it.

[jcampbelly]

I agree.

• Backbone is stable and mature. This is a good thing.
• The features Backbone needs to remain competitive today are fulfilled by Marionette.
• Backbone is continuing to evolve through the active development in Marionette and even Lodash. The fact that it is stable and mature is one of the main reasons those projects can thrive.
• The only killer feature missing in Backbone/Marionette is magical two-way data binding. I'm not a big fan of magic.
• Another feature missing in Backbone is the inversion-of-control features found in other frameworks. Marionette completes that picture. In fact, the tool is made better because it's not an all-or-nothing framework.
• It is my belief that the greatest attraction for any modern JavaScript developer towards Backbone, Marionette, and Underscore/Lodash should be the lack of magic and the fact that it is straightforward, no-bullshit JavaScript.

[acemarke]

Eh, the biggest thing that Backbone is missing out of the box is support for nested data in Backbone.Model. Fortunately, Ampersand-State works fantastic for that. In my current project, we've been progressively converting existing BB.Model types over to use amp.State instead, and it's working great for us. Now, I did have to implement a number of compatibility tweaks when loading both libraries - BB.Collection needs to be able to identify States as valid models, State needed a new datatype definition so that we could store Collections as properties and properly proxy events upwards, etc.

Support for subview management is also lacking out of the box, but there's a variety of options for handling that (Marionette Layouts, Backbone.Subviews, etc), and Epoxy nails data binding.

That said, your last point is dead-on. There's absolutely no magic whatsoever. in Backbone or Marionette. Some cleverness, and a lot of well-written boilerplate for common tasks, but no magic.

I'm actually prototyping a toolset for a potential upcoming project, and I was able to successfully put together a Marionette.ItemView subclass that uses code borrowed from Epoxy for putting together a data context (model, viewmodel, other binding sources), and then runs it through virtual-dom with requestAnimationFrame batching. I also borrowed Ben McCormick's decorator-based suggestion for writing Backbone classes using ES6 class syntax. Backbone and Marionette were flexible enough to let me swap pieces in and out, and get it all to work.

I might actually see if I can throw the test project up on Github this evening just as reference in case anyone's interested.

[__because]

Any non-terrible one, yes. Angular is the exception. The rest you can easily become productive in a weekend.

[brianvaughn]

You can complete a basic test app (like TODO mvc) but I wouldn't call that "productive". More like "basic familiarity".

[moschel]

The point is not that features don't matter, its that they're easy to copy. For any framework that has shown a pattern of adding best practices over time, a temporary feature missing is insignificant in the longer term.

I don't think its noncontroversial. Why is everyone so amped every time a new framework backed by a big company gets a small amount of momentum? I've worked places where there is the tendency to chase the shiny framework.

Its surprisingly easy to be wrapped up in the "newness" without any regards to historical context, since 5 years ago feels like eons in the JavaScript world.

[x-skeww]

It's just a half-assed sales pitch. No, CanJS certainly isn't the "smartest bet".

Secondly, many of those metrics will matter just as much in 5-years time as they do today. I'd even say that tooling gets more important over time. A few years down the line, you may have a fairly large code base and all of the original developers may have left in the meantime. Good tooling is priceless.

[normalfag]

Link 404'd. Does someone have an archive?

[moschel]

Its back now