I would say the Web is unstable because it's a disruptive platform. Traditionally we build native clients, be it mobile or desktop, that work offline and connect to back end services. The modern web allows for that but in a simple, cost effective and cross platform way.
Naturally this attracts developers from all backgrounds to target this platform for their projects. These various influences puts pressure on the platform to morph to their preferences and with the platform still being young; that pressure (and profitability) means it tries to appeal to everyone, creating issues.
- Privacy
Privacy on the web is a challenge primarily because of government legislation. With the exception of the deprecated third party tracking mechanisms, the issues faced on the browser are no different to those faced by native applications - it's just that the scale of the web is much larger.
Any app, desktop application or website can opt to send user data to a third party. Cross-site cookies allow for customer tracking, but they are being phased out.
Service worker has recently started being used by advertisers for tracking. Generally though, advertiser networks can always operate in silos and request from their partners that they send customer data in exchange for compensation.
As a developer you may inadvertently subject your customers to tracking, for this I would love to see greater script sandboxing capabilities. Right now we have CSP and need to iframe anything we don't want to have access to the parent document - it would be amazing if we could sandbox _scripts_ directly, allowing us to grant no permissions by default and add them.
<script src="https://..." sandbox="fetch; dom" />
I would also love to see permanent storage (local storage, indexdb, cookie) require a user prompt for approval, where temporary storage (2 weeks) is allowed by default.
- Utility
The web platform has had incredible innovation and is going in a controversial direction that I personally love. While simple documents on the web are great, the platform is increasingly somewhere you can go to interact with rich experiences that operate on every platform.
Some criticize this as overreach of the traditional web, but in reality - Linux can now use MS Word and Photoshop natively on x86, x86_64, ARM, RISC5. Tools we use daily like APMs (DataDog, NewRelic), Google Maps, Email are all available on all platforms without requiring a native client. This is good because no one is going to make Linux clients for these applications.
Electron demonstrates that people want to use HTML/CSS as a UI toolkit (rather than platform native UI kits like QT, GKT, SwitftUI, WinForms, WPF, WinUI, Xamarin, Flutter, etc) and demand greater OS access than installable web applications can offer (like IDEs).
Web assembly demonstrates that people want to update this simple UI model using the language they like the best.
Expanding the Web Sandbox to offer lower level access to things like the permanent storage, filesystem access and hardware through user prompts would eliminate the need for Electron and allow for optimisations in a single browser to operate across these installable applications. The inclusion of Web Assembly would allow for more processor and memory efficient applications to be written - removing the stigma of "those bloated Electron apps"
Perhaps marking your web application as a "wasm" application would allow browsers to trim some JavaScript specific runtime logic allow for smaller memory footprints.
- JavaScript, Testability and Performance
There's a lot of investment in JavaScript tooling and a lot of impressionable developers out there are implementing software that isn't testable or well architected. A lot of these tools are used in improper contexts or, in some cases, are plainly bad tools.
By and large, JavaScript is a great language - or more specifically, a great compile target. A lot of the issues with JavaScript can be resolved by applying a pre-processor like TypeScript to it.
The ecosystem is a point of critique. Being as open as it is, it's unopinionated, lacking a standard library or tools and engineers must stitch together their projects. By comparison - Rust, Go, Kotlin, Swift all offer rich test tooling and strong standard libraries.
As a language itself, the language features of JavaScript have become an amalgamation of various developer preferences. Being that it's the only language that can be executed in the browser - it is under a lot of pressure to morph into every other language used by web developers.
If Web Assembly ends up replacing JavaScript as a compile target, the web would become a significantly nicer place to develop for as you can pick your language ecosystem of preference.
Some languages are better suited to testing, have better tooling or dependency management.
Some languages have access to better multi threading APIs and some languages have more efficient runtime performance. These would bring the development and user experiences on the web as comparable to native applications in performance.
- Rant on WASM
That said, WASM has been the biggest tease for me as they have over promised and under delivered. 5 years ago they were talking about it as a replacement for JavaScript as a compile target for languages like TypeScript, Go, Rust. Smaller binaries, faster parsing, better runtime performance and multi-threading support. Here we are today and I still can't make a div from my WASM-compiled C project.
Naturally this attracts developers from all backgrounds to target this platform for their projects. These various influences puts pressure on the platform to morph to their preferences and with the platform still being young; that pressure (and profitability) means it tries to appeal to everyone, creating issues.
- Privacy
Privacy on the web is a challenge primarily because of government legislation. With the exception of the deprecated third party tracking mechanisms, the issues faced on the browser are no different to those faced by native applications - it's just that the scale of the web is much larger.
Any app, desktop application or website can opt to send user data to a third party. Cross-site cookies allow for customer tracking, but they are being phased out.
Service worker has recently started being used by advertisers for tracking. Generally though, advertiser networks can always operate in silos and request from their partners that they send customer data in exchange for compensation.
As a developer you may inadvertently subject your customers to tracking, for this I would love to see greater script sandboxing capabilities. Right now we have CSP and need to iframe anything we don't want to have access to the parent document - it would be amazing if we could sandbox _scripts_ directly, allowing us to grant no permissions by default and add them.
I would also love to see permanent storage (local storage, indexdb, cookie) require a user prompt for approval, where temporary storage (2 weeks) is allowed by default.- Utility
The web platform has had incredible innovation and is going in a controversial direction that I personally love. While simple documents on the web are great, the platform is increasingly somewhere you can go to interact with rich experiences that operate on every platform.
Some criticize this as overreach of the traditional web, but in reality - Linux can now use MS Word and Photoshop natively on x86, x86_64, ARM, RISC5. Tools we use daily like APMs (DataDog, NewRelic), Google Maps, Email are all available on all platforms without requiring a native client. This is good because no one is going to make Linux clients for these applications.
Electron demonstrates that people want to use HTML/CSS as a UI toolkit (rather than platform native UI kits like QT, GKT, SwitftUI, WinForms, WPF, WinUI, Xamarin, Flutter, etc) and demand greater OS access than installable web applications can offer (like IDEs).
Web assembly demonstrates that people want to update this simple UI model using the language they like the best.
Expanding the Web Sandbox to offer lower level access to things like the permanent storage, filesystem access and hardware through user prompts would eliminate the need for Electron and allow for optimisations in a single browser to operate across these installable applications. The inclusion of Web Assembly would allow for more processor and memory efficient applications to be written - removing the stigma of "those bloated Electron apps"
Perhaps marking your web application as a "wasm" application would allow browsers to trim some JavaScript specific runtime logic allow for smaller memory footprints.
- JavaScript, Testability and Performance
There's a lot of investment in JavaScript tooling and a lot of impressionable developers out there are implementing software that isn't testable or well architected. A lot of these tools are used in improper contexts or, in some cases, are plainly bad tools.
By and large, JavaScript is a great language - or more specifically, a great compile target. A lot of the issues with JavaScript can be resolved by applying a pre-processor like TypeScript to it.
The ecosystem is a point of critique. Being as open as it is, it's unopinionated, lacking a standard library or tools and engineers must stitch together their projects. By comparison - Rust, Go, Kotlin, Swift all offer rich test tooling and strong standard libraries.
As a language itself, the language features of JavaScript have become an amalgamation of various developer preferences. Being that it's the only language that can be executed in the browser - it is under a lot of pressure to morph into every other language used by web developers.
If Web Assembly ends up replacing JavaScript as a compile target, the web would become a significantly nicer place to develop for as you can pick your language ecosystem of preference.
Some languages are better suited to testing, have better tooling or dependency management.
Some languages have access to better multi threading APIs and some languages have more efficient runtime performance. These would bring the development and user experiences on the web as comparable to native applications in performance.
- Rant on WASM
That said, WASM has been the biggest tease for me as they have over promised and under delivered. 5 years ago they were talking about it as a replacement for JavaScript as a compile target for languages like TypeScript, Go, Rust. Smaller binaries, faster parsing, better runtime performance and multi-threading support. Here we are today and I still can't make a div from my WASM-compiled C project.