|
|
|
|
|
|
by loh
1437 days ago
|
|
|
I was just thinking about this exact topic less than an hour ago. We seem to be slowly reaching a consensus on various best practices and tools, and it's obvious which ones are winners and will be here to stay for the foreseeable future, despite the inevitable churn. There will always be discussion (and disagreements) on how to make things better, and when I was less experienced, I (ironically) used to be way more opinionated on the best approaches, but over time, after witnessing the evolution over the years, it always comes down to one core tenet: choose the best tool for the job. Even this isn't purely objective, as it can vary depending on your individual circumstances, time constraints, and the people (and their skillsets) available to do the work. I've always imagined a future where almost anyone can quickly assemble high quality applications (both software and hardware) to meet almost any human need. We're seeing this trend with all of the low-code/no-code tools popping up, but to take it up a notch, it will probably require some standardization of tooling and practices. I think this is the next phase of our technological evolution and would be a great solution to the author's request for "more better web apps". |
|
|
And of course with web assembly, you can actually replicate a lot of that native experience in a browser and even run very slick 3D games or emulators running entire desktop operating systems. So, it's not necessarily true that browsers are not technically able to do a better job because they clearly are. It's just that web developers and web developer tool makers are just not doing a great job leveraging those capabilities judging from most popular web apps.
My personal observation as somebody who focuses on backend mostly but also needs to worry about having a decent frontend for that backend is that we are being limited by an industry that is perpetually suffering from maturity issues. Both at the technical and personal level (I agree with the author on this).
A lot of the technologies and tools are simply not great when compared to native app tooling and they only compare to each other. So, you get these elm, angular, vue, react, etc. proponents each arguing how their preferred thing is better than the other thing and why. What they should be debating is the huge gap with native apps that none of them come close to bridging and why that gap fundamentally is still a thing in 2022. Why do people have to reinvent so many wheels to build a simple web app? And why is delivering a slick web app experience such an elusive goal?
The future is 25 years ago when any idiot with an MBA could open up Visual Basic, Delphi or whatever and click together a working native app in an hour or so. A lot of really bad enterprise software was created that way. But nothing similarly usable ever really got popular for the web and I'd argue using most enterprise web apps is a similarly dreary and miserable experience as it was a quarter of a century ago. It's gotten harder to build those but they still suck.
Mobile developers have had visual UI tools like that available all along even though many would prefer not using those. But in terms of the underlying component frameworks, mobile development is a lot more similar to how Delphi and VB worked 25 years ago than modern react development. IMHO, those component frameworks are a key reason people like the "native" experience. The web based equivalent component frameworks (there are many) are just a lot hackier, messier and ux challenged.
Ironically, with Blazor, you can target the web and get your good old VB code to run in a browser. Not sure if that's the future but it sure seems to work. Again, the problem is not browser limitations but tools. If MS can target browsers with their decades old tools, web developers can raise the ambition level a lot more as well. Why don't they? Apple and Google have a stake in the current status quo of the web sucking more than their mobile walled gardens. So don't look to them for answers.