13 ms·

After 2 years of Angular madness I will send my resignation and I hope I will never work with it again. My app is a big stack of workaround stuff that might br

• crubier 7y ago
  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.
• mattlondon 7y ago
  Do you have any examples? I've been doing Angular2+ apps for years and have not experienced this.
  • Phenix88be 7y ago
    I had many, but here is the first I can remember correctly : I have a backendService that use the httpClient; it's a wrapper that automate stuff to make API request. I guess it's pretty common. I have a provider for APP_INITIALIZER. It can use the HttpClient but not the backendService. The backendService work everywhere else of course.
  • doczoidberg 7y ago
    I also not experienced these problems.
• JoeNr76 7y ago
  I've been doing Angular for 5+ years now. I think you might be using it wrong because I never experienced anything like that.
  • momento 7y ago
    Angular has a lot of unique concepts that people find difficult to wrap their heads around. The Observable pattern, decorators, typescript, etc. When you throw things like NGRX and effective management of state / side-effects in the mix; things get exponentially more complex and difficult to scale. I have personally witnessed companies take guys who have been slapping together "apps" in jQuery / .NET for the past 10 years and tell them "it's time to make the stack modern" and "we're going with Angular because we're a Microsoft house". Things go very bad very quickly. If you don't take the time to understand the Architecture behind scalable modern web applications you're going to have a bad time. Anyone can slap together a quick and dirty app with Angular or React - not everyone can scale one correctly with thought given to the architecture behind these applications.
    • mcv 7y ago
      I haven't done much with Angular 2+ (I use Vue now), but in my Angular 1 days, I've definitely seen a lot of Angular apps that were basically put together like a jQuery app. Massive controllers, lots of dom manipulation and logic in the controllers. My approach at the time was that controllers should be as small and simple as possible, with most business logic, data models, communication, etc extracted to services. The controller should just connect the various parts, nothing more. But when you're used to unstructured jQuery, the controller is an obvious place to just put everything.
    • JMTQp8lwXL 7y ago
      Agreed. "Unscalable" code is completely possible to write in Angular or React. Simply put, it's bad code that doesn't follow the paradigms of the framework it lives in, with all of the usual suspects (spaghetti code) sprinkled in.
    • BjoernKW 7y ago
• stupidcar 7y ago
  I find it deeply ironic that, judging by the stories regularly posted and upvoted, Hacker News readers supposedly value science, rationalism, evidence-based thinking, etc. Yet the same people reliably upvote these kinds of toxic, detail-free, ungrammatical, emotional rants. By all means, upvote criticism that is properly argued and backed up with evidence. But upvoting these kinds of comments is the equivalent of posting anti-vaccination memes on Facebook.
  • projectileboy 7y ago
    Self-proclaimed skeptics are rarely skeptical about their skepticism.
• remify 7y ago
  Angular is a framework if you've hack you're way without following best practices you expose yourself to such things. I've been working with Angular2+ for 3 years and I haven't met any bug. Know the concepts, apply them and you'll have an easy trip.
  • Pigo 7y ago
    Almost every problem I've seen with Angular involve people not knowing how to implement features correctly or using it for what it wasn't meant to be used for. You know, the same problems people have with all frameworks.
    • node-bayarea 7y ago
      Use things like Svelte. It's a framework that lets you hack. You don't need 'best practices'.
      • jaywalk 7y ago
        >It's a framework that lets you hack. Translation: It's a framework that does less.
        • levythe 7y ago
          This isn't a bad thing if the things the framework does aren't terribly useful for what you want to accomplish.
      • machello13 7y ago
        why in the world would I want a framework that lets me hack?
    • ng12 7y ago
      The problem is there's so much you need to know. Angular invented a custom feature with plenty of boilerplate for every task -- and if you want to do something that Angular doesn't explicitly support you'll end up fighting the framework very quickly.
• bdcravens 7y ago
  What framework would you use to avoid those workarounds (or others in different parts of your app)?
  • Phenix88be 7y ago
    I want to move away from the frontend job et do backend stuff. I really hope to stay away from javascript for a while.