Hacker News Reader

Comment by flohofwoe | Hacker News Reader

Unpopular opinion... but I think this is a too limited view of the web. My contrary opinion is that the actually important feature of the web is the URL, and the important feature of the browser is that it provides a sandboxed platform for running untrusted code without a builtin "walled garden moral police".

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.

View on HN

I'm inclined to disagree, but I guess the real problem is that webpages on the internet are being forced to serve both purposes.

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.

I feel like this gives an overly rosy picture of the past—

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 :)

Absolutely agree with this. The Internet-as-appplication-platform has never been better, from a developer's perspective.

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.

The "notifications" request REALLY pisses me off to no end. A simple "Subscribe" button (if the notifications API is present) would be enough to trigger the request. I wish I could just turn it off all around in the browser... Looking now... Nope, at least in chrome, cannot just disable the feature.

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).

Funny, I think you actually pinned that interpretation yourself - the post was meant to discuss use cases of the web today and doesn't mention the past at all! Regardless, I see your points, but I'd rather compare today to an idealized future and discuss how we'd prefer it to be.

Paradigm 1's security/privacy (WebRTC and webttorrent ip leaking, canvas finger printing) are being compromised in sake of striving for fancy stuff in Paradigm 2.

Browser vendors (Firefox, Chrome, Brave) please get your act together to prevent https://nothingprivate.ml

For what its worth, I just tried this on Firefox 67.0.4 and it didn't work. It couldn't find the name I typed after I loaded from a private window.

It didn't work for my friend when done via Chrome on Android, and when I tried it, i got someone else's name in incognito

I think what the author is saying is that paradigm 2 is built _on top of_ paradigm 1 and if you can't do #1 right, then by definition _neither_ can be right. It's astounding the number of interview candidates who are super-fluent in JS but can't tell you to save their lives why it's a bad idea to put a click handler on a div. React will die (It's already started to) and we'll migrate back to the actual Web at some point and for my money it can't happen fast enough.

> It's astounding the number of interview candidates who are super-fluent in JS but can't tell you to save their lives why it's a bad idea to put a click handler on a div.

Go on?

Using a button here would be more appropriate for a few reasons:

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.

Putting a click element on a div is transparent to accessibility systems. And no, it isn't possible to consider an element with an onclick the same as a button, because events bubble, which means the element with the event listener isn't necessarily the element being watched for a click. IIRC there even used to be a "good practice" where people would attach a single click handler at the root and use it to dispatch events based on the `event.target` instead of attaching a separate handler to each target.

React does that, they call it synthetic events, but it's hidden from the developer. In jQuery it used to be called event delegation, made it easy to handle events on dynamic elements without the need to constantly attach/detach handlers.

Because the user can't hover over it and see where the link goes. Because the click handler represents a Javascript program that has to be downloaded. Because it can't be used with Javascript turned off -- which is increasingly necessary these days since ad networks abuse Javascript.

But mostly because it's usually unnecessary and smacks of laziness on the developer's part.

Because you've literally just described what a <button> is.

That would mean that anything that responds to click events is a button. From your experience of using UIs, you can probably think of many more UI elements that respond to clicks and are not buttons

> React will die

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.

> React will die (It's already started to)

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?

Nothing about React stops you from correctly putting click handlers on buttons.

Well, the behavior is a bit awkward, and older browsers don't even work right. Of course, some older browsers that shall not be named, you couldn't disable certain styling attributes of buttons, which means an anchor may have been more appropriate back then.

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.

I’ll bite: Why is it bad to put a click handler on a div? Because we’re losing the semantic content of the markup?

Because there's already an element for that. Putting a click handler on a div is a hack.

In a clean (from scratch) dev situation, when would it make sense to use the div option?

People have been putting event listeners on div long before any framework was around. Tons of libraries and documentation show how to attach a click handler to a div (ex: https://api.jquery.com/click/). I can think of some cases... maybe the div is contenteditable and I want to trigger some analytics. Maybe I want to listen to all the children of a container rather than apply expensive listeners all over. Do you put button tags around all your tooltips? You might end up making your HTML look right, but now you are jumping through hoops to make it not look like a button. As with all things, it's naive to say "never do something."

For one, it won't play nice with accessibility helpers... screen readers, keyboard interaction, etc.

While I agree semantically use of <button> can be clearer, clickable divs can still play largely fine with most accessibility technologies if ARIA attributes are used.

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...

Number of times I remember seeing an an app using `<div onclick>` with proper aria attributes: 0.

It's often a legal or contractual requirement when selling software to public bodies in many countries, so I've seen it used a lot. Mileage may vary in other markets.

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.

Reinventing the wheel is bad

Don't we kind of have Paradigm 2 on our smartphones and tablets? It's not perfect but it's something.

I agree it's better in some ways than the desktop programs ("apps") situation

We should replace DNS with DHT, then we can have content addressable (or otherwise verified) apps sideloaded or loaded in chunks from anywhere like in BitTorrent or Dat.

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 :-)

Have you seen https://github.com/staltz/dat-installer ?

It can be used to update itself, too :-)

I'm not quite sure how this relates to the original article, but:

> 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.)

