Serious question, what's the issue with react-router?
I'm sure there are situations where using react-router makes sense, but for me it was one of the few packages 'blessed' by the react ecosystem that gave me more trouble than it was worth.
Some claim the added flexibility and easier deployment[1] of web based applications is worth this 3x increase, but usually that's tech staff saying that, not business owners. They want get-it-done-on-budget, not eye candy, if given a clear choice.
We have to come clean and admit that job security is keeping us technical people from being objective on this. A convoluted standard increases demand for specialists.
I suggest the industry form 3 browser-based mini-standards: A) Art/Gaming/Charts/Entertainment, B) Document-oriented (current HTML may almost be good enough), an C) "productivity" oriented data and CRUD.
That way each can focus on doing its niche right instead of trying to be one-size-fits-all.
[1] With a good stateful GUI-markup-over-HTTP standard, we probably wouldn't need local installs to get decent GUI's.
Not it's not. That's what it was created for, but clearly it's not anymore. People are not publishing just documents anymore, it's a fact that HTML is used for all sorts of things from simple sites to complex applications.
We agree it's not great, for all of these purposes but this ship has sailed, we need to deal with it. Either we create something different and good enough to not die in the water, either we improve HTML so that it supports what people are already using it for.
It really is. Just because some people have a uncanny propensity to mix concerns that shouldn't be mixed, that doesn't mean that a data structure is something else.
The linked video talks about documentation, which is a great example. Do you think I should have to download an app to read documentation? Should I have to go find my phone to read documentation because they didn't have enough time to also support desktop OSes?
Here's another way to think about it. The web is competing with platform-specific apps (iOS, Android, macOS, Windows, etc.) to be the primary computing platform of the world (in terms of how the general population interacts with computers). Your position seems to relegate the web to a secondary/niche platform by definition. Do you agree that the web should be a secondary/niche platform?
Disclosure: Google Web DevRel (work on https://web.dev)
The web/web app paradigm isn't the reason Electron exists. Electron exists to poach web developers into app development, because native code and frameworks are hard. There's no technical reason why we can't go back to native apps, the friction is entirely due to culture and business, and an entire generation of developers who've never written a line of anything that isn't javascript or maybe python.
Also, being able to distribute and run software over a network is a good idea, and it's a logical progression of the purpose of the web, which is to allow open access to information and media. Code is no less a form of media than video, audio, images or text. A web that would let me read whitepapers but not let me emulate an Amiga would be crippled in its potential.
And that notwithstanding the fact that most "web apps" are just documents that use javascript as a front-end framework, and most people's complaints along these lines are aesthetic and emotional, rather than technical.
I don't agree with the "poaching" statement, but I would argue that "frameworks are hard" should be replaced with "desktop gui frameworks are appalingly poor".
Webview-based rendering frameworks trade away native look-and-feel for a myriad of tools and processes and techniques and workflows and expertise that you simply do not get with plain old widget frameworks. GUI developers know this, and in particularly GUI frameworks vendors are well aware of this. In fact, check XAML or QML.