This is the reason why I still enjoy to write in C, there is simply no need to change your entire codebase because some dude came up with a new "miracle".
I do full-stack javascript for my income, but have reached the point of not enjoying coding anymore because of this continuous change of ideas forced upon me. Why do I need to change from React.createClass to ES6 classes, from ESxx to Typescript or Flow, from React to Vue, from callbacks to Promises, from Flux to Redux, or from any idea to the next hyped idea?
When will people start to realise that this new method or technology they're implementing is deprecated already?
There is no end to this and I actually hate it as it destroys my passion for coding. I code to create things, not to continuously change what's created already and works fine.
As soon as I find a cool C job I'll definitely leave this mad house.
> I do full-stack javascript for my income, but have reached the point of not enjoying coding anymore because of this continuous change of ideas forced upon me. Why do I need to change from React.createClass to ES6 classes, from ESxx to Typescript or Flow, from React to Vue, from callbacks to Promises, from Flux to Redux, or from any idea to the next hyped idea?
Who's forcing you to do this? All of these old things still work. If your team/job are forcing you to do this, then why is the problem not with them, rather than the language/ecosystem?
The old things likely have bugs. And most libraries don't spend a lot of time patching old versions (why should they, it's free software). The longer time passes the less and less likely there will be bug/security patches. So if you want to own those bugs/security issues, sure, stay behind to avoid the cost of upgrading.
There are "enterprise type" libraries for JavaScript developers that move slower & focus on stability over performance or productivity increases. Some are backed by a company that offers paid support. While I haven't used it, I've heard good things about Telerik.
"The old things likely have bugs" Do you even have experience with React? It sounds like you don't. Because there's no "bugs" with using createClass or proptypes, it's simply been split out into a separate package that you can still use if you want.
JavaScript is a young language. It's been around for 21 years.
C has been around for 45 years.
I'm sure things will be relatively stable 24 years from now in terms of web development, but then there will be a new medium for writing code with massive churn in commonly-used libraries and techniques.
A need to learn new things in a young language will never die.
Even C++, which is "only" 34 years old is experiencing massive changes to its syntax and common practices.
It's impressive how most of the progress in the JS land is essentially adding the features most of the other languages have already had for years (or - at least had done them properly in the first place).
And I do understand why - it's just quite pathetic to see all of that being done for no practical reason.
Sure, Haskell & OCaml have had a lot of these features for years, but they can hardly be called "most languages". Other languages are also in the progress of adding similar features (C++, for example) or aren't getting them (C).
Javascript has more library churn, but the alternative is being stuck on something like BOOST. ugh.
Let's be clear: JavaScript tries to be both a platform and a programming language.
People hate it because there's no practical reason why we're forced to use JavaScript in order to program - and most of the people who are productive are probably using some sort of variation on ECMAScript that makes it bearable anyway.
> Let's be clear: JavaScript tries to be both a platform and a programming language.
I'm not sure how you came to this conclusion. JavaScript is the common language for two major platforms (browsers, Node.js) and many smaller ones (Cocos2d, enyo JS, Espruino, GNOME Shell, Kinoma XS6, NativeScript, Weex, etc.).
- browsers: used since the 90s because there's no other alternative
- node.js: created because JS is used in browsers and it's easier to write code in a single language for browsers and servers
- Cocos2d: you're clearly lying as the only place where JS is mentioned is Cocos2d-html, as there's again - no alternative
- enyo JS: again, used clearly due to the fact that modern - browsers are available for all of the modern platforms
- Weex, NativeScript: typical "native app" libraries which use a webkit pane for most of the rendering, again - javascript here is circumstantial since you can't choose anything else
- GNOME Shell, Kinoma XS6: OK. These are the only ones that make any sort of a strong point in your message; but as far as it goes - modern linux distros are moving to Python for systems programming anyway. So learning JS here is a miss.
It's also incredibly frustrating that every step that is rediscovered that other languages just have is then subject to endless fragmentation over trivial differences that are put forward as core philosophical concerns. I know this is not unique to the JS ecosystem but it's definitely a lot worse than I've seen in the past.
Which past are you talking about? Before the last years progresses, to make your javascript working on multiple browser your only choice was to lock you learning huge frameworks and toolkits like jquery and dojo, or spend hours during your weekends to get a project working on multiple platforms.
Those times were painful, now it’s much much better.
I've been writing production JavaScript since 1999. Writing compatible JS used to be a horrible pain, now everything about writing and maintaining your JS is the pain and browsers by comparison are highly forgiving.
I'm talking more ecosystem than core language changes. Though of course, core language changes are part of the build and tooling ecosystem because of everyone constantly wanting to write code that is years ahead of what browsers are actually supporting. Build and package management tooling, frameworks etc.
On one hand, I absolutely agree. The amount of change that happens for the sake of nothing more than change is laughable theme in front-end development.
And if it's not for changes sake it becomes some weird squabble over how to best handle X, and we wind up with numerous ways to do so. At that point we have to take a bet as to which approach we think will be supported and pushed forward in the future (i.e. promises? generators? callbacks? async/await?). If we're right? Great. If we're wrong. Well, let's hope the libs we're using keep support for the way we've written our code.
On the other hand, it does finally seem like React has one the shake out of front-end frameworks. While it's ever changing, it does seem like it's longevity will be far greater than most front-end frameworks of the past. And it does solve a lot of the BS that one would deal with if they didn't have a framework to leverage.
But yeah.. The danger with front-end development is how fast the knowledge depreciates.
edit: by danger, I more mean difficulty of keeping up with.
"Why do I need to change from React.createClass to ES6 classes, from ESxx to Typescript or Flow, from React to Vue, from callbacks to Promises, from Flux to Redux, or from any idea to the next hyped idea?"
There are good reasons for those changes. As you are a full stack JS developer, I'd recommend you dig deeper and find out why. It might alleviate your frustration.
In my case, the main pain points were third-party packages, more than React 16 itself. For react you only had prop-types and createClass to change everywhere. The migration of react-router in particular was awful, the new react-router is so different from the old one they should have created another repository for the new version.
This has been my experience of react-router since its inception. When react-router does a major API version bump, they really mean it. I don't use it in any projects I have full control over, but unfortunately due to its popularity in larger projects I've had to use it.
Agreed! After being burned by React-Router, more than once, I actually would opt for manually implementing a Redux-et-all solution with something like History.js over using React-Router again. Which is pretty worrying considering how important routing is, or should be, in the ecosystem.
That's good to know. React Router is the only thing stopping me from updating to React 16. I can't find an NPM package, so assume you need to point it at Github?
That is true, but the new react-router makes better use of the component hierarchy which is the real beauty of React IMHO, by having the route components render conditionally based on the url.
We had a lot of pain doing this rewrite ourselves, but I must say it was worth it in the end.
Unfortunately, this is major version 4, so who is to say that the repo maintainers don't find an even better way to do it in six months, prompting a version 5 and so on...
The only things we're looking at for another major version are some changes to the default API behaviors (making `exact` default to true, for instance). There are potentially some changes to path matching, but that's being driven by path-to-regexp, not our own development.
Yes, 4.0 was a big change, but a necessary one. Now that we're in a great place, we plan on keeping things relatively stable indefinitely. Pencils down, as it were. Outside of some major upstream change with React itself, future versions will be more evolutionary than revolutionary.
Happy react router user here, at various major versions. Thanks for the great work!
> Yes, 4.0 was a big change, but a necessary one. Now that we're in a great place, we plan on keeping things relatively stable indefinitely.
Out of curiosity, was this also the thinking when 3.x was released?
Or when 3.x was released was there more of a philosophy that the problem space was still being explored, and major design changes were still possible and acceptable?
Sure, but whether or not 3.x changed significantly from 2.x isn't really what I'm asking about, I was more wondering if you imagined upon the release of 3 (or 2 for that matter) that it was more or less the final stable overall design, or were significant future redesigns/rewrites still in the plan at that point?
This seems like engineering for engineering's sake. From the author's description, this was a pretty superficial refactoring that may or may not have been for the better.
It seems like a bizarre decision to spend time migrating to a new system / tool that provides no immediate benefits. A thorough refactoring of their codebase seems like it would have been a better use of engineering time.
React 16 adds Portals and Error Boundaries, which are very useful things that often change the way you write components. When you defer upgrading something that changes the way you write code, you accrue debt because you're increasing the amount of code written in a style that will be deprecated once you upgrade.
If you're all-in on React (as Discord is), the upgrade to React 16 is inevitable. Given that, upgrading now makes sense.
The more you delay the upgrade, the more painful it becomes in the future.
At a previous workplace we had to go from React 0.13 to React 15. We had to re-write, fork and patch, or get rid of entire third-party libraries. There are no stepping stones in the JS ecosystem that let you do gradual updates if you are several versions behind.
It's very easy to upgrade React incrementally. The only problem is that it's likely not so easy to upgrade your related dependencies incrementally. Especially if they use internal APIs or aren't regularly updated.
There are in the Ember community. They do such a fantastic job of transitioning between versions.
I have had my complaints in the past when I don't touch an Ember app for a year, but for the most part, they provide ample "stepping stones" to bring the community along without too much anxiety.
I'm afraid with all due respect to the author, I have to concur.
"Right now, it isn’t clear that the advantages are significant" - so why invest the time in doing so? Why not use a tried and tested version until such times as you either need features from the newer version or some third party dependencies you absolutely need require it?
I've migrated two applications from React 15 to 16 and it was completely painless. I only had to bump all dependencies to the latest version.
Literally the only reason a migration could be painful if you're on the latest version of 15 before upgrading is that your code or your dependencies are using deprecated APIs, which the latest version of React 15 will helpfully warn about. You can fix that before migrating.
To be fair, mutating props was frowned upon pretty early on. Also, emphasis on upgrading to the latest version of React 15 before upgrading to React 16.
React has pretty thorough deprecation warnings on the final releases of each major version about what is going away with the next major. Once you've gotten rid of all deprecation warnings, migrating to the next major should be uneventful.
This means you can take your sweet time when upgrading, migrating your code without breaking your entire application.
You say that, but their engineering team has been consistently producing one of the better performing electron apps I know. I've seen a lot of praise on HN about their product, so I think they must be doing something right.
To me, it describes more the attitude some people have torward new technologies developed by new people, by criticizing without knowing enough the things they criticize.
"Facebook has done a good job of deprecating and warning for the last few months, but not all libraries are well-maintained and if you depend on or have forked a great many ancient ones, you will be in for a bit of a slog.").
This is one of reasons to limit third party libraries you use along with React. Every dependency comes at cost. If you use React and React-Foo, React-Bar, React-Baz and dozen of other React based additional libraries, then upgrading all/troubleshooting can be painful. As it was ("We ran into an error which took us 2 days to track down to a library, ...")
Agree 100%. I always use zero-dependency libraries if they are available. The only library in my codebase that has a React dependency is react-redux. React upgrades have thus far been painless.
This is why I prefer web components. This is nothing against React. But it's a library, and they make breaking changes just like all libraries (eventually) do.
The great thing about web components is that they cannot make breaking changes now that it's been implemented by multiple libraries. It's stamped in time forever.
If there ever comes a time where the existing API can't be updated any more because of mistakes or whatever, they'll just make a new API and your existing code will continue to work, forever. Look at XMLHttpRequest and fetch(). Did you have to migrating your XHR code over to fetch()? No, it works fine, and always will.
When the Polyfills are gone (mostly), I'll come back to web components. I love the idea of web components, but the browsers are still pretty fragmented in terms of support.
There's definitely progress, but an older Polymer 1.0 app of mine is painfully slow on everything but Chrome.
Hm, DBmon benchmarks show that Polymer 1.x with polyfills is a lot faster than Angular 1.x which has thousands of production sites and was acceptable not that long ago. So I'm not sure that non-polyfill execution will really fix the performance for you.
Maybe chrome is better at rendering your application structure?
I can speak to _significant_ performance improvements when upgrading to React 16. Like night and day performance with minimal code tweaking. (Basically add prop-types package and remove any references to React.proptypes)
The author hints that there probably aren’t significant performance improvements yet, but I’ve seen a spattering of tweets claiming to see fairly significantly real-world performance boosts.
That benchmark needs more context because were I to guess i'd say they're using stream rendering[0][1] in React 16
I also agree with one of the comments in reply who linked to "How to win in web framework benchmarks"[2]
Unlike, say, benchmarks for performing hash functions on graphics cards or frame rates on certain hardware the units of work being tested on web benchmarks very rarely reflect the units of work used in your own systems
In performance and security critical components we write benchmark-*.{ts,js} tests and track performance of real-world components.
At the moment in the mocha world there is no good way to keep a history of results, so we tend to copy+paste them as code comments (noticed this in a lot of projects) - but it wouldn't be difficult to write a storage backend here in sqlite or similar and store it in the same way coverage reports are
If you're doing comparisons on modules you use - you can include them as devDependancies. This also forces you to abstract away your dependancies which is often a good thing.
Indeed, it’s not easy to come up with a repeatable benchmark from which broad meaningful conclusions can be made. But if a real-world React application gets faster when upgrading, I’m all for sharing that, and it can be a useful estimate if that application is somewhat similar to my own codebase.
How does the performance of React 16 compare to Preact? I understand that Preact is still a smaller filesize, but fibers (and async when it’s enabled) sounds like it’ll be faster than Preact.
We are using Preact for a small mobile site, so I’m wondering if it’s worth switching.
IIRC, preact is faster by the virtue of being smaller so it's loads faster, but React is actually more efficient when updating the state, in some ways.
The "Fiber" stuff is FUD until we see some perf comparisons. It irks me that React gave their rewrite a codename and talked about perf, and so many people are now have this "Fiber is fast" stuff in their head without any real evidence. I've seen evidence that Preact is fast.
The React team did say, many times, that React 16 was not intended to be a "make everything faster" release. The "React Fiber" internals rewrite was intended to enable making re-rendering asynchronous in the future, but for now, the overall rendering process is still done synchronously to maintain compatibility with 15 behavior-wise. It's possible that the changes may make things smoother for your app now, but this was not a pure-perf-oriented set of changes. (The future asynchronous rendering is also not strictly speed-related either, but rather opens up a lot of possibilities for how React prioritizes updates.)
The initial improvement that Fiber gives is about splitting up the rendering process into bite-size chunks so that the determination of what does need to change doesn't block the main thread. The rewrite of the internals also made the codebase more maintainable, and gave them a chance to implement often-requested features like returning strings or arrays from render(), as well as implementing error boundaries.
You know very well that community doesn't hear nuance, all they hear is that Fiber=fast and this is why people question the Preact developers with stuff like "will you implement Fiber". I know that FUD wasn't the goal, but FUD is the result of overhyping a rewrite and giving it a codename.
It's all perceived performances, not real, raw performances.
Synchronous react rendering will still be as slow as ever.
This rewrite is a bit pointless to me, increase the complexity of using React on the long term (before, you could count on synchronous rendering having predictive results) and is just a hack to spread the cost of react's rendering across multiple frames. If anything your site will take longer to render now that it's async :)
I'm wary of progressively rendered sites (like Facebook) where buttons are rendered but don't work for the first few hundred milliseconds or seconds anyway. Complex websites can already defer the rendering of their most expensive parts (e.g google maps, etc); baking it in the framework sounds like engineers who had too much free time to me :p
I do full-stack javascript for my income, but have reached the point of not enjoying coding anymore because of this continuous change of ideas forced upon me. Why do I need to change from React.createClass to ES6 classes, from ESxx to Typescript or Flow, from React to Vue, from callbacks to Promises, from Flux to Redux, or from any idea to the next hyped idea?
When will people start to realise that this new method or technology they're implementing is deprecated already?
There is no end to this and I actually hate it as it destroys my passion for coding. I code to create things, not to continuously change what's created already and works fine.
As soon as I find a cool C job I'll definitely leave this mad house.