Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> The web stack (html/css/js/http) is one of the most impressive feats of invention by humanity.

Yes and no.

The "no" part comes from people trying to twist a system designed for displaying static text into an application platform. And as an application platform it sucks. It's one of the most inefficient, slow, resource hungry app platforms that humanity has ever devised.

As a free somewhat open cross-platform means for information exchange, it really is unparalled.



>It's one of the most inefficient, slow, resource hungry app platforms that humanity has ever devised.

Is it? JavaScript interpreters are crazy fast, almost comparable to compiled languages. The layout engines are powerful and efficient. They support extremely-optimized networking protocols and media formats.

It's not (currently) a great platform for high-poly 3D rendering and such, but who knows what the future holds with wasm and WebGPU.

Browsers do use a lot of memory, but so did Java, Flash, Shockwave, Silverlight, etc.


> Is it?

It is. None of what you write is either fast or efficient. Especially not the layout engine that does a re-layout and a re-paint as soon as you look at it sideways

I always say when people talk about efficiency: There's a reason you can't animate height: auto or a list item efficiently without hacks. As is the reason why opacity changes are outright banned on lower-end devices like TVs.

The limitations of this system designed to display static text are such that a non-issue like quickly displaying scrolling text becomes a problem: https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...


A large part of the issue is the modern Javascript ecosystem too. The browser isn't the most efficient way to build apps, sure, but using a virtual DOM adds a whole extra layer of performance issues.


> but using a virtual DOM adds a whole extra layer of performance issues.

You mean the fastest libraries like ivi use Virtual DOM ;) : https://twitter.com/RyanCarniato/status/1636120238638137344


The "no" part comes from people trying to twist a system designed for displaying static text into an application platform.

The original web memo by Tim Berners-Lee defined "a document" as text only content that could be displayed on a 240x80 character display. Images were defined as an optional extra few people would be able to access. I'm going to guess you want a web that does a bit more than that.

In which case.. Tim Berners-Lee's memo suggests "Live Links". His proposal was that the web should have "documents" that are generated per request aka serverside rendering. He went further and suggested "If one sacrifices portability, it is possible so make following a link fire up a special application, so that diagnostic programs, for example, could be linked directly into the maintenance guide." To me that sounds a lot like a clientside app. At the time (1989) I imagine he meant that a link in a page would execute a local app, but it turns out we just found a different (better?) approach.

The memo is really interesting - https://www.w3.org/History/1989/proposal.html - TBL was incredibly insightful.


The original baby was only designed to live inside and come out of it's mothers womb. It was only supposed to drink milk and cry.

How dare it learn how to talk, walk eat solid foods and grow bigger!


> How dare it learn how to talk, walk eat solid foods and grow bigger!

For sure. That ship sailed 25 years ago, when XMLHTTPRequest was invented.


It does provide a cross-platform application development stack with easy to use networking and deployment capabilities while being sandboxed and requiring little to no admin on the user terminal.

There was no real equivalent to this before. In corporate environments, this was often the Java stack that was used and it was often a really painful experience.

PWAs are the same for Mobile, the current experience of developing mobile apps using the native SDKs is really subpar and it is expensive. PWAs will become the default for mobile apps because, in most cases, there's no reason to go through the pain and cost of creating native mobile apps.


> PWAs will become the default for mobile apps because, in most cases, there's no reason to go through the pain and cost of creating native mobile apps.

Unless you need, you know, actual performance, fast animations or even things like proper controls which the web has none of.


It _sucks_ compared to some other non existent platform. The adoption both by users and developers seems to indicate it is the best thing we have produced for this so far.


> It _sucks_ compared to some other non existent platform.

Those platforms exist: desktop and mobile. People are so enamoured with the web and/or have no experience outside the web, and so don't know how insanely more performant almost literally everything outside the web is.


Sorry, but no. You‘re wrong. „Desktop“ isn‘t a platform, it‘s a loose term for native applications running directly on your OS. „Desktop“ is extremely fragmented: Windows, MacOS, Linux. The latter is fragmented as well.

I will gladly take every disadvantage of the web to deliver my products to every platform. The alternative is not shipping to MacOS and Linux systems.


But those platforms _suck_ in terms of time to market/time to add features in a cross platform way. That's the terms that they lose to the web on.


I have an M2 with lots-o-RAM. Not everything needs to be "performant".

I'm old enough to remember the same arguments being made when people started using C rather than ASM.


> Not everything needs to be "performant".

With that attitude you get Microsoft officially advertising their new Teams version that takes 9 seconds to show less than 1kb of text (3 seconds just to show the splashscreen).

Yes, we are running what essentially amounts to supercomputers. Why is it then that Slack still requires 20% CPU to show an animated emoji? Or that Matrix spikes to 60% CPU when scrolling through a largely empty channel? Or...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: