9 ms·

Meanwhile, the web apps I wrote in 2014 in react still work flawlessly. Join us, you’ll enjoy the ride!

Phenix88be 7y ago
Thank you, but I m done for the frontend shit for a while. I will be perfectly happy throwing JSON to other frontend dev.
matsemann 7y ago
The Angular1 apps I wrote around that time are still running as well. The question is about maintaining them. Did you try to actually upgrade the react version? Lots and lots of breaking changes in that time, some really major ones along the way. Especially when upgrading react also forced one to change router etc.
stringyham 7y ago
Are you suggesting that angular apps written in 2014 would not still be working?
- gridlockd 7y ago
  I don't think so, the point is that Angular breaks user code often, whereas React rarely does. An Angular 2+ app built in 2016 (when Angular 2 came out) wouldn't build anymore. An Angular 1 app didn't even need a build step, so that would probably still work fine.
  - hmcdona1 7y ago
    lol it would work fine. I've had a joke app running Angular 2.0 in production for years. The code doesn't just expire and break. If you upgrade to Angular 8 in your package.json without running the upgrade schematics, yes it will break...because there were breaking changes. In 2016 React was on version 14. Are you telling me that from version 14 to 16.12 React has had ZERO breaking changes? Because they definitely haven't. That ecosystem has also changed recommended patterns countless times. They just choose to leave a lot of the old implementation options around if they can while Angular as a frameworks tends to be more opinionated. Same goes for any library or framework across major versions...
    - gridlockd 7y ago
      > I've had a joke app running Angular 2.0 in production for years. The code doesn't just expire and break. Nobody claimed that stuff which has been built and never touched again stops working. > In 2016 React was on version 14. Are you telling me that from version 14 to 16.12 React has had ZERO breaking changes? No, I'm not saying that. If they had zero breaking changes, I would have said exactly that, it would be remarkable. Nevertheless, there have been very few breaking changes in that timeframe[1] and they are highly unlikely to affect if you're doing ordinary stuff. [1] https://github.com/facebook/react/blob/master/CHANGELOG.md https://github.com/facebook/react/blob/master/CHANGELOG.md > Because they definitely haven't. That ecosystem has also changed recommended patterns countless times. You can just ignore the "ecosystem". You don't need it. React pretty much only does one thing. It doesn't impose an architecture on you. If you want to go all-in on the ecosystem, maybe it's as bad or worse than Angular. That's besides my point. > Same goes for any library or framework across major versions... No it doesn't. Some or even most people working with Javascript are completely out of touch with software engineering practices outside of the web bubble. Breaking changes are supposed to be avoided at great cost. Of course there's no real incentive for that if you're a random person pushing something to npm, or if you're Google and your business model is selling users instead of software.
Udik 7y ago
I joined a company that had two fairly simple internal web apps, one in Angular and the other one in React. Both had been written and maintained by a number of devs, each on the task for a few weeks or months. Both had several issues and blunders that needed to be fixed. However, while the Angular app had a very obvious, predictable structure, with issues confined inside single components or services, the react app was a totally obscure jam of javascript and html with more javascript and more html interspersed within, tons of redux boilerplate and properties passed down three or four levels of nested components. The stuff was such a wild spaghetti mess that editing a form in a foreground modal made the text in a background static page jump around when the number of characters in the form was even. So no, I didn't enjoy the ride, at all.
- crubier 7y ago
  Anecdotal evidence. This is just the result of bad practices. React is less opinionated than Angular I'll give you that, so I guess that subpar angular might be preferable to subpar react. Well-managed react is incomparable in power. Try to make a library like react-three-fiber using Angular, in less than 500lines of code.
  - andrewjrhill 7y ago
    > Well-managed react is incomparable in power. Unfounded opinion. > Try to make a library like react-three-fiber using Angular, in less than 500lines of code. react-three-fiber is much bigger than 500 lines of code.
    - crubier 7y ago
      Opinion founded on several examples such as the react-three-fiber one I just gave. And no, the initial implementation which was just as powerful (but lacked typescript typing) was mostly 2 files of 250 lines of code each. Look it up. I am waiting for the angular or vue counterparts. And also the angular and vue equivalents of react native.