> 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.

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.

That's not a marginal cost of production, though. It costs almost the same to fix a bug if you have one user or a billion users.

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.

The zero mainly comes from the ability to scale for free. Sure it costs a few million bucks to maintain Linux (or whatever), but when divided by billions of copies the per unit cost becomes effectively zero.

> My contrary opinion is that the actually important feature of the web is the URL, and the important feature of the browser is that it provides a sandboxed platform for running untrusted code without a builtin "walled garden moral police".

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.

Flash had several problems that should have been addressed differently. Among others:

- 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).

Those were all problems but none of them had any real bearing on the general population avoiding it for general sites.

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).

> The thing is, most people don't want a blank canvas to go nuts with for the general use case.

Are you kidding me? Flash was an absurdly popular platform. Careers were launched on Newgrounds!

> 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.

> very few sites in the grand scheme of things were solely rendered with Flash

...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.

> 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.

but most sites had some flash on their site. just like the previous person said: flash was never intended to replace the website entirely - flash was intended to supplement it. and that need went away with html5/css3, which is why it was deprecated as the insecure behemoth it was.

Yet people did this all the time (2advanced, HomestarRunner, etc) because the web as an application (a product) was served particularly well by an application platform.

But for every 2advanced studios there were tens of thousands of people not using Flash as their entire site.

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.

> the general population avoiding it for general sites

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.

The case against Flash was, I think, not so much about what it was, but everything around it.

- 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.

JS didn't suplanted it from day to night. It was Steve Jobs who killed Flash, not letting Adobe from conquer their new iOS platform. They tried it so hard, even on Android back then, but they failed to deliver something solid. Eventually, both Google and Apple released their SDKs to develop apps, way more solid and faster than running a Adobe Flash player layer on top of the OS. This article shows the jump on technologies, from the CSS perspective http://minid.net/2019/04/07/the-css-utilitarian-methodology/

Flash was already mostly dead by the time the iphone came. Adobe was not investing much into it and it was mainly being used to show videos.

I don't think so. Flash was strong in three scenarios: corporate websites, games and advertising. The agency I worked for made 95% of its revenue from Flash work, and most of the agencies in Barcelona, Madrid did the same.

The case against Flash was (apart from the horrible security issues) mostly about stacked libraries, including Adobe's own UI library. You could code applications with remarkable performance and small footprint using the pure Flash Player target (neither Flash nor Flex, but pure AS3).

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.

The general web loved Flash for cases where you needed an application rather than a document. It wasn't appropriate for everything, and it was unfortunately very difficult to mix Flash with general HTML, but in many ways it was better than today's web for both creators and end users.

Second that.

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).

The 1995 view is superior. It loads fast, doesn't hog CPU, never does anything unexpected, and has limited tracking capacity. I cringe whenever I browse without NoScript. If your pages can't render in my sandbox I just go somewhere more sensible.

It's superior only until you want to do something that does actually need JS - sometimes "go somewhere more sensible" isn't an option when you actually need to do something specific (e.g. buy an Amtrak ticket).

> the browser is that it provides a sandboxed platform for running untrusted code

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 :)

I'm aware of at least one project to do that with Ember

https://ember-fastboot.com/#how-does-it-work-

The reason browsers use the document as a building block is to provide a consistent and accessible UI to everyone using your site. This is the exact same thing that Windows, Apple, Android, etc do with their UI frameworks that they recommend you use. It also provides the ability for websites to safely degrade on older browsers because unknown elements can still be rendered in the correct hierarchy.

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.

Platforms should provide the necessary low-level APIs to hook into their accessibility- etc... features without having to use their high-level UI frameworks, and they should provide lower-level services like high-quality text rendering.

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's no way a platform can provide accessibility for arbitrary pixels you throw onto a screen. You could, by yourself, using the low-level accessibility APIs, but you likely won't since it's a lot of work. Hence the push for using platform UI components: they inform the framework of your intention, and in return this information helps it provide you with better accessibility.

