71–80 of 86 posts
Was a firm believer in Angular when it was version 2, made the switch to React before Angular version 4. Best choice I've done for productivity.
Same, they handled the transition terribly, I really wanted to use angular but I stuck with knockout and then ended up going to VueJs instead.
Earlier quoted context omitted.
How about the story on mobile? Is there an Angular analog to React Native?
Not really answering your question cause React Native builds to native platform code. But Ionic uses Angular internally -> Cordova-> PhoneGap (mobile)
. Ionic app never feels completely right as components are not as much optimized as platform native.
. If Apple/Google comes up with a new look/style for default components, good luck chasing and updating libs.
If you are targeting for mobile-app and web, just go with react-native.
Earlier quoted context omitted.
>At the mid-size corporation that I work at, we just standardized all Javascript development on Angular from a mismash of a ton of technologies. Angular seems very well suited for this role. In my experience centralisation and fixation on specific technology leads to stagnation quickly. IMO you should allow teams to choose their own tools. How else will you improve?
To quote one of Akin's laws which were on HN yesterday, "better is the enemy of good". It's really good when one technology is used throughout an organization to achieve the same purpose. At some point, the technology you use is actually good enough, and incremental improvements to "keep up with the times" are simply distractions from the real work. And if at some point you find that your tech has truly stagnated, at…
Earlier quoted context omitted.
> Focus on what you want to build, not the tools you use to build it. This is an interesting comment to me because, by essentially building your own framework, that onus is now completely on you. If you want to implement code splitting or tree shaking or whatever, you have to figure that out for yourself. That's time taken away from building product features. Whereas other frameworks can offer this out of the box bec…
I also did what the parent did. I'm using mine on several enterprise projects. And I'd also argue that devs spend //more// time implementing updates due to framework churn than for maintaining their own framework. After mine was "done", it was done. There is no code churn, all the features are in, tight code, etc,...so now I only spend time creating/expanding my products. The discussion today about React v6 is exactl…
Do you actually believe that? Or does your organization not believe in software maintenance and opts to rewrite entire apps instead? In my experience, Enterprise^w software is never "done". A common conclusion to your story is "I've been asked to modify/refactor this app that has ben unchanged since 2005" - sure it's perfectly crafted, but it's in ECMAScript 3. Also Best practices shift over time.
Earlier quoted context omitted.
>At the mid-size corporation that I work at, we just standardized all Javascript development on Angular from a mismash of a ton of technologies. Angular seems very well suited for this role. In my experience centralisation and fixation on specific technology leads to stagnation quickly. IMO you should allow teams to choose their own tools. How else will you improve?
This sounds like how you'd end up doing web development in the least efficient way possible. There is a ton of space for reuse, the web is dead simple and the same pattern shows up over and over and over.
Web is not dead simple (I consider web to be frontend development in this context). Why I would consider web to be hard: - it is harder to do frontend development than backend, because you write code which is sent to one of thousand different compilers, creating another layer of difficulty. Versus controlled environment where your backend code is being run - While there are only few patterns which are applied to FE development, there are many new features(PWAs, real time syncs,..) coming into web. Taking advantage of them requires learning, coding and refactoring. You might say - this is just reinventing the wheel - while partly that is true, developers will still need to learn, adapt knowledge to web, build tools.
Earlier quoted context omitted.
Angular 6 and all future main releases will be supported for 18 months. As for backwards compatibility, as was described in the presentation on the new renderer they are working on, 600 apps at Google are built on Angular, so there is a great deal of internal pressure to make sure backwards compatibility is a constant consideration. Along those lines, one of the big tooling features in this release is the upgrade com…
> Angular 6 and all future main releases will be supported for 18 months. Does that mean that every 18 months you'd have to rewrite your app in the newer angular version? And if not, what does it mean?
And they will tell you upgrade is painless, but it's still work. And then if you have many dependancies (and the npm culture is to make every single function a package...), one of them will be painful, another one will stop working, etc.
And now in this devops world, the same devs will do server maintenance. The next 10 years are going to be so fun to watch.
Earlier quoted context omitted.
Angular 2 came out in 2016. Why use angular 1 in 2017?
It was 2016 when we started this front-end rewrite, away from a mess of jQuery and Razor view spaghetti. Angular 2 was brand new, without much support for third-party components we used, and AngularJS looked like the mature option. Probably should have bet the other horse, but c'est la vie.
I was joyfully expecting this upgrade and checked the release notes daily during the RC phase. Don't let the quick 'major' version changes shock you, upgrading 4 -> 5 was easy and I expect the same for this upgrade. A big thanks to everyone involved in shaping this release and ensuring the upgradability for the past major versions, including the huge effort in making it possible to continuously migrate from AngularJS…
Earlier quoted context omitted.
To quote one of Akin's laws which were on HN yesterday, "better is the enemy of good". It's really good when one technology is used throughout an organization to achieve the same purpose. At some point, the technology you use is actually good enough, and incremental improvements to "keep up with the times" are simply distractions from the real work. And if at some point you find that your tech has truly stagnated, at…
The problem is how will you find that your tech has stagnated? If nobody experiments with new tech - who will teach others? How will that knowledge come into your corp? Hiring new people to do that will not work, because: - People being hired will be evaluated by legacy people (different thinking will be considered disadvantage during interviews) - Legacy people will not listen to new hires since they have no credibi…
But when every team is doing it's own version of the same thing, that's another story. It can be crushing to productivity, in fact it's likely to be the deciding factor if some types work get done at all. And, unlike your concerns about preventing stagnation, the only way to solve that problem is to stop doing it.