Overview
The World Wide Web, or just "the Web," is an increasingly complex set of technologies that allows us to communicate and share information all over the world.
It's existed for generations, and only gotten more and more advanced as time has gone on due to various safety, performance, and usability additions.
In the modern day and age, websites have slowly transitioned from being focused around sharing text, files, and links, and more towards intricate services; web applications.
In this article, I'd like to illustrate what makes web applications convenient, what we could learn from desktop applications to improve web applications, and what my personal proposal is for the future of the web.
Web Applications vs. Desktop Applications
Discovery, Bookmarking, and Package Managers
Finding an app is the first step to using it. Web applications are usually quite easy to find, only requiring you to use a search engine. People can also share links to the app. While these things are still true with desktop apps, as they'd have their own site, there's the problem of having to download, possibly install, and then run a program.
Although, desktop apps benefit from package managers, app launchers, and start menus which all help the user install, uninstall, update, and access desktop apps.
The only issue is that package managers and app launchers are primarily found in the Linux community, as package managers are usually command-line apps (that's not to say Windows doesn't have one, it's just scarcely used) and other operating systems do not need app launchers. In the browser world, the closest thing to a package manager is the bookmarks bar, as that allows you to save links for quick access.
Sandboxing, Safety, and Malware
One of the immediate benefits of the Web is that many websites are secured with TLS, meaning all HTTP requests sent to those websites are encrypted. In a desktop app, this is something a developer has to go out of their way to implement, and many independent developers have limited experience with cybersecurity.
Adding to this, desktop programs have the ability to execute any code. There are plenty of viruses that have circumvented the need for permissions, and it's not even necessary to have permissions to wreak havoc. Attackers find new ways to exploit processors and operating systems to circumvent safety patches, precautions, and anti-malware programs. There is a constant arms race.
With new web technologies, such as WebAssembly (WASM) and WebGPU, we have the ability to make performant and modern apps in a completely sandboxed environment. WebAssembly has to be safe, considering it takes advantage of the end-user's processor. This is effectively remote code execution, which would be terrible with unregulated, malicious code, but WebAssembly is designed to not be capable of such code.
Better yet, you can compile to WebAssembly from various desktop programming languages, like C, C++, and Rust. This is not only beneficial for developers who want to work with lower level code than JavaScript, usually for performance benefits, but it also means we can develop applications for both web and desktop platforms with relative ease.
That's not to say that websites are perfectly safe. Many will make you download malware, steal credentials by posing as real sites, or scam you with misleading pop-ups. Cautious users will learn to recognize fake looking URLs and suspicious websites, and browsers combat these by showing warnings, though not all of them are blocked. The issue here is that search engines will show anything they can find. A lot of these malicious sites are not exactly front page, but it's still harmful to display them to unsuspecting users in any way.
Bundling and Binaries
One of the issues many front-end web developers run into is making their site load quickly. The cause of this is usually due to sites serving large files or, more often, many files. Many tools and services were designed to combat this issue; CDNs cache commonly used CSS and JS libraries, bundlers minimize and bundle code and assets into easily cache-able segments. WebAssembly even aids smaller download sizes as it is a bytecode language, meaning it is compiled and stored as a series of bytes, rather than as text, like JavaScript. There's even been changes made to HTTP to help with this problem.
The issue here is that we are putting a lot of work into something that desktop apps have no issue with, as many do not need to load anything, and if they do, it's usually just from the filesystem, which is a lot faster than downloading multiple files from an HTTP connection. Where desktop apps fail is in downloading them. A lot of apps come with heavy file sizes, usually due to the libraries they require, or their assets. This means you might have to download a couple hundred megabytes for one app. A lot of these apps are actually Electron instances. Electron is a framework that lets you make desktop apps with web technologies using Node.js and a version of the Chromium browser, the backbone of Chrome, Edge, Opera, and various other browsers. Many apps you know of, including but not limited to Discord, Steam, and Spotify, all render their interface using browsers, either partially or fully. This allows for flexible, modern visuals with CSS, but it has a major impact on memory usage and file size.
A Proposal for the Web
As you can tell, both desktop and web have pros and cons. There isn't much we can do to help with the issues surrounding desktop, but we can improve the web, we do it all the time. Not only could we make it even safer, but we could make it easier to discover and manage apps as well as easier to load them. We could even decouple HTML, CSS, JS, and more from browsers, so developers have a choice over what they can use, and users can be given the most effective, fast software.
Ditch Web Browsers!
This is going to spark a lot of mixed reactions: I personally think that we need to abandon the old web if we want to truly improve. Web browsers are insanely complex pieces of software, they are focused on many different things from accessibility to responsive web apps to video and audio playback to high-performance web games. We could simplify things. Backwards compatibility is a strange focus of web browsers. Many developers take the time to make their sites compatible with Internet Explorer, a heavily outdated, slow, and all around terrible browser you can't even use anymore.
We can keep the good ideas, but there will be a lot of rewriting bad ideas if we want things to be vastly improved.
Web Executables
Instead of web browsers, I propose we have an app that has the ability to load web bundles (AKA web executables). They would use an archive format that is easy to compress and verify but also fast to traverse, allowing our new web browser to easily find and read resources. When our browser receives a bundle, it will find specifically WebAssembly code to execute on a new thread. This code will handle rendering, page events, and various other things. The "WebAssembly first" approach decouples code execution from JavaScript. JS would stop being a primary focus of browsers, perhaps having its own runtime alongside WebAssembly, but more likely, it or a derivative of it would be compiled to WebAssembly.
Rendering
Don't be worried, this concept doesn't entail forcing everyone to write low-level WebGPU code. We will allow that, but frameworks will exist to render pages in a more traditional way, possibly even allowing developers to load CSS resources. This completely decouples rendering from CSS and gives people more freedom to make their own formats and frameworks. No longer would you need a tool for transpiling SASS or LESS, just the library for it.
App Discovery
Not only can you access apps via a URL, but our browser will have first-party support for "app discovery portals." Think app stores but without the monetization. The keen amongst you will notice the plural, "portals." Yes, decentralization.
Now, an issue arises when you allow people to create their own portals. It goes from an app store to more of a repository, which is alright, but it does complicate the discovery part. I don't want to think about an "app discovery portal discovery portal," so the alternative is going to derive from the old web: Word of mouth! If you want your portal to be found, make it worth finding. Link to your portal from your high-quality web app.
Access Protocol
The pattern of decoupling the web continues as HTTP will stop being the primary way to retrieve resources. It would still be possible to use HTTP, but you would require an HTTP client/server library.
The alternative to HTTP is a very simple protocol designed just for requesting and retrieving bundles as well as accessing app discovery portals. You visit a web:// link and it either brings you to an app (via downloading a bundle) or a discovery portal (via downloading some metadata). In our browser, we'd even allow for saving portals and apps to our homepage.
Sockets
With the removal of HTTP, you gain the benefit of sockets, allowing you to send packets, rather than just make requests to an HTTP server.
A bit of work would have to go into making these sockets safe for the end-user. We obviously can't use plain TCP sockets since an attacker could make an app that makes the end-user send malicious packets. Regardless, the work is worth it. The amount of potential this gives developers is astonishing.
Closing
There's a lot we can do to improve the web. Speed, safety, and usability are the primary factors in designing an application, and as such, are the focus of my set of improvements. I do also believe in developer experience. Modern programming languages have not only shifted towards better user experience, but better dev experience too, and it's why I designed a lot of this around giving developers more choices and power.
You don't have to agree with all of the ideas I've presented. In fact, if you have anything to say, I'd highly recommend doing so! Feel free to comment, tell me this is stupid, or whatever. I thank you for sticking to the end.
Top comments (0)