dragonsh 7y ago
On HN in general there is a disdain for anything other than react, probably more people of Facebook generation and admiration of it's technology like open graph, react and few other products. Based on personal usage of React, it's no easier than angular or any JS based framework like Vue (which in my view more sensible than react). You add state management, templates, router and 1000's of npm packages to do anything simple and react soon becomes an unmaintainable nightmare with emany vulnerabilities if you do not upgrade. An app is not just simple react but many of the npm packages (although it's true in general for JavaScript eco-system which is by default is insecure and maintenance nightmare unless there is an extra amount of work done to secure it). Angular at least provide a decent complete single framework to work with and a unified documentation, there are issues with it, but react is same when you need any reasonable size app from it. React gives you an easy start with false sense that it's easy, than becomes just too convoluted and complicated with the addition of different components as soon as app starts growing. Maintaining and upgrading apps based on react is very difficult as one version to another it introduces breaking changes. Angular had similar thing from angularjs to angular 2, but slowly they made it much better but letting compiler do more work. Ivy tree shaking compiler will give a fight to upcoming compiler framework like svelte and keep the size smaller and may be in some cases much smaller than react app bundles, will wait for the benchmarks and size comparisons. I am still waiting for a simpler way of developing web apps, elm looked very nice, but it is still far from ready for use in the same way as Angular or react yet.
- crubier 7y ago
  Maybe the disdain comes from the fact that people don’t like getting a whole house (like angular) built on shaky grounds, but prefer a clean basic foundation (like react) where they can lay whatever bricks they like on top (routing, data management). It feels cleaner and more solid.
  - Cthulhu_ 7y ago
    "Built on shaky grounds" needs a citation and additional explanation. I mean I hear what you're saying, but Angular is an opinionated framework whereas React is not, and many people end up reinventing the wheel (or an application framework) in the process. There is value in being opinionated.
deleted 7y ago
[deleted]
disiplus 7y ago
i have a 2013 backbone and 2015 react still working in production.
Cthulhu_ 7y ago
I wouldn't expect anything else to be honest; as long as the underlying JS / HTML does not change, anything written 10, 20 years ago should still work now. Browsers (= your application runtime) are pretty good with backwards compatibility, and not touching your application should not break things. Unless it's doing unsafe or nonstandard stuff in the first place, like idk, cross-domain requests or weird stuff with iframes or whatever it was Google tried to do when it added an extension that tried to do preloading and stuff like that.
- JMTQp8lwXL 7y ago
  One day, all Meteor.js apps went blank in production (you'd just get a blank screen) due to a change in Chrome, that required everyone to upgrade (albeit, a non-breaking change, so it was easy to accept). I had been building an enterprise application on top of Meteor. The outage caused a huge lack of confidence among my customers.

Thank you, but I m done for the frontend shit for a while. I will be perfectly happy throwing JSON to other frontend dev.

matsemann 7y ago

The Angular1 apps I wrote around that time are still running as well. The question is about maintaining them. Did you try to actually upgrade the react version? Lots and lots of breaking changes in that time, some really major ones along the way. Especially when upgrading react also forced one to change router etc.

stringyham 7y ago

Are you suggesting that angular apps written in 2014 would not still be working?

gridlockd 7y ago
I don't think so, the point is that Angular breaks user code often, whereas React rarely does. An Angular 2+ app built in 2016 (when Angular 2 came out) wouldn't build anymore. An Angular 1 app didn't even need a build step, so that would probably still work fine.
- hmcdona1 7y ago
  lol it would work fine. I've had a joke app running Angular 2.0 in production for years. The code doesn't just expire and break. If you upgrade to Angular 8 in your package.json without running the upgrade schematics, yes it will break...because there were breaking changes. In 2016 React was on version 14. Are you telling me that from version 14 to 16.12 React has had ZERO breaking changes? Because they definitely haven't. That ecosystem has also changed recommended patterns countless times. They just choose to leave a lot of the old implementation options around if they can while Angular as a frameworks tends to be more opinionated. Same goes for any library or framework across major versions...
  - gridlockd 7y ago
    > I've had a joke app running Angular 2.0 in production for years. The code doesn't just expire and break. Nobody claimed that stuff which has been built and never touched again stops working. > In 2016 React was on version 14. Are you telling me that from version 14 to 16.12 React has had ZERO breaking changes? No, I'm not saying that. If they had zero breaking changes, I would have said exactly that, it would be remarkable. Nevertheless, there have been very few breaking changes in that timeframe[1] and they are highly unlikely to affect if you're doing ordinary stuff. [1] https://github.com/facebook/react/blob/master/CHANGELOG.md https://github.com/facebook/react/blob/master/CHANGELOG.md > Because they definitely haven't. That ecosystem has also changed recommended patterns countless times. You can just ignore the "ecosystem". You don't need it. React pretty much only does one thing. It doesn't impose an architecture on you. If you want to go all-in on the ecosystem, maybe it's as bad or worse than Angular. That's besides my point. > Same goes for any library or framework across major versions... No it doesn't. Some or even most people working with Javascript are completely out of touch with software engineering practices outside of the web bubble. Breaking changes are supposed to be avoided at great cost. Of course there's no real incentive for that if you're a random person pushing something to npm, or if you're Google and your business model is selling users instead of software.

Udik 7y ago

I joined a company that had two fairly simple internal web apps, one in Angular and the other one in React. Both had been written and maintained by a number of devs, each on the task for a few weeks or months. Both had several issues and blunders that needed to be fixed. However, while the Angular app had a very obvious, predictable structure, with issues confined inside single components or services, the react app was a totally obscure jam of javascript and html with more javascript and more html interspersed within, tons of redux boilerplate and properties passed down three or four levels of nested components. The stuff was such a wild spaghetti mess that editing a form in a foreground modal made the text in a background static page jump around when the number of characters in the form was even. So no, I didn't enjoy the ride, at all.

crubier 7y ago
Anecdotal evidence. This is just the result of bad practices. React is less opinionated than Angular I'll give you that, so I guess that subpar angular might be preferable to subpar react. Well-managed react is incomparable in power. Try to make a library like react-three-fiber using Angular, in less than 500lines of code.
- andrewjrhill 7y ago
  > Well-managed react is incomparable in power. Unfounded opinion. > Try to make a library like react-three-fiber using Angular, in less than 500lines of code. react-three-fiber is much bigger than 500 lines of code.
  - crubier 7y ago
    Opinion founded on several examples such as the react-three-fiber one I just gave. And no, the initial implementation which was just as powerful (but lacked typescript typing) was mostly 2 files of 250 lines of code each. Look it up. I am waiting for the angular or vue counterparts. And also the angular and vue equivalents of react native.

dragonsh 7y ago

On HN in general there is a disdain for anything other than react, probably more people of Facebook generation and admiration of it's technology like open graph, react and few other products. Based on personal usage of React, it's no easier than angular or any JS based framework like Vue (which in my view more sensible than react). You add state management, templates, router and 1000's of npm packages to do anything simple and react soon becomes an unmaintainable nightmare with emany vulnerabilities if you do not upgrade. An app is not just simple react but many of the npm packages (although it's true in general for JavaScript eco-system which is by default is insecure and maintenance nightmare unless there is an extra amount of work done to secure it). Angular at least provide a decent complete single framework to work with and a unified documentation, there are issues with it, but react is same when you need any reasonable size app from it. React gives you an easy start with false sense that it's easy, than becomes just too convoluted and complicated with the addition of different components as soon as app starts growing. Maintaining and upgrading apps based on react is very difficult as one version to another it introduces breaking changes. Angular had similar thing from angularjs to angular 2, but slowly they made it much better but letting compiler do more work. Ivy tree shaking compiler will give a fight to upcoming compiler framework like svelte and keep the size smaller and may be in some cases much smaller than react app bundles, will wait for the benchmarks and size comparisons. I am still waiting for a simpler way of developing web apps, elm looked very nice, but it is still far from ready for use in the same way as Angular or react yet.

crubier 7y ago
Maybe the disdain comes from the fact that people don’t like getting a whole house (like angular) built on shaky grounds, but prefer a clean basic foundation (like react) where they can lay whatever bricks they like on top (routing, data management). It feels cleaner and more solid.
- Cthulhu_ 7y ago
  "Built on shaky grounds" needs a citation and additional explanation. I mean I hear what you're saying, but Angular is an opinionated framework whereas React is not, and many people end up reinventing the wheel (or an application framework) in the process. There is value in being opinionated.

deleted 7y ago

[deleted]

disiplus 7y ago

i have a 2013 backbone and 2015 react still working in production.

Cthulhu_ 7y ago

I wouldn't expect anything else to be honest; as long as the underlying JS / HTML does not change, anything written 10, 20 years ago should still work now. Browsers (= your application runtime) are pretty good with backwards compatibility, and not touching your application should not break things. Unless it's doing unsafe or nonstandard stuff in the first place, like idk, cross-domain requests or weird stuff with iframes or whatever it was Google tried to do when it added an extension that tried to do preloading and stuff like that.

JMTQp8lwXL 7y ago
One day, all Meteor.js apps went blank in production (you'd just get a blank screen) due to a change in Chrome, that required everyone to upgrade (albeit, a non-breaking change, so it was easy to accept). I had been building an enterprise application on top of Meteor. The outage caused a huge lack of confidence among my customers.