I think the issue is that Google has too much power to push features via Chromium. This would allow them to create new de-facto standards, which is what we had with IE back in the day.
Sure, the forks could choose not to implement whatever Google might come up with, but that's unlikely, I think.
Understood, but that's entirely opted into by everyone else. I don't see what else Google could possibly do to encourage competition. They already fund Firefox, and allow anyone to build - and change - based on Chromium. At what point do we wonder why competition isn't arising given all of that? It's not as though Microsoft couldn't do the R&D themselves if they wanted to. They've chosen to build on Chromium because there's not much value in the "power" you're citing. Certainly not compared to the cost of building Chromium.
I took "identical" as in feature wise. The user should be able to accomplish the same things, no matter what platform they're using.
I do think that the way the features are implemented should be platform dependent, i.e. use common UX pattern on each platform, fit in with the UI, and be good platform citizens.
The solution is to make the common features a part of a statically-linked library that you can pull into your apps. A web app is, IMO, never the answer when you want to address multiple audiences. It is bad for accessibility (because 99.999 percent of web app developers never consider accessibility) and it doesn't solve the problem that web apps are trying to solve (having 8 code bases all that have to remain in sync) because you will inevitably need your code to handle platform-specific differences, standards/conventions and whatnot.
I don't know iOS so I can't say, but a good UX does depend in part on platform expectations and every system historically been different. The compromises mean the each have good reason for what they do (sometimes anyway), but switching is hard.
It shows the sad state of user experience that applications completely ignore how different platforms function. For websites, I would expect them to follow the web conventions of UX. However, as soon as you're in a "native" application, you need to function like the device you're running on wants to function. Otherwise, it's going to be a jarring user experience for everyone in there. The whole system becomes harder to use.
When I look at job postings and see "React" I go "ugh" these days and find myself looking for Angular instead. That's the complete opposite of my thoughts from just two years ago.
I would still rather use something else (instead or React or Angular) but 1) most jobs in my area are asking for one of those, and 2) I'm actually starting to lean towards Angular even for personal projects.
Angular is great these days, and they're making really nice improvements.
I'm logged in, using Zed Preview, and selecting the model does nothing. In the configuration it says I "must accept the terms of service to use this provider" but I don't see where and how I can do that.
EDIT: figured it out. My Zed settings was broken, because it tries to create a settings file in "~/.config/zed", and my entire "~/.config" directory is symlinked somewhere else, so macOS permissions broke Zed's ability to create that config file. So I gave Zed full-disk access in the macOS "Privacy & Security" settings, Zed is now able to make a config file (which is where the model is set when you choose one), and everything is hunky dory.
Having stuff included does have advantages, but, in my opinion, some of those included things in Angular are really badly designed (I'm looking at you, Forms)
I never use Angular for personal projects, and I have been using TypeScript exclusively for years. I.e. other libraries work really well with TypeScript as well (sometimes actually better than Angular, in my experience)
I find the dev experience of Angular very frustrating, and many things seem overly complicated or not very well designed, in my opinion. That's why I would choose something else (anything, really)
However, if it was noticeably faster than alternatives then I would just deal with those frustrations, personally. User experience (including speed) trumps developer experience.
Test and, especially, builds time issues can be greatly reduced using Nx - give it a try. In one project (~400 components/directives) we’ve reduced the CI cycle (lint, test, build, deploy) from 50-55 minutes to 2-7 minutes. I know it sounds too good to be true, but there is no magic behind it: you can read how “nx affected” and remote cache works. It's basically free to use, we are using a free tier for every project.
One more thing: with Nx, it’s much easier to generate libraries, and you don't need to rebuild them to see the changes. Because of that, most of the code natively and without friction moves to libraries with time.
After having worked on an Angular project for a little over a year I'm at the point where I'm very unlikely to accept another job where they use Angular. It's so frustrating to work with, and every week I find another corner in the framework that, in my opinion, is very poorly designed and/or implemented.
Angular, to me, feels like it was designed by Java developers - classes and bloat* everywhere. Most code, when compared to a React etc. version, just seems like a wall of text on my screen.
But, this might make it more approachable to developers that come from a Java background - I see this at my current employer.
(*) By bloat I mean that I often feel like I should have been able to implement whatever feature I just implemented in half the amount of code.
reply