There are ARIA attributes which let you customize the advertised meaning/intent of an element, but there is nothing to, say, mark that a particular location on the page should be considered a button. As far as I'm aware, this matches how Android, Windows, iOS, etc work.

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.

I think you need to take into context the history of browsers vs. operating systems... operating systems were always a platform, while browsers started as consumers of an electronic document standard.

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.

No one's delivered? There were and are plenty of platforms for full apps on the web. All of them require: loading each time or elevated privileges above the normal browser. This is not the reason they haven't taken off. Security isn't the reason either.

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.

IMHO the word "installed app" shouldn't even exist. What's the use of "installing" an application these days?

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).

> What's the use of "installing" an application these days?

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.

Most of this isn't a given anymore with software vendors going subscription-only like Adobe's Creative Cloud.

On the other hand, PWAs (Progressive Web Apps) also work in offline mode without a "traditional" installation step.

Which is a problem that needs to be pushed back against. SaaS is a step backwards in our relationship with our machines.

> Most of this isn't a given anymore with software vendors going subscription-only like Adobe's Creative Cloud.

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.

Progressive Web Apps that work in offline mode are still installed when first accessed through the browser; they just don't need to go through the "traditional" method (installer, app store).

"Traditional" applications that are subscription-only are only partially installed, if their full functionality requires always-on connectivity.

Not even Steam works like that.

Stay offline for 30 days (iirc) and try to play the games you paid for.

Well, Steam is a DRMed game lending platform; content is only stored off-line because there's no practical way for them to do otherwise. If they could get away with streaming games from their servers, they'd happily do it.

There are many things one could blame Steam for, but AFAIK this limitation has been removed years ago.

What's the issue? There's two that are unavoidable.

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 don't think that is an unpopular opinion, since I am of the same.

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 we need, in my opinion, is a new protocol. Leave http(s) for documents and make a new protocol designed from the ground up for interactive applications. That solves the problem of trying to shove an application into a document viewing sub-system and should allow for more creativity and efficiency, depending on what this new protocol turns out to be.

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 possibility for HTML documents to support inline scripting was considered even prior to HTML 4[0]. The script tag itself is decades old now, it's supposed to be there and it's as legitimate an element as any other.

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...

Maybe that would make it better, maybe not. It's hard to get everyone on the same page working together on a platform that noone ownes. If it was easy, there would have been several protocols in use already.

I am content with what we got and are happy about it. I think it works pretty great after all.

I'm not so happy with it, since I'm tired of trying to figure out which domains to allow javascript from when practically every page has a list of a dozen or more. I'm tired of trying to run pages that don't work with any of the browsers I have access to on linux, despite html being a standard. The whole paradigm seems broken to me. It just feels like a monumental kludge.

> any of the browsers I have access to on linux

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've had a few sites that wouldn't work for me without booting up my windows laptop and running edge. One of them is the place I make car payments.

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.

Ok cool to hear your story, thanks for sharing it.

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):

https://i.imgur.com/OeOaMPt.png

> [not] block javascript and instead block trackers and ads

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.

Sure but what about sites that are hosted on the GCP? Google will surely log that visit as well and there is no easy way for you to tell.

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.

Don't we already have that with TCP and/or UDP ?

Isn't it pretty hacky to use a Web browser for that instead of a dedicated virtual machine ?

For what exactly?

That view of the browser is what I want to have. It blows my mind that we still have to tell people “don’t click links in your email” because it’s still possible for something terrible to happen if they do.

> for something terrible to happen if they [click links in their email].

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...

[1] https://objective-see.com/blog/blog_0x43.html

And: https://news.ycombinator.com/item?id=20283922

You don't need to exploit a browser when Adobe still can't fix the holes in Reader and corporate users are still heavily dependent on Outlook.

The real question is why should links in an email message be clickable? Restricting email messages to plain text would make it much more difficult for attacks like that to succeed.

URLs are plain text... Can also easily be clickable, depending on your e-mail software.

They are, but some email clients will display text that doesn't match the original URL. Hence the advice to hover the mouse pointer over the link and tread the original URL text that way.

If you use plain text mode they won't be able to. Hence the advice to disable HTML in e-mails.

... and make emails completely useless.

Ever head of copy & paste?

Won’t make them “useless”, maybe inconvenient for non-security minded individuals.

if You make emails inconvenient for non-security minded people by removing something as important as links, you will push mainstream users to move away of the medium (because other way to communicate will definitely support links and not force people to copy paste), which doesn’t help or solve anything.

> My contrary opinion is that the actually important feature of the web is the URL,

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...

