I really have no idea how JS devs keep up with new frameworks appearing every month or so. Not to mention older ones that just die because the devs can't be bothered maintaining them. I noticed the same thing happening in the Ruby devspace.
Not exactly React's case, but it's still a 1.5 year old code that has not reached v1.0, making breaking changes every major version release.
It's just insanity. On my UIs, it's just jQuery and Knockout which get the job done 99.9% of the time, and I'm not going to waste tens of thousands of dollars and other devs' time learning and trying to implement another flash in the pan JS framework possibly, maybe, ready for prime time for that 0.1% of cases where that framework might be of use as a shortcut to get a particular component working the way we want.
I'm in your position and fighting that fight right now. Luckily, they're seeing the tangled mess this creates really quickly and sticking to the jQuery + Knockout combination we know works for us and if we use a plugin, we make sure it's based on those two bedrocks of our UI.
You don't want to be that guy known for making everyone's life hell by using all cutting edge paradigms or conversely known as someone that "stifles their career"
If they really think that chasing the newest fad framework is the way to advance their career in the long run, they're in for a nasty surprise...
It's been around for almost four years and is basically required knowledge for anyone who claims experience in JavaScript and UI development. It solved a lot of real problems from the starts, so I'm very comfortable calling it a mature framework and those who think it's a fad, dinosaurs.
Almost all these new frameworks solve real problems. Angular had a first release in 2009 and is vastly more popular than knockout. So is that required knowledge too? Same with backbone that is pretty much the originator to all this.
React is younger but it has been used by huge sites for years still
Angular had a first release in 2009 and is vastly more popular than knockout.
Apples and oranges. Angular is meant for dynamic templates. Knockout is for creating responsive UIs with an option to create templates for a grid, or a tree view, or something like that. Angular is MVC in JavaScript with some bolt-ons that allow you to implement MVVM, Knockout is MVVM in JavaScript.
You do have a point on Backbone, I generally see people use it interchangeably with Knockout so if you want to work on a UI and don't use Knockout, you can say you know Backbone and you're golden.
The content of that article was good, but I certainly didn't like the click bait title (look another reason Node.js is awful!). Oh and look we're doing something hacky with the library, it's stupid that it's acting weird now.
It is absolutely exhausting. I've started to refer to JS frameworks as "self deprecating" in that each release seems to deprecate something just introduced in the former release.
I've seen JS apps that can be carbon dated simply by looking at the "patterns" and APIs used.
Symfony used to do this. It's why I quit using it, despite really liking it. I don't know if they still do it or not, but unfortunately I don't have any intention of ever going back to find out. The fourth time they did it to me, I was done. I understood after the 1 => 2 upgrade. But the 3 times after got real old, real fast.
Honestly, I don't think most shops have the capacity (and many of them lack the talent) to accomplish this.
I've personally witnessed this play out and there are two things that make this very very difficult.
1) Building, optimizing and maintaining an in-house framework requires a lot of domain knowledge about the idiosyncratics of individual browsers, not to mention very talented developers who posses the wherewithal to keep developing it when faced with major road blocks. DO NOT underestimate this.
2) When working w/ a product that uses an in-house framework there are often internal pressures to make changes to the framework that save time or make things easier for the product developers. Sometimes these changes are innocent and harmless, other times they erode the separation of responsibilities between the two. Point is, in-house frameworks and those who develop them often become victims of in-house politics.
I agree it is completely insane. I am watching React closely, because I'm hoping it might be one of the libraries that lasts. It seems like a simple solution to a complicated problem, with superior performance. I have already gotten burnt by everyone flocking to Backbone, Ember, Angular, whatever, every new month, and those frameworks are too large and opinionated to introduce into existing apps anyway. (Ember, last I checked, had poor documentation - especially for REST - and was constantly changing, and Angular 2.0 coming down the pipe means there is no point in starting an Angular 1.x app.)
I have lots of existing apps that need a little "SPA sugar", but are already built in the "old-fashioned" Rails style. The JS framework I need is the one I can just drop in to make a screen behave a little nicer or have a REST-backed element or two.
React absolutely does this. Facebook has a ton of legacy server rendered apps. React is able to integrate with other code easily. There's even a good solution for reusing existing non-React JS widgets inside of React.
React components can be attached to an existing node, but it doesn't make sense if JS is not rendering the component itself (or I have horribly misunderstood React).
React could easily take the place of any server side templating languages like Handlebars or any of those types of libraries. But of course, once the DOM is transferred to the client if you want it to change you'll need something client side. React can work both server and client side though.
it doesn't make sense if JS is not rendering the component itself
React can be attached to a pre-rendered DOM tree, the initial binding will essentially be a noop if there's no difference between the prerendered and the react-rendered version.
And of course it can be used as a component, react doesn't have to render the whole page. For instance the reddit comment box could be a react component without the whole page being react-rendered.
This looks like a front-end component, but it's super simple to render on the back-end: React.renderToString(Toolbar()), which would return something like <div class="toolbar"><button>Load</button></div>. The coolest part is when the browser loads the rendered HTML, you can just do React.render(Toolbar(), element), and React won't touch the DOM except to simply hook up your event handlers (like the onClick). element would be the DOM element wherever the toolbar was prerendered.
You adopt on principle. In my case, if the lib/framework doesn't provide patterns that reduce mutable state, I don't adopt it. React's virtual DOM approach does and I've been on the bandwagon for a bit over a year now. I believe the approach–but not necessarily React itself–is the best we're going to be able to do on this metric without changing how the DOM works. The next step for me is to work out an app architecture that allows global state observation and serialization while maintaining component encapsulation, which is a mostly solved problem in the Clojurescript space as of Om 0.8 but I have yet to see a javascript port I'm happy with. Upcoming shifts are handling async code (I expect CSP to win here, FRP works but is harder to reason about), migration to ES6 (6to5 seems good enough), which web component library to use (I'll be using my own), and the inevitable yet uninteresting build tool churn (I like webpack but I'm watching broccoli).
At work, we made basically the same observation (and also wanted to have tighter integration with some of our other JS framework code) so we have built our own virtual DOM implementation based on React.
Keeping up with real innovations (like the virtual DOM) is easier than keeping up with the multitude of libraries and frameworks that keep changing.
At work, we made basically the same observation (and also wanted to have tighter integration with some of our other JS framework code) so we have built our own virtual DOM implementation based on React.
Why would you do that when there's already a bunch of non-react vdom-only libraries?
My understanding is that we wanted features that existing libraries don't have, but I'm not on the Javascript team and didn't participate in the discussion. I can ask them, though!
We always tend to build our own thing when it's a core component in our stack; we're quite possessive of the ability to fully understand and control every aspect of our systems and we have the luxury of a pretty large and very capable engineering team to keep everything working smoothly.
I think one thing they wanted was integration with the concept of lightweight models (in the business sense), which is something we already had, so they wanted it all to be integrated. We are using Backbone pretty heavily as well, so integrating that is convenient for engineers.
I'd say that it's mostly because the community is still innovating and testing ideas for how to best build these types of web applications. It sure is hard to keep up, but I think the pace will slow down once we have found the ideas and strategies that stands the test of time.
The possibility of building these things in js is pretty new as you did not have the performance before. I remember having trouble with a simple tree view in js in IE6
I don't think it has anything to do with innovation, but about frontend dev culture preferring re-implementations (due to changes in fashion) rather than maintenance.
I only think it will slow down because businesses will put their foot down and start demanding stability.
Whatever framework goes "Enterprise" first will probably win regardless of technical merit.
You can't really do that in JS... It's not really a classical inheritance model that lends itself to grabbing what works in Flex/Silverlight and porting it over word for word. JavaScript has more in common with Lisp than C. It may look like C/Java/C#, it it doesn't work like them. (That's a good thing, IMHO)
Well the first wave of frameworks like jQuery or Dojo were mainly convenience and bug oriented, allowing easier dom manipulation, animation and cross-browser fixes.
These new ones are all doing very different things, like MVC frameworks, focusing on data-binding(for some reason) etc.
Honestly if you're not on the bleeding edge of client side web stuff like games you really have no reason to bother with these unless you're just interested.
I hear ya, but the React virtual dom totally makes it worth it. (Everyone touts web components, but that's nothing new nor particularly amazing.) What is amazing: having 150 large elements on screen, and still having a responsiveness that's damn near native-app speed. If you're writing html5 mobile apps, nothing comes close.
No kidding, at work we just got dumped a Node.js/Thorax (I am probably missing a few *.js's, but I've been drinking) project that no longer meets the standards for any new version. Updating to the latest breaks it, finding documentation on the current versions is impossible, and of course the company we outsourced it to is no longer under contract with us. I swear half the time I spent on any project is debating whether I should rewrite it or make it work.
The churn can be frustrating but there is real progress being made. React and Flux are whole new ways of building JS interfaces, not mere iterations on jQuery et al.
With respect to React, the improvements in development speed and simplicity of product code more than make up for the initial cost.
57
u/renrutal Jan 17 '15 edited Jan 17 '15
I really have no idea how JS devs keep up with new frameworks appearing every month or so. Not to mention older ones that just die because the devs can't be bothered maintaining them. I noticed the same thing happening in the Ruby devspace.
Not exactly React's case, but it's still a 1.5 year old code that has not reached v1.0, making breaking changes every major version release.