For us contractors, we have to answer to clients we had 2 years ago about why their app is in Backbone.
I mean, damn; we have to build software here and we aren't all Facebook. You might get warm and fuzzies from constantly starting over and feeling like you've chosen the right framework, but it's immature.
Oh, we got it right this time! React is a paradigm shift! We've quickly forgotten we were saying this with Angular bindings. Oh your model based stuff is crap, this has TWO WAY BINDING, it's a paradigm shift!
Now, I'm using Angular. I could recite the Backbone source code, we had a few small libraries and we built huge apps and they worked (and they were built with Grunt and it worked fine, but hey, move it all to Gulp! now! Paradigm shift!). In this case I was expecting it. I waited six months and Web Pack came along.
We're going to go ahead and build our app in Angular 1.x with TypeScript and Web Pack and test it with Jasmine.
This article is NOT correct. This hasn't been 'decided', there is no clear winner. You can't simply list the features of something as "amazing" and "where it's at". You are arguing finality here and you main data point is "coolness factor". It's not correct, it's not objective, and it isn't high quality, long term; well thought out software development practice.
And while certain fads do come and go, there are also larger shifts and it's pretty clear by now that React's declarative-reactive style is the direction the industry as a whole is going.
The aggregate community is always searching for better solutions, it just so happens that this aggregate community is now huge and that means lots of people thinking about the same problems, meaning we make faster progress.
Old things don't stop working, but new things can be made better! What's the harm? Why so angry?
- Code is fashion; for some (especially on HN) there is inherent value in using technologies that are bleeding-edge and in vogue. Additionally, the necessity to use things that are bleeding-edge and/or in vogue is amplified when you're on HN or similar communities, much in the same way that the quality of your raw denim is amplified when you're on a fashion forum or with a bunch of stylish people.
- Fashion fades; building something when it's in vogue in 2015 for the sole reason that its in vogue in 2015 feels a lot worse when its in 2016 and suddenly the underlying technologies are not so shiny.
I think it can be easy to muddle 'progress' in the sense of "how do we move web technologies forward?" and 'progress' in the sense of "how do we deliver value to clients and customers?" As someone who is fairly shy of the current fashion (namely the React + Redux stack, which I've had the pleasure of working with the past couple weeks and whoa is it cool!) -- I'm not entirely convinced that the value delivered by using these technologies always outweighs the risk that they'll be obviated in less than a years' time. And so, there is a risk inherent in rapid progress, if rapid progress necessitates (as it seems to) the abandonment of anything that isn't pushing forward.
Choosing your technologies is a value proposition: every choice has positives and negatives. It can be frustrating to realize in retrospect that the positives weren't that positive and that there were negatives you didn't even imagine.
You or anyone else posting hasn't identified this "industry", it appears to be "quickly built apps that have no lifespan". I mean no offense; but we're back to saying it should be used because people are using it.
I'm upset at exactly that; it's not like anyone replied with objective software development reasoning that justifies this constant shift of frameworks, or addresses the need for enterprise software to have a longer horizon for support and talent.
Well, I thought they were neat before at least.
I really like this comment; because it resonates with my Backbone experience. I kept reading these hit pieces by Angular fans as part of my daily info gathering; but I had code to write and a project to deliver.
But not writing those blog posts may have been an error on our part; we avoided the discussions and it leads to the cool kids changing the rules all day.
I can't force you or I to write these posts; but maybe we have to face that there is a cost to not contributing.
I've got no dog in the Angular fight, but I will point out a problem with the 'while others have been arguing I've been shipping' line: while it does optimise for productivity ('shipping'), it ignores correctness. Imagine someone writing, 'while others were fighting over crypto, I was shipping [ROT13-using code].'
My problem is that these arguments are important: e.g. we know that the halting problem is not generally computable, so a product which relies on computing it cannot be right. And oftentimes 'just shipping' ignores the lessons learnt by those with more experience than oneself: 'I've been shipping' can really mean 'I've been busy putting myself in a position to learn' and 'others writing blog posts' can really mean 'folks who've learnt the hard way trying to warn others.'
I definitely do worry sometimes that spending too much time getting things done takes away from time spent learning how to do things better. I hope that I've found a good balance between the two, but it's easy to get it wrong, and your point is an important one.
(Put another way: hype, even valid hype, can fall victim to an echo chamber.)
It does mean bleeding edge, most hyped, etc...
I use Backbone models in a React app because Backbone is still the best library for models. I haven't tried Redux because it doesn't solve any problem I know I have.
Plenty of people skipped Angular because they knew it wasn't going to be on top of the hill for very long in the evolution of the frontend ecosystem.
I don't think it would be productive to switch to something new even if that new thing was better.
Also, some people love this. It means they can show up at work and talk about how they learned React and it's better and they can do a pretty good job of using the hype train to stand out from their peers.
The only clear winner can be vanilla JS web components, especially custom elements. A temporary polyfill is fine, but we need to say no to the extra dependencies like React and Polymer that trap us in dependency hell and minimize re-useability.
Polymer is designed to _mazimize_ reusability and interoperability via standards. Polymer elements just elements and you use them via standard API - set properties, attributes, listen for events, add children. The only wrinkle is that Shadow DOM is a little slow to polyfill, so we're using a wrapper on the DOM API. This will eventually go away.
Polymer is also extremely small compared to other libraries, and has no external dependencies: 34k gzipped without polyfills and 42k with. This will get better as native Custom Elements arrive across browsers later this year.
My main point is that in the Web Components future, it will not matter so much what libraries are used to implement components, as long as they are standard elements on the outside. The guts can be Polymer, some future web-component supporting React, Angular, etc., or just plain JS.
It cannot work since some browsers have different support for different features. You think people stopped using Android 2.x or old iphones ? So you end up with polyfills and since polyfills become dependencies you end with abstractions akin to frameworks, even worse since you now need to maintain your own mess.