> As others have pointed out, that's hardly a contrary opinion.

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.

Imagine that in the 90s, a "URLs only" web took off -- not too hard to envision, really, considering how many sites there were that were giant slabs of sliced images with hotspots for links between, or how Sun was pushing the vision of URLs essentially indexing Java client apps.

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.

ChromeOS is pretty close to what you are talking about... yeah, it's still an App store, but IIRC, you can add an "app" from any URL. It would be nice to see a more open version of what Adobe AIR tried to do, but with node/electron at the core. Unfortunately $VERSIONS makes it difficult to support well with a common runtime, but would still be well worth seeing.

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.

I'm sorry but you have to be special kind of delusional to think apple is doing something to move away from walled garden lol.

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

Did you read the post or are you just responding to your own prejudices? The parent post said that OS vendors should have sandboxes without an App Store. Isn’t Apple doing exactly that with the Macintosh? The Mac App Store is optional and despite all of the conspiracies, it was introduced over 8 years ago and you can release an application on the Mac just as easily today as you could then.

So how is MacOS - a real certified Unix OS “dumbed down”?

Well, I remember people warning that having an official Android Market would make distributing via side loading not a viable option... Lo and behold, these days Fortnite gets criticized for being delivered via an .apk because it's "unsafe" !

It was unsafe.

Edit: Corrected Link

https://www.cnet.com/news/fortnites-battle-royale-with-andro...

Something that has nothing to do with sideloading or even Android?

Wrong link above:

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.

Couldn't agree more, html should be just one implementation amongst others. It's good for documents, it's lousy for richer experiences. The rich experience shouldn't be built on top of HTML, it should live next to it.

Indeed, a browser should be just a sandbox, nothing more.

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.

I agree. If we want an application platform, let's have something designed first and foremost to be an application platform instead of the garbage fire we've bolted to the skeleton of HTML.

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.

Ok, but that isn't "the 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.

> Ok, but that isn't "the web."

It's "the sandboxed, browser agnostic web".

I'm not sure that it can be called "the Web" if it doesn't have directly accessible pages linked by hypertext, instead having a single page/app for instance (even if it runs on the top of the HyperText Protocol...) We're getting into non-Web Internet territory here...

The web browser _is_ the "safe" sandbox. Your dream of competing OS vendors coming together to build a standard UI platform makes no sense whatsoever. The current state of web apps is mostly a factor of developers being willing to do any amount of work whatsoever to avoid having to learn how to do things differently than they already know (ie, writing good native apps for multiple platforms, which would require learning multiple frameworks, so instead they create their own abstracted framework within a sandbox.

> 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.

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...

This. absolutely this! We didn't get the crossplatform UI framework we needed, we got the one we deserved. SwiftUI looks amazing - but again - apple only. React looked promising, but mainly for desktop, and it's not without its own issues.

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.

If I remember Xamarin can be used to target all existing platforms, even using native looks and feel. In practice I don’t think I’ve seen it in the wild. Maybe it’s being used by Microsoft for crossplatform applications? (E.g: word, excel, OneNote, etc)

What makes React inherently un-mobile except the fact that all browsers have a touch timeout thus making UI seemingly slower?

Don’t know if it’s unmobile per se. But it’s heavy, JS wise, tends to promote SPAs, and can be quite tough to get to play well with a hybrid. The react team seems to put their effort in React Native. And that might the only framework I’d never ever ever “touch” again - pun intended:) We do use react for some mobile stuff, the issue seams to be that you still need a lot of other stuff and your app/UX still feels a bit like a 2nd class citizen

Have you ever written anything in Qt?

I've recently been using it and I am very disappointed. Some tasks that should be totally trivial are incredibly hard to get right and require platform specific solutions. Nothing unsolvable, but I was expecting a much more straightforward experience from a product that has been promoted as the cross platform toolkit since the 90s.

I co-developed a Qt C++ app of ~40,000 lines. I think the amount of platform-specific code was at most a couple of pages (handling macOS' behavior to keep an app alive when all its windows are closed).

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).

I don't have a large amount of experience but when I worked with Qt I was blown away with how friendly and cross-platform it all was. It's pretty close to write once, compile to anything.

I have not. I’ve looked at it quite a bit, and it looks interesting.

Apple planned to use web apps for iOS but developers wanted bare metal performance, and users also want bare metal performance. So dont blame the platforms, blame users and developers. As a Linux user you can however restrict what the app can do using Apparmor.

Well, beside formatting, html is <a href="...">

Reply on news.ycombinator.com