Paradigm 1 - interconnected, hyperlinked web of text-and-content-based documents: open, accessible, amenable to indexing and tooling and so forth.
Paradigm 2 - delivery vehicle for cross-platform, full-featured, somewhat-security-sandboxed, applications.
I agree with the article that it's sad if Paradigm 1 is trampled to make way for Paradigm 2, just because (as you point out) we haven't been able to develop a viable alternative. In theory these could coexist, but the point of the article is people are being trained in Paradigm 2 and try to use it for purposes that are much more suited for Paradigm 1.
Just as sad, Paradigm 1 is more oriented around decentralization, giving power, options, and information to the user; Paradigm 2 is often exploited for lock-in, control over user's decisions, collecting information about the user, etc.
The need to serve Paradigm 2 existed all over the place in the plain html days.
It’s just instead of having standards-based languages for Paradigm 2, we used to embed janky Flash SWFs and Java applets, were dependent on single vendors to patch zero-days in closed source code, and had to pay hundreds of dollars for licenses for developer tools.
Today’s Paradigm 2 now has multiple competing implementations, open standards, and powerful DOM inspectors in almost every web browser to tear apart any modern Paradigm 2 app you come across.
I think today’s Paradigm 2 gives more power to users than the Paradigm 2 of the past :)
From a user's perspective, it's maybe a bit more nuanced... I'm tired of websites trying to get around my adblocker, and everyone attempting to enable desktop notifications, for example. If I'm trying to read someone's document they've published, I'd like it to just be a document, thanks. But, increasingly, "Paradigm 2" webapps like Spotify and Google docs are as good or better than "rich" desktop apps.
Also agreed, many web apps these days are as good or better than desktop. I actually have worked and am working on applications that replace their desktop counterparts. They're practically easier to scale, tend to have tooling to handle window sizes better, customization is easier and imho just nicer to write against. Better still if you don't have to support legacy browsers. Most browsers today are supporting modules and async import. Still using Webpack and Babel for JSX, but really close to a point where I'd just assume write for esm and have a server-side translation for JSX on demand (cached).
Browser vendors (Firefox, Chrome, Brave) please get your act together to prevent https://nothingprivate.ml
Go on?
Buttons by default have keyboard support for focusing and clicking. You’d have to manually add this to a div.
Screenreaders, scrapers, and other automated tools reading your html understand buttons and treat them differently from divs.
It’s easier for other devs to understand your code at a glance if clickable elements are buttons.
But mostly because it's usually unnecessary and smacks of laziness on the developer's part.
Hopefully, but people have a large capacity to deal with broken web software. Back when I was young, it was all the Java & .Net websites that turned every friggin link into a POST form so that navigating back, and opening in a new window was completely broken.
I read a lot of articles about front end, including framework & library trends, usage statistics, rumors, etc., though I've never heard that React has begun to die. Can you provide a citation?
I tend to prefer semantic tags most of the time. I do wish there was a CSS declaration, or maybe an <html> attribute to start off with absolutely NO styling, so that it all comes up from what's in the CSS only. Various resets suck or don't work well, or are really big for various reasons. For that matter, being able to reset everything under a given element that way so that in-browser rules aren't applied would be really nice for WebComponents.
My own weakest point is probably on CSS these days, I just haven't really kept up since 2.x as I haven't really needed to, and can usually google when I need more. I feel the flexbox stuff is more complex than it should be.
In a clean (from scratch) dev situation, when would it make sense to use the div option?
Does it semantically make the most sense? Not necessarily, but it isn't a blocker to most accessibility tools and use and support for ARIA attributes is pretty widespread nowadays, including all of the major browsers and screen readers.
> https://developers.google.com/web/fundamentals/accessibility...
> https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
The important point is that fundamentally using a <div> in place of <button> can still be made to work easily with these accessibility tools - many comments here imply it can't be done at all and only a button will work. Does it semantically make sense? Likely no, but it isn't a hard blocker on accessibility.
To me, the Browser is the most widely distributed sandbox runtime ever! It’s just missing a few crucial things we plan to add soon :-)
It can be used to update itself, too :-)
> the important feature of the browser is that it provides a sandboxed platform for running untrusted code without a builtin "walled garden moral police".
> for some reason "commercial" OS vendors are not able or willing to provide a safe "native" sandbox completely uncoupled from curated app stores.
The key word here is absolutely "unwilling". All the platform vendors want platform lock-in, they don't want a general purpose platform. Microsoft originally tried to do this to the web with ActiveX, before even Flash. At least Flash was slightly cross-platform in that Adobe provided Mac and Linux versions. These days no platform vendor is going to give up their 30% cut voluntarily.
In a world of fully general app sandboxes, you can switch out your hardware and OS at any time without disrupting your life or business. Therefore those are commoditized, and their price drops to the marginal cost of production - which for software is zero.
(Also I think CS theory took a while to catch up to practical security; everyone used to teach the model in which multi-user systems were trying to protect users from one another, not one where a single-user system is trying to protect the user from predatory apps, viruses and potentially unwanted programs.)
I think software's marginal cost of production is zero only if no updates/fixes are ever needed. I know it sounds like nitpicking but just think of all the vulnerabilities discovered, specially the closer software gets to the lower end of the stack. Even if an OS could suddenly stop adding features and still be viable in the market, the cost of patching it as holes are discovered is certainly not zero.
It certainly is a real cost that has encouraged software vendors to move from "box" sales (which became tricky when we gave up on boxes) to annual licenses and/or SaaS. But it's not a marginal cost.
Flash tried to do this 15-20 years ago. Flash was basically "here's a canvas, do whatever you want within reason". It had its use cases back then but the general web vastly preferred good old HTML and eventually CSS and JS.
There's a lot of value in having constraints, especially when those constraints (HTML) are specifically designed for displaying documents.
- it was owned and controlled by a single company and thus a target for other companies instead of other companies helping to improve it
- that single company was unable or unwilling to fix security holes in the sandbox and browser makers eventually got fed up with that
- while there were some ways to interact with the underlying browser environment, ultimately a Flash instance lived in its own little bubble, creating usability problems
Putting the HTML+CSS layout engine into a separate module doesn't mean that it wouldn't remain the standard way of doing document-layouts on the web, it would just mean that higher-level solutions wouldn't need to use hacks and workarounds to map their concepts to HTML+CSS (same way as Javascript had to be used as a less-than-perfect compile target before WASM because it was the only option to run code in a browser).
The thing is, most people don't want a blank canvas to go nuts with for the general use case. It's too complicated. Suddenly you need to learn entire SDKs and pull in many dependencies just to render text on the screen.
The reason HTML and the web was so well accepted back in the day was all you had to learn were a few HTML tags, a couple of properties and then drop it onto a Geocities site and you were good to go. It was something you can do and see real progress on in 10 minutes with very little background knowledge.
Compare that to now where if you wanted to be a "trendy front-end dev" you would probably reach for Vue / React + Webpack* and go SPA style for all of the sites you make because you learned something and now you want to apply it everywhere. Meanwhile to serve a document such as a blog post, you just went from having 15 HTML tags in a single HTML file and some CSS to pulling megabytes of Javascript sprawled across hundreds of dependencies and now you have build tools, an entire runtime environment (Node) and are using APIs that don't exactly match up with HTML exactly, and then your entire site isn't even crawlable by search engines unless you introduce even more complexity to do server side rendering and before you know it, you're dealing with something that's even more complicated than Flash was back in the day.
* I personally use Webpack to handle my assets too, but I don't write SPAs for sites that are document based (which tbh are most sites).
Are you kidding me? Flash was an absurdly popular platform. Careers were launched on Newgrounds!
I'm not saying it wasn't popular, but what do you think the percent spread was between sites that were fully driven by Flash vs not Flash?
I don't have the stats in front of me, but I would guess it was probably 2% Flash vs 98% non-Flash. Now, a lot of sites had sprinkles of Flash but very few sites in the grand scheme of things were solely rendered with Flash. Part of the 2% were sites like 2advanced studios.
...yeah, because that's not what Flash was about. Flash was an application platform (ok, so more like an Animation platform) first and foremost. Why would anyone run their whole site in flash? It wasn't the right tool for that job.
And this is exactly what I'm trying to say.
Back in the day you would very likely reach for Flash if you wanted to build an FTP client that ran in a browser. Totally reasonable use case because that's a highly interactive app that doesn't really follow the request / response style of a document style page. But you likely wouldn't reach for Flash to build some type of site that presented data in a document style (pretty much the general use case of what a website outputs).
But if you fast forward to today's technology, some front end developers are bringing in the complexity of creating SPA style applications that are primarily rendered with JS for everything -- even document style websites like a personal blog and the original comment I replied to is hinting they want to remove constraints from browsers to give us more of a FFA style of doing whatever we want to render pages. I was just saying that model didn't really take off for the general use case with Flash decades ago.
Fortunately we still live in a time where web developers can choose what they want to do, but browsers shouldn't change the concept of being something that renders HTML that is optionally combined with other things like CSS, fonts, JS and images.
If people really wanted a no constraints platform to build any UI they want with a blank slate then web development as we know it today would be a completely different environment.
Instead, 20 years later, we're still trucking along with HTML as being the primary focus, and everything else can be loaded as needed.
You can build some pretty amazing things today with a combination of HTML, CSS, JS, fonts and websockets. But at the same time, if you don't need an application and just want to serve a HN style site, you can render HTML with a bit of CSS and everything works well. To me, that's one hell of a success story.
I'm not sure that happened. My friends and I got on MSN Messenger and shared flash sites all the time. Kongregate and similar gaming sites were part of it, but so was YouTube, and so were greeting card sites, ESPN, various other news sites and many, many others.
At least from my POV, maybe a few people hanging out places like here didn't like flash, but the general population had no problems with it until Steve Jobs did his best to kill it. Even then, people not on iPods/Pads/Phones didn't seem to have any problems with it. AFIK, the fast majority of people still installed it years later.
- It wasn't visually scalable. (Today we say "responsive", mostly, but that's too easy to confuse.)
- It didn't integrate with HTML and CSS in any interesting way other than sitting there in the middle.
- Performance was mediocre to terrible.
- A rent-seeking company was in charge of it.
As you say, eventually JS supplanted it.
Regarding integration, some text elements featured basic HTML capabilities. Nothing terrific, but you could extend on this. (And, of course, XML parsing, but this is another story.) Also, later Flash Player applications (Air) featured a full-fledged WebKit element for rendering web views. That said, it was good thing that Flash had eventually to go, and, at times, the state of the web today is pretty reminding of this.
For the user, flash applets where super easy to block in general and to whitelist on pages where you wanted to use that particular flash application. Basically the same was true with Java. And for a certain extend JavaScript -- until the ugly DHTML menus arised and websites stopped to be usable without JavaScript.
Nowadays there are only two options: Either you block JavaScript --- and percieve a 1995's web view, in general --- or you let it run on your browser, having tons of programs running which you probably don't want (ads, tracking, that particular application that replaces flash).
Unfortunately it's not true. Zero day exploits happen all the time, even the recent Intel CPU vulnerabilities were exploitable via JavaScript. Morevever, some harmful effects of arbitrary code execution cannot be mitigated (like the drained battery or user tracking), that's why I have recently adopted a view that code execution on web pages is just a Bad Idea and my non-work browsers are configured with JS turned completely off.
This gives me nearly 2 full days of battery life on my phone and I'm less worried about privacy/security aspects of visiting random web sites.
Unfortunately, even within the last year, I'm noticing that more and more web sites simply serve me a blank screen without JS enabled. This forces me to stop using such sites, which is gradually reducing the size of the usable web for me. My only hope is for a new trendy server-side rendering fad to come along and rescue the Internet :)
Now in both cases, you can just make your app a fullscreen canvas or opengl/metal viewport or whatever and manually render everything to that while manually handling user input, but you lose interactivity, accessibility, extensibility, etc.
Mostly this already works, I can open a standard file dialog, or copy data into or out of the system-wide clipboard. If there are any APIs for accessibility missing (e.g. for hooking into screen-readers), I would consider that a bug on that particular platform. There's no reason that applications which use the system UIs should behave any different from applications using custom UIs.
There are so many parts that go into the accessibility of an element, handling tab index, handling keyboard input, handling screenreaders, spoken voice prompting, etc, that a custom solution usually ends up being detrimental to the user's experience.
That being said - I agree with your ideal, and I don't think it's far off. HTML as a view engine combined with WASM as a cross-platform runtime can enable truly cross-platform, industry-standard native applications. I think it's only a matter of time until Electron apps morph into cross-platform native apps running off of a thin WASM layer. Once those are available, then the OS vendors will have a huge competitive advantage if they develop fast native WASM runtimes.
It isn't used because it's just not how the suppliers of content nor consumers of the web want to use the web.
If they want a full featured app, they use it. Even with super fast speeds, latency and minimal startup time still make the browser unattractive for this.
Web users and content providers want linkable documents.
I'd argue that the modern browser stack is so good that we see installed apps adopting html/css/js for the presentation layer.
Of course this goes hand in hand with an instant start (no dreaded splash screens please), and not having to download gigabytes upon gigabytes of data upfront.
Modern web apps might be bad at this, and browser engines might be bloated, but native apps aren't any better (even heavy web pages still load many times faster than - for instance - starting Visual Studio or Photoshop).
Once I "install" an application, for example libreoffice:
- It works even if I do not have a working Internet connection (or back in the day, even if I had removed the original media from the drive);
- It works even if the original is gone.
That is, by "installing" an application, I gain a permanent, offline, working copy of it.
On the other hand, PWAs (Progressive Web Apps) also work in offline mode without a "traditional" installation step.
Please stop saying this as if it is in any way acceptable. Some parts of the computing world work like this, but this is not, nor should it ever be, the new normal.
You can still definitely use your computer without resorting to such licensed crapware.
"Traditional" applications that are subscription-only are only partially installed, if their full functionality requires always-on connectivity.
Stay offline for 30 days (iirc) and try to play the games you paid for.
The maximum speed of moving data from one physical place to another, moving data from the hard drive to the motherboard and the ram to the cpu/cache is faster than from the internet to a computer. To he speed of light is still noticably slow when you're making round trips to get data.
The other issue is configuration, even if automated, software needs to make decisions about how to deal with different hardware and system differences. This takes time to bootstrap after initial load increase time to usuability or it can be done on the fly slowing down the interactions.
I agree with you that the URL is the most important feature of the web. Without it, you could just as well deploy native apps because it wouldn't really make that much of a difference.
Without javascript and a heavy client side, I wouldn't have a job today since the application I build is simply not possible to create with just html+css.
Sure there are many web pages that don't need to be a SPA, but a lot of other webpages do need it. I think an increasing amount of webpages are not simply text documents but we can easily see a move from traditional applications to web applications.
It's obvious why, it is truly a "write once, run everywhere" scenario, it's easy to scale on many different devices and there is little to no advantages to write a native app in most circumstances.
The document web has already been done, just use wordpress or whatever framework to create those sites but the new exciting web for me is the more interactive web where we can seriously move heavy apps into the browser.
What's happening now is like trying to force ftp to show documents, with markup, and forms, and so forth when it's just supposed to transfer data.
The web was never intended to only ever be static, nor is scripting in the browser somehow a corruption or aberration of the web's original purpose. If anything, the web should have been a lot more programmable[1] than it turned out to be.
[0]https://www.w3.org/TR/2018/SPSD-html32-20180315/#script
[1]https://eager.io/blog/a-brief-history-of-weird-scripting-lan...
I am content with what we got and are happy about it. I think it works pretty great after all.
I use linux as well and I have yet to find a webpage that doesn't work with Firefox and Brave.
Maybe you shouldn't block javascript and instead block trackers and ads. There are a lot of tools to do that like uBlock Origin, pi-hole, privacy badger etc.
Javascript is used by pretty much all websites today to do mostly other stuff than tracking. Why are you blocking it if I may ask?
Also, I am very curious (I really am), what websites do you visit daily? I'm sure at least some of them are depending on javascript and couldn't be solved with html+css alone?
I use uBlock Origin at home. I use NoScript at work. I like it because it blocks ads and because it does break much of the web. I don't want auto-playing videos, I don't want an enhanced experience, I just want to find the information I'm looking for. If the website I go to won't show me anything even after enabling the main domain and a CDN, then I move on to the next choice. Enabling js on the main domain usually makes menus and such work. The rest seems to be ad-related, from what I can tell.
There are a handful of sites where I really am looking for an enhanced experience. Mainly my banking sites, sites I frequent for shopping, and some forums. Most other places I visit I'm happy that the site is mostly broken as long as I can see what I went there to find. In many cases, I'd be happier with a 90's era gray page with text and pictures. But then I'm old.
If you want, I can tell you some of the apps I use. I use Slack, Telegram, Visual Studio Code, Discord, Tidal (as a PWA) and a bunch of other web apps.
Some apps I really do require to be fancy, like fastmail. Using it with normal forms and no ajax would suck imo.
I am myself also building an app where we heavily rely on a map and rendering stuff upon it. It is very interactive, and it would not be possible (at least to the extent that we want to deliver it) to make it without javascript.
I also think most of the "desktop" apps I heavily use wouldn't really exist for linux if electron didn't exist which is kind of sad.
But now they do and they work wonders, so good I use them every day. You can barely tell that Discord or Visual Studio Code is web apps nowadays since they work so damn good, better than most hacky open source alternatives that exist for linux.
I think it's cool that you and some other people can have a functional user experience without javascript but for me it's simply not possible if I want to enjoy all the benefits that running with javascript enables me.
I actually rather use web apps, progressive web apps etc than install a native app that can ruin my entire computer. They are equally fast nowadays, web apps often get updates a lot faster and it isn't a risk to update the app. Just refresh the app and everything is safe and sound, especially with PWAs.
Just check this screenshot, it even looks native (and hardware keys work fine):
That sounds like it would be great if it were even possible. What about the million times that someone relies on ajax.googleapis.com and forces me to either allow it or walk away? Am I really supposed to believe that Google isn't logging my visit, each and every time I get a script from there to restore the functionality to or even put text into someone's page?
And then, what will we do about any original domain owners (hypothetically) cooperating with them by hosting such scripts in order to go under the uBlock radar and keep getting paid? What about sites that intentionally host and run whatever malicious scripts themselves? Right now it is merely convenient that we can often choose (correctly) to run or block based on URLs alone, and I don't expect that to last.
I just admitted to everyone that if there are blocking mechanisms which work around other bits besides URLs, I haven't heard of them. I just admitted to myself that I have no real reason to think that it's even enough, and I might be just punishing myself and making everything needlessly difficult-- for my own little privacy theater.
I suppose that unless uBlock or Pi-Hole can (someday) analyze every script in every page (hopefully in sub-second time), and determine whether it is cosmetic or mandatory or exploitative or malicious based on nothing but the code and the context, we lose anyway.
I think privacy is important, but to a certain extent. I think I am pretty tin foiled when it comes to integrity. I don't use any social networks, I don't publish my images and location to everyone. I use services that encrypt my information like SpiderOak for backups and I use encryption on my disk.
That said, some things ought to be allowed like loading a crappy jquery file from google cdn. Sure they will log that visit, but comon that is just like visiting a GCP site. The same amount of logs can be made from that.
I think you provide some valid points, but I think your fears are a bit too far fetched. I also fear Google and Facebook. I use DuckDuckGo as my main search engine and I try to not use Google products. I don't think you can do so much more than that to be honest.
There are very few RCEs now on modern browser (they still exist[0,1], though). The main threat is phishing, because users are gullible (and should be educated).
[0] https://www.mozilla.org/en-US/security/advisories/mfsa2019-1...
Won’t make them “useless”, maybe inconvenient for non-security minded individuals.
As others have pointed out, that's hardly a contrary opinion.
To quote Roy Fielding's Dissertation (p 109).
"Uniform Resource Identifiers (URI) are both the simplest element of the Web architecture and the most important."
https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding...
Opinions are almost universally contrary, despite the knowledge that the URL can be a tool. How often is it put forth that the URL is meant to be indempotent or the URL is supposed to be mapped to another routing system etc. The number of commercial sites where the URL is a field you are meant to manipulate (other than say search engines and even they don't point it out for you) is so small as to be significant.
If that had ended up as the dominant paradigm... Google (or a search engine like it) wouldn't exist.
A URLs-only web, one that sees the browser as nothing more than The VM That Lived™, is actually the more limited vision.
I don't mind Electron too much, current (for 5+ years or so) desktops support running a handful of them without issue (provided at least 8gb ram).
I think that once a few quirks are worked out, we may well see a "one runtime to rule them all" with WebAssembly. WASM + Sandboxed FS + Canvas/WebGL could go a VERY long way towards a lot of application use cases. There's been a lot of work underway for this type of thing and it could be very interesting to say the least. I do think we'll wind up with an XML based markup for UI over the top, maybe a ReactNative-like syntax for WebAssembly+Canvas or WebGL would be very cool.
Apple is going down this route with code signing and granular permissions with Macintosh applications that don’t have to be part of the Mac App Store and there is still whining from geeks that this is leading to a walled garden, even though there are approved ways to work around it.
It's the same with Electron apps by the way, those wouldn't exist if operating systems would come with cross-platform UI frameworks that are actually better than the unholy mix of HTML+CSS+JS. But Microsoft, Apple etc... had decades to get their act together without delivering.
One of the problems with Electron is that it’s the same interface everywhere. I don’t want the same interface on a Mac that I have on Windows.
They haven't done it because it doesn't bring any benefits to the greedy corps, and apple is the worst offender with their dumbed down, shackled os
So how is MacOS - a real certified Unix OS “dumbed down”?
Edit: Corrected Link
https://www.cnet.com/news/fortnites-battle-royale-with-andro...
https://www.cnet.com/news/fortnites-battle-royale-with-andro...
A storm of security issues is closing in on the Android version of Fortnite. And it isn't likely to pass anytime soon.
Developer Epic Games just fixed a security flaw with Fortnite's installer for Android devices, but researchers are expecting a flurry of problems for the online game as it gets more popular on Android.
That's because Fortnite isn't available through Google's Play Store. Epic instead chose an unorthodox -- and more dangerous -- route for the game's fans. Rather than download it through the official Google app store, players need to download the game and "sideload" the app on their Android devices instead.
All the HTML+CSS+JS stuff only makes browsers difficult to secure, and also causes bloat and performance issues when they are not needed.
Furthermore, all these hairy web specifications cause compatibility issues, and are a barrier to entry for new browser makers.
If people want HTML or CSS or JS, then they should implement these inside the sandbox. In practice, this would mean that developers would simply include one of the standard libs for rendering HTML, etc., and these standard libraries can be cached by the browser, so their use does not cause performance/bandwidth penalties.
Here's how you do it: create the new platform and its spec. Include an open 'document rendering engine' to replace that portion of the web. For backwards compatibility, go ahead and port a web browser to the new platform. For forwards compatibility, port the new platform to the current web.
You are completely free to write and launch a new app that does this today. Just don't try and shoehorn it into my web browser.
It's "the sandboxed, browser agnostic web".
Windows 10 comes with a VM-based application sandbox. But it's meant for powerusers and has to be explicitly enabled
https://www.windowscentral.com/how-use-windows-sandbox-windo...
I think the W3C are a big part of why the web works so well cross-platform... even though the web was supposed to be "so much more". It's quite hard to imagine a similar kind of body for cross-platform UI frameworks.
It is not perfect, but it feels a lot more native on every platform than virtually any web or electron app I have seen (including predictable keyboard shortcuts).
It would be nice if operating systems would be exactly that, but for some reason "commercial" OS vendors are not able or willing to provide a safe "native" sandbox completely uncoupled from curated app stores.
The ability of a browser to be a document viewer with a very limited layout system should be implemented in an optional layer on top of a bare bones browser.
Again, this should all be provided by the underlying operating systems (click an URL and instantly run cross-platform applications in a safe sandbox), but for some reason we didn't get that. It's the same with Electron apps by the way, those wouldn't exist if operating systems would come with cross-platform UI frameworks that are actually better than the unholy mix of HTML+CSS+JS. But Microsoft, Apple etc... had decades to get their act together without delivering.