It's time to kill the web app - <AUTHOR> https://blog.plan99.net/its-time-to-kill-the-web-974a9fe80c89 <comment><USER3> I find this unconvincing.

Every negative thing said about the web is true of every other platform, so far. It just seems to ignore how bad software has always been (on average).

"Web development is slowly reinventing the 1990's."

The 90s were slowly reinventing UNIX and stuff invented at Bell Labs.

"Web apps are impossible to secure."

Programs in the 90s were written in C and C++. C is impossible to secure. C++ is impossible to secure.

"Buffers that don't specify their length"

Is this really a common problem in web apps? Most web apps are built in languages that don't have buffer overrun problems. There are many classes of security bug to be found in web apps, some unique to web apps...I just don't think this is one of them. This was a common problem in those C/C++ programs from the 90s the author is seemingly pretty fond of. Not so much web apps built in PHP/JavaScript/Python/Ruby/Perl/whatever.

<comment><USER4> This might be the biggest dichotomy I've yet seen on HN. An opinion piece voted all the way to the top of the front page (with a clickbaity title, might I add), yet the top comment soundly debunks the article's arguments.

Yeah, this is why everybody clicks on the comments link first.

<comment><USER5> To somewhat counter all the negative comments here - I read this article and agree pretty much 100% with every sentence in it. There are probably more people who agree with the post - hence the upvotes.

<comment><USER6> Yes, I agreed with the entire article as well. I didn't see anything controversial or exaggerated about it.

Edit: Ok, maybe I could have predicted that lines like "HTML 5 is a plague on our industry" would ruffle some feathers. I guess I like a little snark in my criticism.

</comment></comment></comment></comment><comment><USER7> I rather think, It's time, to completley ignore sensationalistic rant's like this one.

First of, killing a technology does not solve anything. It just means less options. So do propose your better solution (and build it) - then we can talk about killing the current thing.

But the way it is today, the web works.

Definitely not flawless and in large parts really ugly (just browsing with open dev-tools is horrifying, when you see all the errors and warnings thrown at you) - but it is big and reduntant enough, that you can mostly choose only the nice parts.

XMLHttpRequest is ugly? (I allways thought so) Well, there are WebSockets now.

Javascript lacks typesupport etc? - Use Typescript

The whole DOM and *script languages in general are ugly? Skip it all and use only WebGL and Wasm.

And your app will still run allmost everywhere.

That's the power of the web - that's why it became so important. It just works.

And it is very easy to start doing it ... so many people did this, who do not have a CS background. And obviously they made horrible things from an academic point of view. But things still kind of worked for them.

And security ... well, so far I have not yet heard of a save language/OS/Plattform where people can work productivly without years of studying the theoretic backgrounds.

So in general yes, I am very open for better designed alternatives. In fact I am looking for one since I started web-developement, but not so much for angry hyperbolic rants like this one. They are not helpful.

<comment><USER8> > But the way it is today, the web works.

Does it really? What would you hold up as an example of a powerful web app with significant usage?

All the major players these days (like Facebook) get the overwhelming majority of their traffic through their native mobile app, not through their web app. The web's primary stronghold is in publishing platforms (news, articles, etc...), which are not really what you'd call "apps" and indeed they are the one thing the web was actually built for and good at - static(-ish) content.

<comment><USER7> "All the major players these days (like Facebook) get the overwhelming majority of their traffic through their native mobile app"

Source?

And I do not think, there is a sharp line between WebApp and Website. You could say, we are using one right now (even though very primitive) discussing right now - more than "static(-ish) content"

Also most of the other parts of the Web are not really static anymore - <USER2> dynamic, live interaction between the whole world! That's pretty awesome if you think about it. So the Web works and the web is faaaar away from static documents linking each other, what was it's origin.

And with real webapps - well, I believe the big ones are about to come. The underlying technology to really make them usefull, is just about to become stable.

<comment><USER8> > Source?

[https://expandedramblings.com/index.php/facebook-mobile- app-...](https://expandedramblings.com/index.php/facebook-mobile-app- statistics/)

Over 50% of facebook users only access it from their mobile devices.

> And I do not think, there is a sharp line between WebApp and Website. You > could say, we are using one right now (even though very primitive) > discussing right now - more than "static(-ish) content"

You could make that claim but it'd be a tough sell. Sites like this are clearly not what anyone talks about when they say "web app" or extol the virtues of HTML5. This site is static(-ish) content with hyperlinks to go to new static pages. It's not dynamic or highly interactive. Which is part of what makes it great, don't get me wrong. But it's clearly not a candidate for a web app, it's not clamoring for webasm, webgl, or any of those shiny new toys, etc...

> the web is faaaar away from static documents linking each other, what was > it's origin.

How do you figure? Most people google something (either via a dumb web form or more commonly via a native app), then click a link to a static page.

Or this site, which is basically just an index page of yesteryear, and is literally just a bunch of static links to other usually static content.

> And with real webapps - well, I believe the big ones are about to come. The > underlying technology to really make them usefull, is just about to become > stable.

I disagree since the underlying technology really truly doesn't exist. The fundamental basics to making a responsive app still don't exist at all (no cheap concurrency, for example, to say nothing of cheap parallelism).

<comment><USER7> "> Source? [https://expandedramblings.com/index.php/facebook-mobile- app-...](https://expandedramblings.com/index.php/facebook-mobile-app-..). Over 50% of facebook users only access it from"

maybe it is hidden somewhere, but I only read "mobile users only", not "native app" only. So users who access by browser would be in that category as well

</comment></comment></comment></comment></comment><comment><USER9> It's probably not realistic, but I would love to see the web be completely thrown out and replaced with something reasonable.

I write a decent amount of native code. I write Rust, C, and x64 assembly. I think I'm pretty good at this stuff. But the web is too much for me. Any time I think I'd like to do something with the web and sit down to learn, it's completely overwhelming. I've never been able to put together a coherent mental model of the architecture of a web application or figure out what the best practices are for web development. The amount of complexity you have to wade through to get anything done is just silly.

There's the idea floating around that web developers are less competent than programmers on other platforms. I'm only half serious when I say this, but I sometimes wonder if, to the extent that this is true, it's because web developers have _so much_ incidental complexity to deal with that there's just not much brainspace left over for classical CS or software development concepts.

<comment><USER10> The thing is, though, the web _is_ reasonable - for its intended purpose, which is displaying and interlinking documents. And despite the complaints, faults and shortcomings, it's even remarkably not as bad as it could be at being an application platform.

Throwing that out because it's less than optimal at a use case it was never intended to serve would be monumentally short-sighted. Just build something _else_ and leave the web be.

<comment><USER11> I think what he meant was "throw out the web as a platform for applications", not as a platform for document distributions.

<comment><USER12> If so I'm in full agreement.

It's truly mind-blowing how much energy has been wasted on trying to shoehorn the web into an app delivery platform over the last decade. To what end? To make the browser a general purpose platform? We have that already, it's called an "operating system".

Edit: that said, I disagree with many points and the general negativity in TFA

<comment><USER13> Are you comfortable running arbitrary binaries built by arbitrary people? If not, then I fail to see how an operating system is a sensible general purpose computing platform.

It worked OK when we just wanted to run software written by a handful of trusted parties... Microsoft, Adobe, id Software. But as soon as there were 1000s of companies writing software that we wanted to try, running binaries ceased to be a good idea. I don't really trust any binary software on my machine that isn't written by Apple. But I will open basically anything in a web browser because I don't have to trust it.

Even now, with all the sandboxing, Microsoft and Apple still have to manually review software in their stores. And truthfully, app stores are basically a naive Web of Trust system. It's not safe at all. Applications constantly open up holes and then say "oops! Security bug!" and what... you're owned now? But Apple doesn't believe it was a maliciously placed hole, so it's all good? Hell of a security model!

<comment><USER14> "But I will open basically anything in a web browser because I don't have to trust it."

That's incredibly funny. I guess sooner or later you'll learn why it's a losing strategy.

The web is probably the largest malware infection vector nowadays.

<comment><USER15> It's the largest malware vector because it's the largest software vector. It still remains true that running a random website is a million miles away from running a random exe.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> I sympathize with the sentiment, but the web app only sucks if you're using the stuff that sucks.

Like any technology with decades of evolution it has a thick sediment of peat. Half of Javascript, half of Windows, even half of *nix is garbage you should never use, but it's all there because old things would stop working without it.

It's just that the web has a very low barrier to entry and very high reach, so the compost doesn't get thrown out as quickly as it should. So people still pack jQuery when they need to select elements, or pull a left pad from npm without realizing it's in the language core. Or pack Reactiflux when they want to do a form.

In an age where you can literally compile existing, GPU-heavy C++ code to WebAssembly and run it in the browser with no fuss, you can't complain the web doesn't let you do things right, or at least the way you want. It's just admittedly easy to hop on the wrong library bandwagon and complain when things go wrong. But it's not a problem with the web.

<comment><USER17> > but the web app only sucks if you're using the stuff that sucks.

Please show me anything that doesn't suck on the web. And yes, I've been doing web development for close to 17 years now.

There's almost nothing that doesn't suck on the web. The languages, the tooling, the platform - you name it. It is good for one thing, and one thing only: displaying single-page interlinked documents with little to no embedded media. Any and all other attempts to make it do anything else end up bloated incomplete internally inconsistent overlapping monstrosities.

<comment><USER18> I have been using elm for some time now, and it's the first time I feel I am using a non broken tool.

<comment><USER19> Agreed, I learned Elm a year ago and haven't looked back. Love being able to dismiss all other frontend web talk without a second thought.

<comment><USER17> But you can't. The moment you need to do a layout, you're back into html + css and it's inabilty to cater to anything beyond single-page documents (not apps) ;)

<comment><USER18> Actually server side rendering is comming, it's working in a hacky way, but it's promising.

</comment></comment></comment></comment></comment></comment><comment><USER20> I don't get the section on JSON, which seems to assert that XML is more secure than JSON. It does this by linking to a Wikipedia page that includes the security consideration that you shouldn't call eval on JSON. True, but at least that's a tractable problem. Your linter can check for code that calls eval.

In contrast, there are plenty of XML attacks (DOS with billions of laughs, entity references), and parsing XML is a lot more complicated, which matters a great deal if you're using non-memory-safe libraries for parsing. Also, because XML is so general purpose, you get things like libraries allowing deserialization of arbitrary objects from XML, which is a security nightmare.

That last point isn't a clean win because sometimes the same library will handle JSON and XML, and so you have to audit the use carefully. However, if you're sure that your serialization libraries only use JSON, its simplicity means that it shouldn't have that kind of deserialization vulnerability.

P.S. If you want to rag on JSON, that's fine. It's not a great format. But "it's less secure than XML" is not the tack I'd take.

<comment><USER7> "If you want to rag on JSON, that's fine. It's not a great format"

JSON is simple and powerfull. It's success justifies it, to call it a great format, I think. But I am curious, what whould be a great format, in your opinion?

<comment><USER20> JSON gets the most important thing right: it's simpler than XML. I probably should have rephrased my comment. I literally mean that it's a decent format, but not a great one.

One issue is that it's surprisingly poorly specified: [http://seriot.ch/parsing_json.php](http://seriot.ch/parsing_json.php).

As a data-interchange format, it lacks first class dates/timestamps, the issues about specification are a pain when dealing with numbers (depending on language, you may not be able to use the full range of 64 bit ints), and has no builtin concept of schemas. That said, I'm not sure what I'd recommend above JSON, though you clearly wouldn't use it for really high performance servers.

It's also used as a configuration language, where more issues surface. It doesn't accept trailing commas or comments (I can see the argument for requiring all keys to be quoted, but that's a pain to write as well). For configuration, I think I prefer TOML to JSON. Dhall looks cool, but I've never used it.

<comment><USER21> I think it's weird to criticize JSON _the format_ for lacking these specific features. I think there is absolutely an argument to be made that its simplicity often means that it's not the right tool for the job. There are a lot of developers who are stuck on making JSON do horrible things and end up reinventing the wheel poorly because 'XML is gross' but I wouldn't say the right answer is to add these features to JSON.

</comment></comment></comment></comment><comment><USER22> >In part 2 I'll propose a new app platform that is buildable by a small group in a reasonable amount of time, and which (IMHO) should be much better than what we have today... Next time: how we can do that.

i look forward to that article. This one, on the other hand, seems a little pointless. Does the web have problems? yes, absolutely. But I have a hard time believing the best way to solve them it to tear down everything we've built so far and start over.

<comment><USER23> I agree.

People seem to think that there was a time when the internet was better than it is today. Well, I've been 'online' since before the web was world wide. Frankly, it was never good.

In fact, it is better now than it has ever been. It's just people choose to use the worst parts of it.

I've seen the various tech that was supposed to rebuild and revolutionize the web. It's just created more kludge. It's just lipstick on a pig. It's just one more set of standards that get half-ass implementations and even worse support.

If you tear it down and rebuild it, it's just going to end up the same except it is using different names for the protocols.

I'm not angry when stuff breaks. I'm amazed it works at all.

And, truthfully, I kinda like it the way it is. We have, at our fingertips, vast amounts of information and entertainment. It works, after a fashion and for some definition of 'works.' If the Internet sucks for them, maybe they should look elsewhere? The Internet is huge. It's not hard to find parts that don't suck.

Tearing down and rebuilding isn't going to work and nobody is going to invest in that. Hell, we can't even get ubiquitous IPv6 adoption. Not one browser is fully compliant with HTML5. And it's okay. It works, mostly.

<comment><USER24> Everyone has a different definition of what's good and what's bad about the web. A lot of smart programmers seem to think almost all software is bad. Probably all software that is actually used is not as good "as it could be." Any evolutionary process is going to be like that.

HTTP and HTML were absolutely not designed for many of the things they are used for today. A bunch of really smart people probably could come up with a much better solution for modern usage, and lots of them have tried. But the web has too much inertia (the users are there and don't care about these problems) and, as you say, it more or less works, or can be made to work.

It does seem inevitable that it will be superseded eventually, but how far off is that?

<comment><USER23> > how far off is that?

Whenever an OS depreciates, but not kills, something in an API, somebody ignores that it is depreciated, doesn't use the new method, and writes new software against the now-depreciated function.

There are people still using legacy software that got was first written in the 1970s. Someone took that software and converted it from punchcards to hard drives and from memory that was a spinning drum to memory that is solid state.

Somewhere, there are COBOL developers still maintaining stuff older than many of the folks that frequent HN.

I suspect you're right, in that it will be superseded - but I am willing to wager that it is going to take a long time and never be completely done. There is stuff that hasn't been updated since the 486 days and is mission critical. Fortunately, it works - because nobody has any idea how to fix it if it stops working.

As a society, we've accumulated so much technical debt that we may have reached a tipping point where it's simply impossible for us to catch up and it's unrealistic to think we will burn it to the ground and rebuild.

I suppose some external force could crash the house of cards but I suspect we'd just rebuild it with new faults or the same old faults.

Like you say, HTTP and HTML weren't meant to do this. Now we have webassembly, HTML5, and JavaScript libraries that nobody fully understands. We've now tacked on DRM to the standards, put the real functionality in the hands of ICANN, and crammed our data into towering silos of proprietary goodness.

We had a brief moment where we largely owned our devices and our data. Now, we lease supercomputers for our pockets while giving control of our data to a mysterious entity known only as The Cloud. 100 years from now, nobody is going to know how it works and we will attend churches where we pray, sacrifice, and tithe to the god known as The Cloud.

It will be superseded, but it will be just another kludge patched on top. It's like cars in Cuba. They are old and functional, but contain engines from a Lada, bumpers from a bus, seats from three different cars and a horse drawn cart, an exhaust made from tin cans, and four different size wheels.

And you know what? Those cars are a testament to the resiliency and skill of the Cuban mechanic. They are awesome. It's not amazing that they break down, of course they do. It's amazing that they run at all.

On a more serious note, I suspect well just keep patching and tweaking. Eventually things will get better. It has been steadily getting better this whole time.

I like to complainand point out the flaws, but it really does function. It's great and the immediacy of information has been a great asset for humanity.

The Internet really is better than it has ever been. Searches used to be done by a human. As in, you'd send them your question and they'd go through their directory, make phone calls, contact institutions, and get back to you with an answer - usually 3 days latter. Yup... Three days to get an answer. Sometimes, you had to wait for a system to come online, usually a small localized network, and only then would your email be delivered.

It works. It's like a dysfunctional family. Loving, possibly abusive, but our family. I suspect it will continue to improve, slowly but surely. Smart people are constantly innovating and improving. Standards and specs get refined.

The Internet, being vast, means there is a place for pretty much everybody. It has it's warts and there are legitimate complaints, but sometimes it actually does what it is supposed to do, when it is supposed to do it. Sometimes, possibly by accident, people make good choices that result in good things.

Also, cats... So long as we have cats, the Internet will be just fine. Gotta love it, warts and all.

</comment></comment></comment></comment><comment><USER25> People used to do that, in 90s CGI scripts were usually written in C, or even assembly. And let me tell you since I'm old enough to remember it: no, it wasn't a great experience at all. It was actually quite horrible for web developers from the today's perspective. Development was slow and painful and hard to debug as hell. Also, it wasn't secure at all, hacker usenet groups were all about stack overflows back in those days.

One of my first jobs in late 90s was a complete rewrite of a huge web app into perl. It was originally written in pure C, and it had so many security and stability issues due to bad castings and stack overflows and null pointers and all that usual C stuff, that today it'd be considered completely unusable (back then corporate users were far more tolerant I guess). Perl rewrite fixed it all, no stack overflows, no worries about casting every input every freaking time, no sql injections (perl DBI used prepared statements), everything worked like a charm. And it took us only a fragment of the time it took for the original development. Programming cycle was like 10x faster since you didn't have to compile it first (just that was worth it), code was easier to read, we were much less likely to make stupid errors, etc. That's why everyone moved to perl and then php, python, ruby, etc. in the first place. They are simply better tools for the job, history has proven it already like 20 years ago.

<comment><USER26> And can anyone still read all that Perl? I used to speak Perl but I know I'd be far better able to understand some C I'd written 20 years ago than any of the Perl I did back then.

<comment><USER25> To quote the Matrix: "You get used to it, though. Your brain does the translating. I don't even see the code. All I see is blonde, brunette, redhead."

</comment></comment></comment><comment><USER27> Fun fact: The colorful Windows 98 explorer sidebar that is shown in the first screenshot was implemented as HTML (and Javascript), along with the desktop background (called active desktop).

<comment><USER28> Actually the folders themselves were too. You could edit the actual CSS and HTML behind them – changing the colors, putting in backgrounds – by placing specially named files in the directory. Windows 98 was a glorious thing.

<comment><USER29> Yup. I once got paid an absurd amount of money to "customize Windows 98" meaning, write a couple of lines of HTML and Javascript.

</comment></comment></comment><comment><USER30> An article about the web and it doesn't mention quintessential terms like 'link', 'network' or 'platform independence' even once.

Do you know why your 1990s app was so much 'better' than today's web apps? Because it was only supposed to run on Microsoft Windows, and a specific version of Windows at that!

The same applies to layouts. If all you have to deal with is SVGA and Windows 95 layout constraints are a piece of cake.

> Really impressive software would be embeddable inside Office documents, or > extend the Explorer, or allow itself to be extended with arbitrary plugins > that were unknown to the original developer.

Those were only reinventing the datatypes system introduced in AmigaOS in 1992.

> In part 2 I'll propose a new app platform that is buildable by a small group

Yeah, because that's always worked so well in the past.

> there's no Web IDE worth talking about

Save for Intellij IDEA / WebStorm, Visual Studio Code ...

<comment><USER31> > Because it was only supposed to run on Microsoft Windows, and a specific > version of Windows at that!

I worked on an ebook editing tool in 2013 that only supported the two most recent versions of Chrome. If you have a product that is truly valuable to your customers, they will install dependencies to make it work.

<comment><USER32> chrome is free, windows ain't

</comment></comment></comment><comment><USER33> Firstly, rewrites never work and people won't abandon a working solution for a "better" one unless it has a killer feature.

But the real thing is: the "web platform" is not the result of a design process, it's the result of a war. It's the stalemate point between so many competing technologies. It's the no-mans-land between warring monopolists.

Any monopolist could have given us a "tidier" solution (although probably not secure either!) We could have had the ActiveX future, or even a global Minitel system. The web is uniquely in persisting without yet fully falling to any "winner takes all" effect.

</comment><comment><USER34> I strongly disagree with the part about REST being a workaround for browser limitations. REST is about manipulating an arbitrarily large namespace with a small number of verbs; an elegant and powerful design pattern that actually deserves a better platform than what HTTP provides. It transcends browsers and protocols and will be reinvented in any well designed system that manages to survive its own evolution.

The rest can basically be summed up as "the web is a mess," and I agree with that. Can it be otherwise? I have often thought the coercion of HTML+CSS into a platform for complex interactive applications has been pretty terrible. Some of the links to other blog posts that supposedly support Mike's argument are actually criticisms of "JavaScript development." Yet JavaScript is just a programming language, like any other; it isn't limited to web development and the flaws it has are being addressed. JavaScript is the baby in the bathwater and there is no reason it shouldn't be a big part of whatever comes next.

Show us something small, powerful, clean, open and that unifies desktop and mobile and maybe you'll get somewhere. I am not one who believes the current paradigm is immortal; if this blog post contributed anything of value I think it is the observation that the web stack has effectively failed mobile; native tool sets work better in almost every way and are indeed the first choice when you need to make high fidelity mobile applications. That shows the limitations of the web stack and provides and opportunity for a competing solution.

<comment><USER35> Although REST generally boils down to SELECT, INSERT, UPDATE, DELETE.

For an inspirational interaction model, look to SQL.

</comment></comment><comment><USER36> It's worth remembering that in the late 1990s, as Microsoft was facing its own security crisis and everybody hated the Wintel monopoly and how bloated Windows had become, several people put out calls for new systems to replace Windows. This was the era of Java applets, of Linux on the desktop, and of cross-platform widget libraries like Qt and WxWidgets.

What we actually got instead was the Web.

And the reason we got the web was because it was never conceived to be an application platform, and Microsoft crushed the only company who was calling it as such (Netscape) and declared victory, and then were caught completely unaware when new challengers like Google and Facebook sprung up and adopted the web for what it was and then totally ate Microsoft's lunch with it. By not _looking_ like an OS, the web was able to differentiate itself in consumers' minds and not force comparisons to a much bigger, more mature platform until it was so entrenched it was impossible to make go away.

If you want to build a replacement for the web today, your first priority should be to think of something that millions of people will use daily. It can (and should!) be really simple initially - the Web was first used for sharing scientific papers, and then for creating WebRings of band fanpages, and then for porn, and it took 20 years or so before full webapps became viable. But thinking about it from the perspective of how you make a secure, performant, maintainable programming environment for developers is exactly the wrong approach. History is littered with projects that do exactly that and fail to get anywhere.

<comment><USER37> I would add that anyone looking to replace the web should think about what problems the web _doesn 't solve_. I think you could argue that this was what made the web itself successful. Mr. Berners-Lee saw that there was no system which had gained market acceptance that organized information in the way that people actually tend to organize it (which is not hierarchically). As you may have been alluding to, simply coming up with a more elegant, well-architected version of the web has no value to anyone outside of the engineering room.

</comment></comment><comment><USER38> I agree with most of the author's opinions. I'm old enough to have seen the rise & fall of 90's development.

Developers who have been ingrained in web technologies tend to think of the times before as dark ages. They really weren't. Today simply isn't the absolute best that all things have ever been.

Sure some things were a bit simpler & less flashy then and hardware was more limited, but there were a lot of great ideas that have been forgotten and shoved aside in the excitement for modernization. Best practices & whatnot.

But, what the author forgets, is that this is the state of things. Really inventive ideas exist, sometimes in niches, die, and then get rediscovered and reimplemented in circuitous ways. Asinine artifacts tend to arise in every paradigm shift.

I'd argue that word processing, for example, has barely caught up to the days prior to the graphical user interface. Now, with the web browser & mobile, it hasn't even come close to feature parity yet. It will, eventually, mostly. And it will be exponentially more bloated and complicated than before. Such are things.

</comment><comment><USER39> the biggest security blunder of the web platform is allowing third party domains to inject code into https pages, which completely violates the trust that https is meant to establish.

and it's here to stay, folks! because the entire trillion-dollar ad industry is built upon it, vacuuming up data about users across the internet.

a huge amount of security and privacy issues would vanish overnight simply by requiring same origin.

the fact that my banking backend has third-party metrics scripts injected [without uMatrix/uBlock Origin] is unforgivable.

and of course half the web is broken without allowing 2 or 3 CDNs or cloudflare to track me everywhere i go.

<comment><USER40> I agree and disagree. From the perspective of anyone making a web site it's very easy to secure yourself against JS running on a third party domain: don't load any.

That sites _do_ load these scripts says a lot more about their priorities and the state of online advertising than it does about browsers themselves.

<comment><USER41> > _From the perspective of anyone making a web site it 's very easy to secure > yourself against JS running on a third party domain: don't load any._

No that's only half the solution, the other (much harder) half is to ensure you have no XSS. The GP's point was if they hadn't allowed cross-origin scripting it would have had big security benefits.

<comment><USER42> Set the Content-Security-Policy in the HTTP response.

</comment></comment></comment></comment><comment><USER43> There's one big problem with killing the web: Apple's App Store. You can make all the new platforms you want, but they will never be allowed to replace the App Store for distribution.

The web is the only platform that can do distribution outside of the App Store on iOS and Apple will never allow a second one. That means your platform can't have hyperlinks between apps, can't have a no-install experience, can't do just-in-time code delivery. Without those features you can't replace the web.

<comment><USER44> > hyperlinks between apps

Sure you can.

iOS - [https://developer.apple.com/library/content/documentation/Ge...](https://developer.apple.com/library/content/documentation/General/Conceptual/AppSearch/UniversalLinks.html)

Android - [https://developer.android.com/training/app-links/deep- linkin...](https://developer.android.com/training/app-links/deep-linking.html)

UWP - [https://docs.microsoft.com/en-us/windows/uwp/launch- resume/w...](https://docs.microsoft.com/en-us/windows/uwp/launch-resume/web- to-app-linking)

<comment><USER45> One problem I've had when developing for iOS is that universal links don't "trigger" after a redirect, which is very relevant for sending emails though something like MailChimp with click-tracking.

<comment><USER46> The irony of complaining that native, here portrayed as an alternative to a hopelessly multi-party web platform, won't let you interject arbitrary parties between a link and its destination…

<comment><USER47> Basically a case of "I want it to behave exactly like the web, but don't call it that."

</comment></comment></comment></comment></comment><comment><USER48> > _For the first time, a meaningful number of developers are openly > questioning the web platform._

Lost me in the opening paragraph. " _For the first time_ "? Please, people have been openly questioning the web platform for a decade now.

Ever since mobile (and their native apps) starting "killing off the desktop".

Ever since people downloaded their first PhoneGap/Cordova app, and saw how badly it looks and behaves compared to native widgets.

Ever since people pulled up a task manager, and noticed how much RAM and CPU that Electron-based app was using.

On the other hand... we've been openly questioning native too, ever since basic social media apps starting weighing a hundred megs each. Every platform has its problems.

<comment><USER49> Are there any alternatives to Phonegapp? Ever used Flutter or Kotlin?

<comment><USER50> I'd probably look towards react native if I were trying to build a phonegap- type app.

</comment></comment></comment><comment><USER51> > It's time to kill the web ... I'm going to review the deep, unfixable > problems the web platform has: I want to convince you that nuking it from > orbit is the only way to go

gee, those statements are bold. Not only JS or even the front-end stack, the author wants to kill the whole web and make a new one.

I can say it is not a first time I've seen an engineer seeing something imperfect and suggesting that everybody should immediately abandon it to make something better from the scratch.

Like many of you, I am looking forward to see the second part for a web alternative. What I am interested in is how the author wants to make his proposal as beginner-friendly as the web already is.

</comment><comment><USER52> The reason the web platform is "ugly" is because nobody owns it. Multiple players need to get on the same page in order for things to happen. The end result is not pretty (different browser versions behave differently, incomplete specs, etc.), but one thing is constant - nobody owns the platform.

This is important because of things like this [1]. You may dislike some apps' mission, or approach to moderating content, but you cannot outright ban it from your platform, if you don't own the platform.

[1] [https://arstechnica.com/tech-policy/2017/08/gab-the-right- wi...](https://arstechnica.com/tech-policy/2017/08/gab-the-right-wing-twitter- rival-just-got-its-app-banned-by-google/)

</comment><comment><USER53> Apart from some justified points on how confusing origins can be, the author fundamentally misunderstands Web development.

Not only do users want fast sites and multiple of them open, so the performance point bears little weight, but the authors points to OOP techniques, presenting them as necessarily superior to FRP because they came later to Windows.

Next the criticism on productivity and size of developer teams. Productivity has gone up tremendously in my experience e.g. by doing universal apps using React/Webpack/CSS Modules and following FRP principles, all of which you can do while maintaining Web semantics. If you haven't noticed gains in productivity, your workflow is wrong and you aren't taking advantage of the current tools. From my point of view, things used to be much worse and it is finally maturing.

I won't bother commenting on the rest because the article just go down from there in confusion mixing up services with applications. The author just basically wants to write desktop apps, but also be able to take advantage of the Web's discoverability.

<comment><USER54> > "Next the criticism on productivity and size of developer teams."

Were we reading the same article? The main criticisms made by the author of the article were about web app security. If there was a mention of productivity it was only made in passing.

> "The author just basically wants to write desktop apps, but also be able to > take advantage of the Web's discoverability."

Is this a bad approach?

</comment></comment><comment><USER55> While i understand the article and agree with it, i love programming webapps. The combination of html/CSS is much easier (for me at least) to work with than most other rendering framework, also JavaScript while not perfect is very good for fast moving target, and with "extension" like typescript you can even manage very large application in a progressive way (you can mix js and typescript).

I also work with the android layout system and a bit of the iOs one, and they are a lot more confusing, (Constraint-layout fixed a couple of problem on android recently). Currently i work manly with legacy asp.net app at work, and shiny all-js webapps at home, but i done a lot of work also with winform and android apps

Also the ability to update the app "on the fly" and be able to download only the part of the application that you need is pretty cool. Your can make your user always use the last version and quickly deploy hotfix. I understand that this are not propriety desirable for every type of application but sometimes are game-changer.

What i really want to have is a lighter implementation, i think that Facebook did something similar with is Facebook lite app.

Here's a gist with what i really want for a layout/app runtime. * Using a Url style system for retrieving resource.

* A binary protocol similar to protobuf,capnproto etc.. for talking with the server.

* A clear separation between the template and the data, so that i can cache the entire page and only request the data for populating it.

* A Module and a Permission system, with versioning (for backward and forward compatibly),maybe integrated.

* One way to store data (i personaly like key-value system, but i think a document system would be more suitable).

* A Unified syntax for html and css.

* a Component system(this is a big one), ideally the spec should only define a div-style generic container that can be specialised in a new component by adding to it, a name, style and optionally a script witch control is behaviour, (I'm not a fan of the web-component spec as it is).

What would you want from an alternative layout/runtime system for web-like app? I'm really curious!

PS: I really hope there will be more engineering post about the Facebook lite app, it seem a concept really cool that could be used for a lot of other apps!

edit: adjusting formatting

<comment><USER17> > The combination of html/CSS is much easier (for me at least) to work with > than most other rendering framewor

Html+css is not a rendering framework. Also, come back with your "much easier" when you need to do anything even remotely resembling iOS's screen transitions, animations, and capabilities for constrained layout.

Even properly implementing the seemingly simple toolbar in Google Docs is an excercise in endless frustration.

<comment><USER55> My bad, i didn't express myself, for rendering framework i mean both the language and the technology that actually "execute" them. I understand that different browser do thing different but the concept are the same.

Also i don't know ios very well, but i have implemented complex layout in both android and the html/css/js and i can say that android is MUCH more frustrating, even when we consider browser backward compatibility, especialy on the animation side (css animations were a bit hard at first, but in little time i was able to construct complex animation very quickly).

I actually have builded a toolbar like the one on google docs (which i use daily) for editing data in a timeline for appointment, which had to be compatible with IE8 and while there was a lot of pain, i was able to iterate and experimentate a lot more quickly than android, and it wasn't that bad, also in my experience when we talk about layout and user interface there is A LOT more documentation on html/css than android, and there also are more framework/library that can help you deal with browser diffrence.

<comment><USER17> This only means that Android managed to create something that's wors than html+css, which is quite an achievement.

Meanwhile, for every small thing that you need on the web you need to reinvent things from scratch. Animations. Lists/virtual lists. Containers. Toolbars. Menus. Keyboard shortcuts. Constrained layouts. Layouts in general. Interactions. Combinations of anything above. Any basic UI component and interaction you can think of is non-existent on the web, and is re-implemented poorly and inconsistently by an infinite number of various UI frameworks.

<comment><USER55> The css is the part i will leave mostly the same, i will change the syntax a bit, but mantain the functionality.

</comment></comment></comment></comment></comment><comment><USER56> Flux is not equivalent to Windows Events. The analogy is DOM Events. Also, Flux is not required for building web apps.

After this I thought that it makes no sense to read the article further.

For me the problem with web apps is low performance, slow load time. Another problem is people who try to push programming patterns from functional languages (like immutable values) into mainstream JS libraries. Please use Haskell instead if you love immutable values that much.

<comment><USER57> Despite the slow web performance I find web apps open much faster than their iOS app equivalent. This is despite the fact that iOS apps have 100-200MB downloaded in advance while the web loads your binaries and assets on the fly.

<comment><USER56> Maybe those iOS apps have a browser inside?

</comment></comment></comment><comment><USER57> The 2arguments presented are: 1)Reinventing the 90s - Why is this necessarily a bad thing? The author links to a blog post discussing how Flux is similar to Windows 1.0 but that author of that post does not claim that makes Flux bad. In fact they agree it works well and scales well as well. The only thing they say is that based on the experience in the 90s it's likely we will have further developments on this model. Why should those developments not be on the web platform itself (also who thinks that if we are gonna start a completely new platform we wouldn't reinvent the 90s on it again?).

2\. Impossible to secure - Yes security is a huge issue with the web. But a large part of that is older designs and many have been mitigated (as an example, the wiki section the author links to show why JSON is insecure has 2insecurities. Security issues in parser implementations which are not written in web technologies anyways and the fact that before 2009 and the widespread availability of JSON.parse and JSON.stringify people used eval to parse JSON).

I'll be honest that I do think the web needs to be improved/changes/replaced. I don't think this article makes the point well and possibly focuses on the wrong things. But my biggest concern is with the idea that improvements need to be achieved by replacing the web instead of the kind of incremental improvement we are already seeing.

I would be interested in Part 2 to see if the replacement the author has in mind is really worth it. It would need to at least be an order of magnitude better to sacrifice the compatibility advantages the web has, but it may still be worthwhile to think of what a platform written today from scratch would look like to focus the kind of improvements we would like to see on the web.

</comment><comment><USER58> This post reminds me of a few old blog posts by Glyph Lefkowitz (of Twisted Python fame):

1\. on what's wrong with web development: [http://glyph.twistedmatrix.com/2009/09/oh-atangled-web-we- we...](http://glyph.twistedmatrix.com/2009/09/oh-atangled-web-we-weave- from.html)

2\. on how to fix it: [https://glyph.twistedmatrix.com/2009/09/web- untangled.html](https://glyph.twistedmatrix.com/2009/09/web-untangled.html)

3\. earlier, on the problems with generating HTML through string concatenation: [https://glyph.twistedmatrix.com/2008/06/data-in-garbage- out....](https://glyph.twistedmatrix.com/2008/06/data-in-garbage-out.html)

Also, my own personal plea: If anyone tries to create a new platform or front- end framework, targeting the browser or otherwise, _please_ don't neglect accessibility for people with disabilities, i.e. with screen readers and the like. At least the Web sort of gets this right.

</comment><comment><USER58> What about the fact that the Web platform isn't owned by any one company, but is supported (to varying degrees) by every major native platform? A shiny new app platform won't have that. That's important.

<comment><USER59> In theory indeed. In practice there's 3 vendors and the standard defining organisation represents commercial interests in the platform, not you.

<comment><USER60> 3 vendors is still better than one.

<comment><USER59> Name one other platform/deploy target that is as centralised on the vendor side, even though everyone calls it "open"

<comment><USER60> OpenGL

</comment></comment></comment></comment></comment><comment><USER61> This article is so naive.

It completely negates all the benefits of the open web while presenting problems along with non-sensical "fixes"...

<comment><USER62> I apologize in advance for a political analogy but this sounds like "Obamacare is bad so we must repeal and replace it. I'll show you the replacement later."

I've been a webdev for two decades now and while the author highlights the problems correctly, almost all of them have known fixes and there are 'best practices' to avoid them.

Humans are not done with engineering and technology. We're still coming up with better ways to do things. Building for the browser is one of the best things we've done as a civilization. I can build something, send a link to my dad, and he can look it up on his phone with literally a single touch. How is that not amazing? It blows my mind every time I stop to think about it.

It sounds ridiculous to say that since buildings fall every now and then, it's time to kill dwellings or since cars crash frequently, it's time to kill transportation. So without seeing the author's replacement, I am not yet ready to throw away the browser and JS-ecosystem just yet. It's terrible that Authy's 2-factor was bypassed with one simple trick but that doesn't mean HTML/CSS/JS need to die. You could have the same exact issues with mobile apps, installed software, or even hardware devices.

<comment><USER63> > It sounds ridiculous to say that since buildings fall every now and then, > it's time to kill dwellings or since cars crash frequently, it's time to > kill transportation.

It's more like, since cars crash frequently, time to replace human drivers with machines.

I take his argument as replacing the web as an application platform with something designed from the ground up for applications.

</comment></comment></comment><comment><USER40> It's probably not possible to evaluate this post without waiting for part two, where the author says they'll outline their plan for The One True Platform, because after reading part one I come away saying "yeah, so what?".

I don't think many people working on the web platform evangelise it as the most amazing software development platform that's ever existed. But they do recognise the reasons why it has proven to be as popular as it is, and what can be done to improve it. That's why we've got WebAssembly for native code, Service Workers for offline capabilities, WebGL for performant graphics, so on and so forth. Yeah, it's scrappy, but it has much more chance of being successful than some start-from-scratch idealised standard (that will have no security vulnerabilities, naturally) that someone just brewed up.

But hey! Maybe I'm wrong. Maybe part two will blow the web dev world away. But I'm not holding my breath.

</comment><comment><USER64> The author seems to think that most developers think the Web sucks and needs to be killed. While this may have a sliver of truth behind it —in that a lot of us are dissatisfied with certain aspects of the platform— there's one thing the author fails to address:

If the Web (and Javascript) suck so badly, then what's up with all those Electron desktop apps? And all those react native/nativescript/ionic mobile apps?

IMHO, the author fails to address the _only_ reason the web is popular as an application platform: its still the only reliable way to make sure your code runs everywhere with as little effort as possible.

</comment><comment><USER65> I disagree.

\- Web apps remove the need for installing an application. This alone has multiple positive implications, such as lowering the entry barrier for usage.

\- Most of the time you can use them from any operating system.

\- Security-wise, locally installed apps are not more secure. A locally running app if anything gives a larger attack surface to the end user.

\- The level of security major browsers have is not within an average business budget.

Finally, the most important point:

Security is a 2 way street. Just like you can attack software installed in your computer, the software itself can as well be malicious and attack you. Web browsers provide guarantees on what a web application can do and what they cannot. Without these guarantees, it would be much harder to trust an application. Mobile operating systems try to solve this problem with permissions, and it has been rather effective, but not all people pay attention to them. With desktop apps you are largely on your own.

</comment><comment> dan-f I'm not impressed with this article:

\- The author failed to draw a clear distinction between "The Web" as an application platform and "The Web" as a network of semantic information.

\- Digging deeper, "The Web" the application framework is pretty flexible. There are plenty of ways to use hypermedia and HTTP, while using your own non- HTML/CSS UI tooling.

\- The article strikes me as ill-researched -- the author writes "Here's a good blog post on Flux, the latest hot web framework from Facebook". Flux is definitely not the latest from Facebook, and some of the linked articles were from 2015. For better or worse (I think better), front-end is moving really fast, and the web platform roast listicles don't age well.

\- The point about "UI Complexity" is just odd. UIs should _not_ be complex. Comparing the windows explorer to Google docs is comparing fruits to vegetables. The point "look! we still have toolbars and shades of grey" has nothing to do with the web and everything to do with UX metaphors and familiar affordances.

\- "Things as basic as UI components are a disaster zone". UI "components" are not basic! What is a component? No seriously, ask a programmer content with OO languages, and then ask someone who prefers functional languages. Then ask those developers to agree on an interface.

Though I do agree with:

\- Web apps are slow. Painting is really complicated.

\- So many apps are written with the assumption that they're always online. The author is right that users have low expectations when it comes to good offline experiences.

\- The web wasn't designed with our contemporary single-page application use case in mind.

\- JS could obviously be way better.

\- The need for backwards compatibility is pretty crippling.

\- Security is difficult to get "right".

</comment><comment><USER66> > Where desktop apps have exploit categories like "double free", "stack > smash", "use after free" etc, web apps fix those but then re-introduce their > own very similar mistakes: SQL injection, XSS, XSRF, header injection, MIME > confusion, and so on.

All of these are pretty thoroughly solved by picking tools that don't let you shoot yourself in the foot, and SQL injection isn't remotely a web app thing. (The others are far less severe than RCE, anyway, as they only affect the one app. I guess the argument here is that the web platform isn't yet optimal? Work is always continuing to improve security – take Content-Security-Policy, for example, which mitigates every type of exploit mentioned even if you do everything else wrong – and if you think it can't work out, point out a real alternative.)

</comment><comment><USER67> > web apps fix those but then re-introduce their own very similar mistakes: > SQL injection...

Any system using a SQL database is susceptible to SQL vulnerabilities, web based or not. Not to mention SQL injection is a largely solved problem. Creating concatenated strings for your database to execute is hardly the web's fault.

</comment><comment><USER68> Said the author who wrote the post inside a rich text edition app, a web app, which happen to be this thing called Medium. Oh the irony!

<comment><USER17> Please read Medium's own posts on how they implemented this capability and the pain they went through implementing it.

</comment></comment><comment><USER69> >> We desperately need a way of conveniently distributing sandboxed, secure, auto-updating apps to desktops and laptops.

What's the proposal?

* App stores controlled by juggernaut companies, doing the app-screening?

* Signing web apps bu an authority?

* Writing in "safe" languages in java/rust/..?

* Java applets?

* Adobe Flash? Silverlight?

* Uglified, minimized encrypted JS code?

* or Win95 style self-extracting installers for downloaded apps, installed by users with no package management?

* Debian style package managers?

<comment><USER56> Screening apps by a large company is not bad. Users don't want to guess whether the app contains malware or not. They would prefer someone do it for them.

</comment></comment><comment><USER70> _Magic Sorcerer Hat Mode:_ Part 2 is going to detail something like Plan 9, where you don't have to worry about where the disk is, or the information feed comes from; where authorization and authentication are baked into services - not tacked on later; where UI forms are composable, etc etc.

My surmise is that all of these things can be accomplished now with careful choices of how you do things.

And if you aren't Microsoft or Google, maybe you don't need to make Word or Excel on the web?

</comment><comment><USER71> Even though it's a bit forced, I agree that the whole mainstream computer field as a weird non ROI. Machines 10000x faster, personal value/productivity: flat or below.

<comment><USER3> How do you measure that, though?

It seems like you have to ignore all value derived from networks in order to come to the conclusion that software is no more powerful than in the 90s.

In the 90s I couldn't have met with my team, with members in Moscow, California, Pennsylvania, and Texas, in any reasonable way...today I can chat, including video and sound, on a whim!

Managing source code today is _massively_ more productive than in the 90s. CVS (or, heavens forbid, RCS) on a central server was how it was done back then, if you had revision control, at all. It's not merely a better revision control system (git), it's the web-based infrastructure around it (github/gitlab/web- based CI/whatever). That wouldn't be possible on any platform that's less connected and less widely available than the web.

The rise of package managers is another massive productivity booster that maybe goes unheeded (we all love them, but I think their productivity value is wildly underestimated...how else can you add 100,000 lines of code, that probably works, in a couple of minutes, and reliably allow every member of your team to do the same?). Web technologies have enabled that. There's a reason npm has the largest package selection the world has ever seen, and I think it's the massive interconnectivity of the web platform. (This feels sort of vaguely defined, I guess...but, there is a magic to the web platform.)

There's so many areas where we're more productive today because of the network effects of the web as a platform. Also, because the web is universal, I don't have to use Windows, ever. Everything I ever want to do has a Linux version. Anything that falls short of complete platform independence is probably a step backward, IMHO, even if it has other benefits like smaller/faster binary builds.

Also...WebAssembly is coming. We're going to see a fast/efficient web, long before a new platform could possibly be delivered.

<comment><USER54> The Internet != The Web.

Many of those benefits you listed are linked to the growth of the Internet. Package managers, video conferencing, distributed version control, all mostly Internet-based. The web is just one part of Internet activity. It's the part that requires use of a web browser. If you can do something online without using a web browser it's because of the Internet.

The criticisms that are being levelled at the web are related to it being an inefficient and insecure platform for applications. Note this is not Internet- enabled applications like package managers, but rather applications that run within the web. It might seem like a pedantic distinction, but it's a key one in understanding what's under fire.

<comment><USER3> I get that and tried to make it clear that I get that, particularly in the paragraph about npm; Perl has the CPAN, Python has had a half dozen package managers (I don't even know which one finally "stuck"), Ruby has gems, but _nothing_ exploded the way npm did. So, what's different? I would argue it's not that JavaScript is a better language (though it's a pretty strong language today). I would argue that it's a better platform, and that platform, ultimately, is the web.

Every package manager works over the internet. Only one represents the web-as- a-platform. And, it turns out that's the one that has dwarfed all others in size and scope, in a quite short time. Nearly everything I mentioned above requires the internet for interconnectivity, sure, but also a platform that delivers it to the user. Any platform for building apps that fails to deliver at least as much as the web will never be as successful as the web.

Edit: Also, desktop apps have had the Internet for decades. What have they done with it?

<comment><USER54> > "Also, desktop apps have had the Internet for decades. What have they done > with it?"

Automatic updates is the answer that springs to mind first. Is there something more they should be doing with the Internet?

The only other answer I could think of was 'social connectivity', but in the world of desktop apps, there's no major downside with splitting out social connectivity into separate apps. I don't care if a desktop 3D CAD application doesn't have chat functionality as there are specialist desktop applications for chatting online. Sharing a 3D model in a realtime online conversation is as simple as sharing a file.

<comment><USER3> So, this seems strange, to me, and maybe misses the point of the web entirely.

I'm not talking about bolted-on "social" features. There are entire multi- billion dollar industries built on categories of software that did not exist in 1990.

Google Docs isn't merely a word processor (spreadsheet, etc.) with social features...the "chat" is ancillary to the real benefits; it's an entirely different way to work with documents, and that's one of the examples of things that's extremely close to 80s/90s tech; it looks just like a word processor, and people from 1990 would know how to use it. But, it's not the same thing, and before it (and some other online document tools) came along, Word had _extremely_ limited sharing capabilities (requiring ridiculous intranet servers to host the shared docs, and it was basically the same as passing it around via email only with slightly better revision control). That's as close to a traditional app as you can find, and it is _still_ 100% more valuable for being on the web.

What would [ Youtube, facebook, Google Maps, Amazon, craigslist, Netflix, etc. ] look like in a desktop app, and why didn't they exist before they came to the web? The web is a unique (so far) platform with distinct benefits that aren't available to apps in that past. The reverse (desktop/native apps could do things web apps couldn't) was also true until relatively recently, but that's changing, though I don't think the interesting work is in porting native apps to web apps...people will do it, because they can, but the interesting work is in the new things made possible by the web itself.

<comment><USER54> > "Youtube, facebook, Google Maps, Amazon, craigslist, Netflix"

There's nothing stopping any of those being implemented as desktop apps. In the case of Netflix and Google Maps they already have equivalents on the desktop that are even more capable than their online equivalents, such as Kodi and Google Earth.

As for the collaborative document features of Google Docs, MS Office has this as well. The main benefit of Google Docs is its price.

</comment></comment></comment></comment></comment></comment></comment><comment><USER72> Sure, and what's your plan to replace the webapp? Remember, webapps replaced desktop distribution because they:

• Work on all platforms

• Run without installation

• Provide a quick development and update cycle

So whatever you'd like to replace the webapp with has to do at least _some_ of those things better. And unless it rolls out to nearly everyone who already has access to a web browser, you're going to be competing with the imperfect but "good enough" platform.

Further – the author criticizes open standards because they're not perfect. Sure, no one will be implementing the full HTML5 standard from scratch, and there's a lot of waste in what the W3C produces. But what's your proposed alternative? A return to closed, vendor-proprietary UI frameworks and DLL interfaces?

</comment><comment><USER73> The article doesn't make sense without an alternative. What open standard is being proposed to replace the open WWW?

Mobile apps and app stores are not a replacement for the open Web, and it can't reasonably be argued that locked-down mobile devices loaded with craplets and no root access are better than the WWW.

<comment><USER74> I agree, this article doesn't make any sense without proposing an alternative. Sure, I think most people would agree that the web is still a bit rough for (large) apps. (compared to desktop apps) But nothing that can't be fixed, right?

I can't imaging that native phone apps will still be popular in 10 years. I think that they will be replaced by the web in a similar fashion as web-apps have replaced desktop apps.

<comment><USER63> There are still popular desktop apps. Native Office is still used widely despite Google Docs and web versions of Office. Adobe applications are still widely used. Most programmers use desktop editors and IDEs. I use a lot of the Mac applications.

</comment></comment></comment><comment><USER75> I know it's cynical, but every time I see an "It's time to kill [x]" piece, I assume the author has some competing solution they're trying to hawk. In this case, very much no solutions are offered (but promised in future installments).

The web sucking is a symptom of its success, not an indication of some intrinsic inadequacy. HTML is fault-tolerant. JavaScript is an add-on, not a runtime requirement. CSS degrades gracefully. The web is resilient, forgiving, and accessible. And yeah, a little slow and broken, but so?

</comment><comment><USER76> Long live web apps. It's not that they need to be killed, it's that they are evolving and need/urge to evolve more. With so many OS, HTML works perfectly to distribute one single source-code in all platforms. I see it the other way around, "web apps" are here to stay and evolve.

</comment><comment><USER77> I just get sad knowing what I'm missing. I've worked with a bunch of desktop GUI builder IDEs (Visual Basic, .Net WinForms, WPF/XAML, and Qt) and I've seen the immense power they have in terms of developer productivity and application performance. Something like XAML is especially interesting because it brings the styling and responsiveness of HTML/CSS to the GUI builder paradigm. I started off with them and then have slowly transitioned to working entirely with web technologies (PHP, Rails, Angular, React, you name it). Not without reluctance for sure! It's a Faustian bargain to me -- trading off overall inferior technology and developer experience for the sheer reach and ease of deployment of the web. It's nuts to me to design a visual thing like a UI by writing lines of code. The GUI builders of yore really nailed this by allowing you to design something visual using a visual modality (drag n drop, realtime layout designers, etc.). I try to explain this folks who've only ever developed for web and usually their eyes glaze over. They can't seem to (or have an incentive not to?) appreciate the impedance mismatches and the fundamental trades being made with web user interfaces.

</comment><comment><USER78> I agree that the web platform is kind of messed up, but web apps are just so accessible and convenient...

For essential apps, I believe most people would always prefer native versions. They are more convenient that way. (I don't want my local media player to be a tab in Chrome.) People generally are not using Google Docs because they are robust or feature packed. They use them because they could just load it up in a few seconds on a new machine, with nothing to install and everything synced in the cloud.

Actually, I think if there is a platform which allows users to run ANY apps with just one click, it has to be a platform just like the web we have right now. Sure, if JavaScript were not made in a hurry, we could have got a lot of efforts spared - but dialects and attempts to "reimagine" and "personalize" our weapons are still going to show up, maybe just like all those frameworks and workflows we have right now. (Seriously, why are there so many NATIVE UI libraries? So many OS's? So many NATIVE programming languages?)

Yes, we ARE reinventing the wheels, but for a good reason - accessibility. All apps from every generation do similar things: typing docs, filling in spreadsheets, instant messaging, playing music... In fact, humans ALWAYS have done similar things - they wrote stuff and kept lists long before MS Office came along. The web is an upgrade, thanks to the better computing power we have to allow "inefficient" non-native rendering nowadays. The "native" apps we have now can do their fancy new 2017 stuff. Maybe soon we will have full blown AutoCAD as a web version. Many native apps we have today are almost awesome enough - the natural tendency would be to make them more accessible.

</comment><comment><USER79> > thesis [...] not talking about literally all web apps.

I think all my problems with this article are summed up in that paragraph. It's not so much that there're problems (there're of course) but it's just not the problems the author likes and thus goes into this exaggerating rhetoric.

Safe to say, I remain unconvinced about needing to kill the web and I'm sure whatever this guy suggests in the second part _will_ have its own share of problems, probably even the same ones. Because, as it turns out, the web isn't that special in that area; every platform has problems, some identical.

Also, his description of the state of the art in the 90s suggests that the guy isn't that familiar with desktop development today (kind of surprising, given what the author has worked on). Safe to say, efficient binaries that run on just a few MBs of RAM is a) not what happens today or b) hasn't changed much in the last 20 years. Depending on what application we're talking about.

Also when did the web lose on mobile and when did developers "near universally" choose to write native mobile applications?

</comment><comment><USER80> Excellent article. It's time to scream aloud that the emperor has no clothes. This farce has gone too far:

Most of the facilites for implementing a web app started as a quick and dirty hack, creating abuse of HTTP Forms, DOM manipulation, etc. Aided by Javascript, itself a hack (the creator was under heavy time pressure to deliver a language.)

We've built a whole empire using these flawed pieces.

I'm bookmarking this article.

<comment><USER81> What is your definition of flawed, then? It is the most widely used distribution network of applications.

Personally, I would argue the exact opposite. The web in its current state is a brilliant piece of technology that is vastly undervalued.

</comment></comment><comment><USER82> I'm working on one possible solution for application developers who don't really have much experience working with the complicated pipelines involved in building modern web applications.

It also makes it easier to support users without javascript enabled.

I'm calling it a Web Application Scripting Language, basically it's a template language to build interactive client-side applications that can also be rendered server-side (with actual data) without a javascript interpreter on the server.

I just pushed an updated documentation site which includes a mostly-functional TodoMVC demo.

[https://tmzt.github.io/isymtope/](https://tmzt.github.io/isymtope/)

The scripting language aspect of it is similar in some ways to elm, but does not expect a developer to be familiar with topics such as type theory and monads.

This version uses Redux and IncrementalDOM, but the actual functionality it's using in those libraries could easily be replaced with something smaller and more focused on the rehydrated HTML use case.

</comment><comment><USER37> The web became as popular as it did precisely _because_ it sucks. A lot of the supporting technologies made design decisions that favored easy of use over stability and things that experienced developers like. Every argument I hear about how the web sucks basically boils down to an argument that it should be more consistent and well-designed. But most well-designed technologies fail because engineering doesn't win the day -- delivery does. I say all this even though I consider myself an engineer with a penchant for the craft of writing software. I love beautifully architected systems, but I have to sadly admit that they're often not relevant to the bottom line.

I don't think it's time now or in the near future for the web to die. Just as we often still mindlessly adhere to the 80 character limit for terminal width, even though this limit has its origins in the size of punch cards, we'll still be using traditional web stack technologies decades from now.

</comment><comment><USER83> Kill the browser as an app platform and go back to installation/dll hell? No thanks :)

<comment><USER84> Statically-linked binaries would get around that. Not as space-efficient, but modern computers can afford to waste some storage.

This is basically already happening with Electron apps.

</comment></comment><comment><USER85> I wished the author had taken a more developmental view.

Personally, I think the web as it currently is, has a few shortcomings, but on the whole I feel it can be refined into something quite brilliant.

Also, with regards to the title "it's time to kill the web app", I feel the web app has only just started to emerge as a solid competitor to native. To kill it now would be a travesty! I believe that soon it will replace a large chunk of native apps and the innovation we will see in browser APIs in the next few years will be quite remarkable. I think the USP for the web is ubiquity and uniformity - having a single, uniform platform that runs on any machine while being unlimited in the variety and nature of things it's capable of. There are issues to be addressed (security being the obvious one), but still, to me web apps are a step in the right direction, not the wrong one!!

</comment><comment> a-dub annoying clickbait title and irrelevant trolltastic comparison to '90s windows garbage designed to incite anger.

1) yes, large webapps are hard to secure. but they're also infinitely easier to patch.

2) yes, the fact that google just shits out random things so people can get promotions (SPDY, NaCL, whatever) and it becomes a thing is a problem. this was not how the decentralized web was designed... but that doesn't mean that it's "time to kill the web."

<comment><USER86> You seem to be conflating the web with webapps.

<comment> a-dub nope.

<comment><USER86> > this was not how the decentralized web was designed... but that doesn't mean > that it's "time to kill the web."

Its not "time to kill the web", because that was never under consideration.

<comment> a-dub click the link and read the giant 18 point text heading. thx.

<comment><USER86> Ah, I assumed you read the article. So sorry..

<comment> a-dub i did. i started with the title.

</comment></comment></comment></comment></comment></comment></comment><comment><USER87> Yeah, I have been working on the web for 10 years. When I started, it was fun, because I knew nothing, and that seemed magical to me, but the more I work on this platform, the more I realize it's crap.

We are now at peak crap. Did you see all this JavaScript bullshit code needed nowadays to just render a fucking web page and fetch some data?

I hope OOP would die too, I mean, it's often an over-engineered bloat that only works for trivial Programming 101 courses (using Bike, Vehicle classes). In real world, I found OOP to make things messy with pseudo-objects like Service, Manager, (Abstract?!)Factory and so. Just using params and functions feels more natural I think.

Sorry for the rant. I think we all do an unbelievable job pushing these tools to their limits, but it's just made me sad that we may building on ugly foundations.

</comment><comment><USER88> From an engineering standpoint there are surely some valid points here but I have to say that I don't think things are all that bad.

HTML,CSS, and Javascript separate the layers of a web app fairly nicely.

It's all free for the learning and using and even distributing, and it comes with a huge community to lean on for support where many, if not most, of any questions you might have are already answered.

Those parts work pretty well and have a huge user and developer base. You don't just toss that out and tell everyone they need to start over. To even imagine that you first have to ignore the real value of it, which is truly immense. So much so that in reality you cannot ignore it so whatever you do has to be compatible with it, or at least accommodate it.

I have to admit this leaves me curious about what "Part 2" will offer.

<comment><USER89> > HTML,CSS, and Javascript separate the layers of a web app fairly nicely.

Except they don't. Most devs aren't even aware of what divs they are using for pure styling vs semantically correct ones. They think all the html they write is by definition semantic.

Then there are the less frequent but even more insidious cases where css is used for content.

<comment><USER88> Does that really make a difference?

Seems to me that's a feature that's generally described as "more than one way to do it" and the goal is getting the app working and shipped not to appease some outside critic's sense of semantics.

<comment><USER89> Styling separable from content is the direction W3 wants to go. So being aware and adhering as much as possible should improve performance and long-term maintenance burden.

I agree the tradeoff probably isn't worth the extra time needed to carefully structure your html and do css acrobatics.

I just get triggered when someone claims the holy trinity idea works good with html/css/js. It doesn't, but that's OK.

</comment></comment></comment></comment><comment><USER90> I agree with the premise but the problem is developing apps in any other ecosystem decreases your overall audience. You're either in the corporate world with their walled gardens, or in the FLOSS world where there's all sort of rough edges and things don't work as smoothly (and I say that with nothing but respect and admiration for all the well-meaning hard work from folks that's gone into both ecosystems, but it's the stark reality of matter).

The web is as close as we've gotten to making tech as user friendly _and_ accessible. I bet Mr. Hearn has a bunch of technical proposals lined up for part 2, but how we cross all the factionalism, corporate or idealogical, that's formed in the software community at large since the birth of the web?

</comment><comment><USER91> The creator of this post is the same guy who said bitcoin was dead in 2016 [1].

[1] [https://blog.plan99.net/the-resolution-of-the-bitcoin- experi...](https://blog.plan99.net/the-resolution-of-the-bitcoin-experiment- dabb30201f7)

</comment><comment><USER92> If you're trying to prove that a platform is unfixable and present as evidence the assertion that it's reinventing things from a previous era, you're doing it wrong. Even assuming it's true, reinventing in no way makes the platform unfixable. Quite the opposite; you're asserting it's being fixed.

If you're trying to prove that a platform can't be made secure and present as evidence security issues that have been made into non-issues (SQL injection, XSSI) you're doing it wrong.

If you're arguing that it's time to start over from scratch don't criticize things that could be fixed without starting over from scratch, e.g. lack of a binary RPC format.

</comment><comment><USER93> Until I can block ads in web apps, I'll keep my browser thanks.

<comment><USER69> And you can't block ads in youtube, instagram or fb apps.

</comment></comment><comment><USER94> Seriously? the web app is the most ubiquitous and flexible app on the planet; adapt or die.

<comment><USER95> No kidding. I'm at the point of almost exclusively developing webapps. Universal, instant, and powerful. It's the perfect platform.

<comment><USER63> It's really not. HTML and CSS are far from ideal for making applications. JS has gotten better, but it still lacking in some ways. And there is no IDE for the web, whereas Smalltalk had one in the 70s, and numerous ones have existed for other platforms since then.

<comment><USER96> Try VSCode it's one of the best IDE, it has code completion, built in documentation and even code autocomplete for JavaScript.

[https://imgur.com/a/26oFa](https://imgur.com/a/26oFa)

<comment><USER63> It's an IDE for a programming language, which is only part of the picture. Compare it to what the Flash IDE or Visual Basic offered developers. Or Smalltalk in terms of a fully customizable, live environment.

Maybe something that's a cross between Developer Tools, Flash Designer and the Smalltalk environment.

Anyway, VS Code isn't the development environment for the web. It's just one of many options for writing Javascript.

<comment><USER96> What would a dream tool for web development would look like to you?

Edit: VSCode is not for one language, it supports dozens and dozens of technologies... wait for it... for the web.

<comment><USER63> Yeah, I've tried it. I've also used Adobe tools and Visual Basic before, and some web layout/theme builders. So it's the IDE plus the visual building environment, with tools for animation and what not.

I also use Jupyter Notebooks, and having a rich REPL is great for prototyping and exploration.

So maybe something like the Smalltalk environment, where the environment is a fully customizeable web browser, and the language is your choice, which would get compiled to WASM or JS.

<comment><USER63> To clarify, it's the IDE plus the live environment plus the layout and design tools.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER97> > "Flux, the latest hot web framework from Facebook."

This guy is clearly not a web developer.

</comment><comment><USER98> At my last job, the app we were creating had both a web frontend and a Qt ui, so it was pretty easy to compare the relative difficulty of the two approaches since we were generally doing the same thing in both. Honestly it was kind of a wash. Qt was a little nicer as a developer because it meant never leaving visual studio, but I can't say that Qt offered some great advantage over HTML/CSS in terms of UI paradigm. I'm skeptical of this premise in that, yeah, the web isn't that great a development platform, but the alternatives aren't significantly better overall.

<comment><USER89> You can program in much more complex scaling behavior. Bet you just tested on a single 21" monitor at 96dpi.

</comment></comment><comment><USER99> During the last 20 years I used to prefer web apps over native (C++, Java, C#) for banking and trading applications. (although most developers didn't like to fight browser incompatibilities).

2 years ago I changed my opinion. We've developed two different user interfaces for trading at the same time. One with HTML5, Typescript, Angular, WebSockets, and the other one with JavaFX. The developement of the JavaFX based application was way cheaper, faster, pleased users more (due to multi- window!) and had by an order of magnitude fewer glitches in the UI. (But the web application was prettier).

</comment><comment><USER100> If, as the article (and much of this thread) seems to suggest, the problem we are trying to solve is

1) Serving a GUI application to multiple users in a way that they can trust

2) Maintaining up to date versions without client side updates

3) Storage of data on a remote server over the internet, enabling saas etc.

4) Easier GUI development using an IDE.

This points to needing something more akin to Citrix/RDP/Terminal services. Run full blown GUI apps on the server and serve an image of them over the network. This needn't be as bloated as the MS implementation, but seems to solve those issues above

</comment><comment><USER101> He's spot-on with a lot of his analysis, including security around REST/JSON. A few weeks back, I made similar, though less-detailed comments on another HN- thread, particularly in a SPA context.

The responses I received were essentially "it's not a problem if you do it right". But, of course it's inherently less secure when you now have data flying off of the server to be rendered on the client vs. consuming it all on the server and rendering the view there. You're kind of doubly-exposed.

It's not that there are no techniques for attempting to secure it. It's that it adds more complexity and that it's easier to leak data to your client (or an unsanctioned client) without realizing it. Because, of course a REST endpoint just sitting there on the open Web, intended to serve up raw data to an app is less secure than an app that holds on to its data and serves up text/html requests. So, with a SPA app, you'll find yourself doing a lot of things twice (client and server side), and that includes security.

The arcaneness of the techniques for securing all of this that he mentions is also accurate. It just amplifies the problem. The Web was not designed to be an application platform, let alone a secure one. It's hard to ignore this fact in any earnest discussion.

</comment><comment><USER102> The "unfixable design flaws in the web platform itself" that enable HEIST attack are trivially fixed by disabling third-party cookies, on the client side — in the browser's settings, and on the server side — by using SameSite tag in the Set-Cookie header.

I'm just left wondering why browser vendors don't apply this behavior by default, it would've been much cheaper to fix the broken sites than mitigating the security hell that 3rd-party cookies provide.

</comment><comment><USER103> You would think text documents work wonderfully but weirdest parts of html [to me] are...

1) the rendering of things outside the viewport. The way wrapping of divs and lines works it seems impossible to make it render the way pdf did from day 1(?) I don't even know if there is a maximum length for pdf but in html you really should try to stay under 20 000 lines. I know, it seems like I'm splitting hairs here, but before the early 90's you could easily scroll though the entire memory of the system as if it was a single document. The amount of code was kind of a lot smaller than the infinite scroll web page requesting pre-cut chunks of xml or json where you get to manually measure the size of elements then get to do crazy calculations with the scroll offset if a new element needs to be inserted above the stuff the user is looking at.

And 2) not having a nice way of doing a reference section summarizing the stuff linked in a text kind of ruins the joy of having links in the text. One ends up building a kind of disposable experience if the text is long enough.

Combined, it's like having a pile of pages that are all the entry point. This is lovely for short reads but far from what books use to be.

I suppose the ultimate creation is one such article that promises everyone a fire breathing pony with laser eyes in the soon to follow up.

When you write one, be sure to rage at the thing everyone loves and to suggest abolishing it - to be replaced by that pony you will get in the next episode!

I for one am all ready to be disappointed by this holy grail of subscribe baiting.

</comment><comment><USER104> > The fix: All buffers should be length prefixed from database, to frontend > server, to user interface.

If you think that that is a solution to anything, you must be living in a universe where ASN.1 implementations have not ever had bugs, in particular they must never have had any vulnerabilities.

It's certainly not the universe that I live in.

In that same universe, packet sniffers/protocol disectors probably also never had any vulnerabilities due to blindly trusting length values?

</comment><comment><USER105> If we're going to kill the web, can we start by forming design principles instead of retrofitting patches on the existing design?

For instance, a great principle would be to minimize shared knowledge. Having a giant pre-shared base (i.e. browser) not only restricts what I can build and how, but also stifles evolution and innovation, because the whole world has to be upgraded to the same ginormous 'standard' for us to talk to each other.

</comment><comment> Chiba-City The Web is a failure of cheap tool distribution by attention seekers distracting possibly greater talents wasted on short lived skills or failed projects.

We mostly lack use-case qualification, support metrics, documentary weight or programmatic contract between tool makers and users. None should take commercial interest in tools without references, tutorials, cookbooks, i18n support and road maps shared between stakeholders.

The ecosystem of Unix and Windows literature was exceedingly well written and stable. Backward compatibility was important or breaking changes well flagged. Real software for profitable operations (not entertainment) requires stakeholder analyses for costs, adaption cycles, business models, risk and so forth (no screens or code yet) taking weeks or months even in "move fast startup" mode. Chasing tooling and testing against API changes in a code dump is unwise.

Sadly pop promotional blogs make breathless lottery winning with "bailing wire and chewing gum" seem desirable or probable. That's nonsense. We never need hear more "dorm room miracle" stories or "DB2 rewritten in Forth" fantasies. Anything rushed is a bad bet for talents wasted on shifting sands. The use- cases absolutely matter for tool applicability in a multi-stakeholder (contract obligations) profitable operation. Everything else is a distraction.

I suspect voices of endless tool fetish, "exploratory programming," consumer gaming and "content scripting" might disagree. They do not matter. Those people suffer special needs. The Web as a tool platform has mostly failed. The most "convenient" tools for people measuring fake productivity in keystrokes have failed the hardest. [Edit: typos]

</comment><comment><USER106> I'm tired of seeing this same article on HN every week.

I've begun to feel that a lot of HN is stuck in 2010, a lot of people refusing to adapt to a changing industry who want me to get off their lawn.

I'm in desperate need of some links to alternatives. Perhaps something with the same vibe as this site had several years ago.

Not to say there isn't still a lot of good discussion on here. But at least when it comes to the web there's far too much noise. It's toxic.

</comment><comment><USER107> I deleted Facebook from my iphone because i don't want to give them that much access, and now only use their web app on my iphone. And it's horrible _. If Facebook can't get it right, who can?

_ My latest example is from 30 minutes ago, where I tried uploading s video; and almost gave up after 5 mins. The UI was hard to understand, extremely slow and never let me understand what was happening.

Professionally I'm an iOS lead on a dual platform (iOS @ Android) app that has hundreds of thousands of users. I've occasionally wondered about whether we should switch to React Bative and using Web Facebook always cures me of that idea.

And the fact that i've spent hundreds of hours optimizing our app and every view to ensure they launch and open as quickly as possible, down to managing every bit of memory use as ruthlessly as possible. And letting our users use our app offline. Every second costs us users and dollars.

Then there are new technologies like ARKit. Native is still the best way to go if you can afford the time and people to do it the best way possible.

<comment><USER108> Facebook has decent incentive to move people from their web app to their mobile app.

</comment></comment><comment><USER13> Call me when some other platform gets:

1) sub-100ms installs and upgrades

2) a secure sandbox in which to run untrustworthy code

3) distribution without gatekeepers

Until then every other platform is playing catch up.

And maybe in the meantime ask yourself why is the web so popular if it's so bad? Is it just complete stupidity, or is there maybe some form of natural selection happening and you're not understanding the fitness function?

</comment><comment><USER109>
      "...unless you work at Google or Microsoft you can't meaningfully impact the technical direction of the web"

I think this is a great argument for why we need a (for lack of a better name) "meta-browser". An application on the user's machine that contains and runs browsers. Then flip the control to the developer. If I'm only going to design for [name of obscure but super secure browser], my success doesn't have to be dictated by the fact that 99.99% of users didn't originally open my browser of choice. If they come across a page only supported by this little-known browser, they are prompted that they can install it, or they can decide to move on to the next website if the developers didn't write any fallback.

This doesn't just ensure the web can remain open, but makes the whole architecture (the web itself) an open question and allows all aspects of "the web" to evolve more smoothly.

</comment><comment><USER110> This reads like an article about web applications written by somebody who doesn't have any meaningful amount of experience writing web applications (which I've just seen he admits further down in the comments). The number of false statements and false assumptions in just the first section is enough to make it hard for me to continue reading, since it's supposedly the foundation for the rest of the suggestions.

> Web apps can't use real sockets.

Because security is an important consideration, and websockets are designed to live within the constraints of the same-origin policy, which helps immensely in creating apps that are secure by default.

> Things as basic as UI components are a disaster zone. [Links to article > about web components]

Web components are a failed/failing/doomed (IMO) proposed standard and are nothing but an implementation of the idea of UI components. The design of web components is about building component object hierarchies, and is doomed to fail (IMO) in a markup language built around content composition. Saying UI components are a disaster because (one guy says, though I agree) web components are a disaster is like saying "a square won't fit here, so obviously no rectangles will fit."

> HTML5 has peer to peer video streaming

No, it doesn't. Browsers support the completely-separate WebRTC specification and its related javascript APIs. No HTML spec says anything about WebRTC.

My suggestion would be that if you want to replace something, you need to actually grok it first, or at least have a sufficient understanding of the complexities (and the reasons they exist) you're trying to argue against. Otherwise it's way too easy to point out that you don't really know what you're asking to replace, and your opinions, while potentially valid, are going to be tossed with the rest of the bath water.

<comment><USER17> > Web components are a failed/failing/doomed (IMO) proposed standard and have > nothing to do with the common UI component frameworks that exist today. The > design of web components is about building component object hierarchies, and > is doomed to fail (IMO) in a markup language that excels at composition.

1\. Exactly

2\. Instead of building a set of native (to the platform) common UI elements w3c ended up ckreating an incomplete low-level API for something, no one knows what exactly.

3\. Existing UI frameworks re-invent a huge amount of things, poorly and inconsistently.

</comment></comment><comment><USER81> This article addresses web apps at the micro level. Comparing a React based webapp to a 20-year old UI, the end result. It fails to address distribution. How did that UI end op on your display? Through 13 floppy disks. How did the React based web app end up on your display? In the blink of an eye. Distribution is key. Real artists ship.

</comment><comment><USER111> ... I feel like I've read the same about terminal apps, tons of programming languages, etc. and it's again missing the point.

Nothing is reinventing anything. The code you write these days in Go, JavaScript whatever is still following the same principles as in the 1980s. All we do is swap out tools and languages, add comfort.

</comment><comment><USER112> I agree that the web is kind of a catastrophe. However, the problem is not really that it confused documents and apps. I would actually like to see this distinction get blurrier, in the form of better support for active documents, ranging from interactive illustrations of ideas to spreadsheets with formulas.

</comment><comment><USER113> > _This is why the web lost on mobile: when presented with competing platforms > that were actually designed instead of organically grown, developers almost > universally chose to go native._

almost universally?

mobile dev has enough inefficiencies and complications that, for many use cases, quite a few people today wonder if native is preferable to mobile web, especially PWAs.

i mean, look at the discussion here, 12 days ago: [https://news.ycombinator.com/item?id=15219154](https://news.ycombinator.com/item?id=15219154) and this: [https://joreteg.com/blog/betting-on-the-web#what-sucks- about...](https://joreteg.com/blog/betting-on-the-web#what-sucks-about-apps)

</comment><comment><USER114> Some of the assertions from the author about how things were in the past are pretty off. Office 2000 wasn't happy with 75 MHz and 32 MB ram at all. I would say the average computer at that time was at least 200MHz with 128MB of RAM.

In addition in 1995, developer "platforms" were rarely Windows-based. Borland was still hugely popular at that time, and DOS-based compilers were still big. The assertions he makes about the developer platforms are a complete joke: "Support for graphing of data, theming, 3D graphics" were completely not a thing, nor was "Sophisticated support for multi-language software components".

I'm pretty sure the author didn't develop back in 1995.

</comment><comment><USER115> >But Office 2000 was happy with a 75 Mhz CPU and 32mb of RAM, whereas the Google Docs shown above is using a 2.5Ghz CPU and almost exactly 10x more RAM.

The pixel count of that win 98 screenshot could probably fit in the top left corner of the menu in google docs.

</comment><comment><USER116> You can't kill the web, it has to die of natural causes. Even if everyone agreed to abandon the web tomorrow we couldn't.

Make a good replacement for the web, get everyone to _want_ to switch, and then migrate. You might accomplish this in 10 years.

</comment><comment><USER117> Just my opinion, but developing for the web is much easier than building native mobile applications. This is a good thing from my point of view. Native development has some catching up to do in this respect.

</comment><comment><USER97> > All this adds up. I feel a lot more productive when I'm writing desktop apps > (even including the various "taxes" you are expected to pay, like making > icons for your file types).

That made me remember something: compatibility. I like web apps because they will run on my Linux machine and on all other people's Windows machines. What is your solution to that, angry guy from the article?

Also, please provide solutions to:

* the dangers of installing other people's software to your computer -- dangers that practically inexist in web apps; * the friction of getting people to try out your apps.

</comment><comment><USER17> One of my rants is linked in the article (Failed promise of Web Components).

Here are two more rants on the insanity of the web and what we could probably do with it:

\- [https://medium.com/@dmitriid/w3c-and-whatwg-should-die-a- qui...](https://medium.com/@dmitriid/w3c-and-whatwg-should-die-a-quick-and- horrible-death-a7cff5e1da8f)

\- [https://medium.com/@dmitriid/ok-w3c-and-whatwg-dont-die- but-...](https://medium.com/@dmitriid/ok-w3c-and-whatwg-dont-die- but-7952221fcbe4)

</comment><comment><USER118> I'm surprised no one has mentioned same-site cookies. This would help a lot with privacy and mostly solve BREACH, CRIME, HEIST, CSRF, mime-confusion, JSON issues, etc.

[https://www.owasp.org/index.php/SameSite](https://www.owasp.org/index.php/SameSite)

It wouldn't solve XSS or SQL injection, but native apps are just as vulnerable to SQL injection as html5 apps, so I'm not sure why the author brings that up.

I'm curious what the author will propose as the solution.

</comment><comment><USER119> > _Hence my conclusion: if you can't hire web devs that understand how to > write secure web apps then writing secure web apps is impossible._

Furthermore, the web devs that understand how hard it is to write secure web apps generally don't want to do it for a living.

I've found that the most straightforward way of avoiding problems on the web is to sidestep them as much as possible. Draw UI with canvas or WebGL, overlay native widgets, use RPC over a WebSocket for everything except for public assets.

</comment><comment><USER120> When you've got things like new multi threaded renderers, all browsers now 64bit, web assembly, service workers, faster processors etc. It seems that in actuality app development with web technologies is finally practical.

But, why are these things framed as an either or? Surely the best thing is always to use the best technology for the job and in many cases the speed and security trade off is worth it in order to utilise existing assets and expertise from a businesses web application.

</comment><comment><USER121> The biggest advantage for a hobbist developer like me is that web development makes a single code base possible. One code base runs on phones, tablets, desktop, across OSs etc. It would be impossible for me to write and distribute solutions otherwise. Multiple programming languages, deployment overhead across app stores etc.

I miss the provision of notifications the most. With PWA I can cover Android, but I don't think anyone allows notifications from websites (I don't).

</comment><comment><USER122> The fact that this article is written and distributed with medium (web app) invalidates everything the author says.

It's working fine, you are using it, and millions of other people are happily using it. Web is great for users because they can do arbitrary operations with just a browser without needing to install anything.

I don't know about you, but I build web apps to help users, so it's okay for me to suffer a little pain to make users happy as a developer.

</comment><comment><USER123> Security is probably not the exact same thing as it was on desktops.. However anyone who's been burned by a Javascript miner (like on the pirate Bay) or whose data is mined for ad revenue knows that the web exposes you to a series of lesser assaults which we shrug off typically. Just because breaches in privacy and security are not as flashy as waking up to a computer which won't boot doesn't mean web apps are secure.

</comment><comment><USER124> People who hate have either a severe depression or try to get easy attention.

Why hating web apps? Every app has their advantages.

\- Native apps are great and I couldn't imagine how Sketch, Snapchat, etc. could be done as a web app

\- Web apps are great because I wouldn't want to install apps just for those I use once in while or apps where I rather consume than interact

\- Console apps are great when I focus on raw text manipulation and they get even better when working on remote servers

So, why they hate?

</comment><comment><USER125> We definitely don't have a replacement for the web on the presentation layer. Likewise, we're stuck with web services for now for the display services sitting immediately behind the frontend. But for pure backend services, there are plenty of alternatives to HTTP that are ready to use today and more sane. There just isn't a ratified "standard" yet (outside of large tech companies, which tend to have their own).

</comment><comment><USER126> > The fix: All buffers should be length prefixed from database

How does this fix anything? When you compose length prefixed data (in e.g. arrays, nested stucts) you still have to check if these length and offset fields are coherent. If these length fields get passed over the wire from the user, you still can't trust their values.

Binary protocols don't solve this problem, they just make doing the validation less CPU hungry.

</comment><comment><USER127> This is a WEB APP [https://3d.delavega.us](https://3d.delavega.us) using 3js. It can run on most iOS and Android smartphones, most Windows and macOS machines and Linux computers.

It is likely to run on over a billion devices.

It should just take a few hours to a few days to code depending on your coding skill level. Did I mention no installation required.

Can a non web app or native app be better than this?

</comment><comment><USER128> I wonder if there's a market for a WebApp store. Like a curated WebApp library - centralized billing, some form of vetting before apps can be listed, maybe even some apis for notifications or whatever. WebApps tested on a few major browsers and platforms before they're allowed to be listed. I'd probably be more willing to pay for WebApps if they were delivered that way.

<comment><USER129> Most consumers don't know the difference between a web app and a native app, so no one would care

</comment></comment><comment><USER130> Web app may not be as good as you wish, but I think GUI app development either on desktop or mobile is definitely worse. Otherwise there won't be a market for hybrid apps. For those desktop app guys who haven't heard of vue, spend some time going through its guide, you will find web development is actually much more advanced than anything you are using.

</comment><comment><USER131> I almost signed up for that site, only so I could respond to that article. Why kill the platform that can be accessed from devices available to everyone, everywhere. Cross platform support on applications is taxing, even with an engine like unity that offers multiplatform builds, if you want to get a product in the hands of the world, you build it on the web.

</comment><comment><USER132> The web 'lost' mobile because there is no way for Apple and Google to scoop up 30% of app sales when there aren't any.

</comment><comment><USER133> There is only ONE major thing that's bad with web apps: you have to trust the server. Which makes them unusable for truly secure applications like bitcoin clients. Because you can always say you didn't authorize an action!

I think the future is IPFS and other content-addressable protocols. Why aren't browsers adding them to the web alongside https?

</comment><comment><USER134> The web is our best bet to converge to a single platform.

I find it extremely intellectually unfulfilling to write my code for three platforms (web/Android/iOS) instead of just one. So until there is a better common denominator, the web is my first choice, because at least it is accessible from all three platforms, and from the desktop.

</comment><comment><USER135> Agreed. This is why I'm retraining myself on C# in 2017. Native is better and the web should remain a primarily lean and fast text document delivery system. I'm loving C#/.Net so far, It's almost as good as Java serverside but has the (well-supported) ability to natively produce iOS and Windows apps (the two most important platforms IMO). One stop shop, and it's output is native code. It'll also support wasm when that's a widely used thing as well. Having to learn one platform like Java or C# and work out the rest of my career is a bonus too. I've had it with fashionable technology one year to the next and I certainly don't want to maintain these leaning Tower of Pisa stacks. Not to mention, on a similar chord as the author stated, we learned a lot of lessons over the decades. Part of that lesson is industrial-strength tooling (IDEs) and languages (typed) are important.

C#, Java or discard IMO for most greenfield projects. At least if I'm to maintain it longterm. Others may differ and that's fine, but at least all of this is my philosophy at this point with everything that I've seen and experienced. I'm really looking forward to his part two.

</comment><comment><USER136> I found the article convincing.

Taking a step back to look at the big picture, does the current evolution of js, html and server technology seem to be headed somewhere great? Seems to me we will soon need large AI stacks just to assist in reading these jumbled stacks of code.

I would have thought software would evolve toward simplicity by now.

<comment><USER137> > Taking a step back to look at the big picture, does the current evolution of > js, html and server technology seem to be headed sonewhere great?

Yes.

The current evolution of web app dev practices and popular frameworks doesn't, but that's a different thing.

</comment></comment><comment><USER138> All the more reason to switch to Urbit. Have you accepted Curtis Yarvin into your heart as your personal BDFL yet?

<comment><USER139> As soon as it does something useful, sure. As a power user I could not be any less interested in whatever I've been able to understand Urbit does.

<comment><USER138> Sorry, forgot the '/s'. :)

</comment></comment></comment><comment><USER140> One advantage of the web is that you can browse, discover, and test new apps directly inside your browser without needing to install anything on your system. Image you had to install a software any time you visit a new interactive website or check out a new webapp.

I'm curious to see the second part of the article!

<comment><USER141> Sure, that is an advantage but I wouldn't say it is a strong advantage.

With app stores I can view screenshots and videos before installing the software. The app runs in a sandbox and I can uninstall it very easily.

</comment></comment><comment><USER142> First of all, there is nothing called web app, this are called websites, that makes sense that the author is more likely to like app's for everything.

Yet web has no alternatives for what it supposed to do, so lets not try to fix it, as it is not broken. and possibilities of web technologies are limitless.

</comment><comment><USER143> On the contrary, from the users pov the vast majority of mobile apps are inferior to a webapp. Downloading apps instead of pointing a browser to an address, while giving all kinds of control (permissions and access to the device itself) to app publishers is just silly.

</comment><comment><USER144> > "Buffers that don't specify their length" This is a good thing. You just > need proper escaping. To parse data with length field you need higher-level > automata (maybe even Turing-complete parser) than for delimited or > quoted/brace-enclosed data.

</comment><comment><USER141> What if Facebook provided a way for React Native apps to be compiled to Windows and Mac desktop applications? If such apps were lightweight and could be automatically updated, would React Native development be a serious alternative to web app development?

</comment><comment><USER145> Reminder me of this article from Wired... back in 2010 "The Web is Dead" [https://www.wired.com/2010/08/ff_webrip/](https://www.wired.com/2010/08/ff_webrip/)

</comment><comment><USER146> "So unless you work at Google or Microsoft you can't meaningfully impact the technical direction of the web"

If this is truly what you believe. You are the problem. Killing the current system does not solve anything, proposing a solution and building it does.

</comment><comment><USER147> > All buffers should be length prefixed

Fortran called that a Hollerith constant, but that was 60 years ago.

[https://en.m.wikipedia.org/wiki/Hollerith_constant](https://en.m.wikipedia.org/wiki/Hollerith_constant)

</comment><comment><USER148> Why web Apps? Because you can hit just about every platform with one codebase, you got instant distribution, you got near universal compatibility. And, If you are inclined, you have minimal licensing.

Desktop has big compatibility cross/platform hurdles (does it run on Linux, MacOS, Windows, Android, iOS, and Playstation?), difficult distribution, and at times licensing (even moreso on walled-garden platforms).

You are also dependent on the desktop/PC manufacturer (ever have Microsoft, Apple, Google, etc pull the rug from under your product? it happens regularly especially with OS updates and "trusted" platform initiatives) Not to mention the development platform whims ("Sorry guys, we are selling to MS. We're sure they'll keep those MacOS and Linux versions up to-date, they are really excited about it!")

Maybe if its a open platform with high adoption on the scale of LibreOffice or GIMP... maybe.

</comment><comment><USER149> We are using a stateless document model for apps. You can select text on buttons. Madness.

</comment><comment><USER150> > First, use an XSRF token as discussed earlier to make sure that JSON results > containing confidential data are only returned to your own pages.

Is this necessary for GET requests that return JSON? You need to include a XSRF token in the request headers?

<comment><USER56> Ideally browsers should block cross-domain requests by default (so no XSRF is possible), but sadly this would break compatibility with older sites. Maybe we should make new HTTP methods (like SAFEPOST) with builtin XSRF protection and switch new apps to them?

</comment></comment><comment><USER141> I'm showing my age here, but I think Sun had the right objective with Java Web Start. Unfortunately their implementation was awful - bloated, slow, ugly, with a complicated API and poor security.

I think there is still an opportunity to do it right.

</comment><comment><USER151> I was about to say, it's time to kill monolithic native apps that live behind DRM'ed App Stores, can't talk to one another effectively, can't be composed, must be explicitly managed by users lest they run out of storage, and have an enormous transactional cost to trying them out.

Or I could point out that explicitly designed application protocols with native clients over the years have also shown themselves vulnerable to attack (e.g. IMAP, SMTP, etc), or that most of the attacks on the Web have not been XSS/XSRF but server-side hacks. Or that Android's native app platform is full of malware and viruses that even Google hasn't been able to completely eliminate with deep scanning.

Is the price of security that we throw away the Web and HTTP and implement everything as silo'ed IOS style monolithic apps? It's a price too high to pay in my opinion.

<comment><USER152> Personally, I vastly prefer the iOS ecosystem precisely because apps are silo'd and sandboxed. I have never had to worry about whether I can store data securely on my phone, never had to worry whether any particular app I've installed is going to do something nefarious to the underlying filesystem or to other apps, never had to bog down my device with (largely bullshit) anti- virus / anti-malware apps or anything like that.

iOS apps Just Work™, and incidentally the "transactional cost" of just tapping a button once to install any particular app hardly seems onerous to me.

And the fact remains, as is always the case with these debates, that the uncountably vast majority of users could not care less about the underlying technology that lets them play Candy Crush. Nobody is ever going to build a mass-market consumer product targeted specifically at people like you or me regardless of what preferences we have. All users want to know is that their device works the way they expect it to work and is as easy as possible to manipulate.

Having said that, I'd be interested to hear you expand further on what price you think you're actually paying and why you consider it to be too high. What is it about the iOS model that's holding you back so much, and how do those drawbacks outweigh the benefits? In concrete, real-world terms, what is your use case?

<comment><USER151> Web surfing is called "surfing" for a reason, like channel surfing, you never have to worry about the cost of an install, there is very little barriers to moving between apps. You flip effortlessly between sites and simply hitting the back button or closing the tab ends the experience. When Google serves up a surf result, there's never any fear that a click is going to require work in the future.

That is not the case on a mobile native app. Installing an app is a promise for you to perform janitorial work in the future cleaning it up. It creates needless shitwork that the browser cache model does not impose on the user. Native apps take up permanent screen real estate and storage. I know plenty of people who eventually run out of space and then have to go on a spring cleaning adventure to delete unused stuff.

Do you have a 16gb, 32gb, or 128gb phone? You probably know and care when you buy one. But you probably don't know how big your browser cache is nor do you care (or need to).

Likewise, if you switch devices, in a browser, you do nothing. Quite literally, you can drop your Chromebook in a river, open up another, and proceed almost instantly. Does iOS backups and Handoff/Continuity deliver the same experience? No.

Web apps are ephemeral by nature. They can be cached, but they don't need permanent installation to work.

Web apps can be composed easily, because links are relatively transparent and as a web programmer you actually have to do extra work to hide links from people (and Web 1.0 made it impossible). This means connecting one app into another is a benefit, not a hindrance, and the Web was somewhat self documenting of its integration points. Deep linking in native apps is no where near advanced, and navigating between native apps with deep links is very clumsy.

Web apps also tend to support encapsulation better. It's far easier to embed a third party resource, an image asset, a gadget, a banner, than it is in any native app model. Look at the way people embed status indicators on GitHub pages, now try to find the equivalent in ANY native UI that doesn't work by just embedding a Web view.

Let me give you an example of a world simply not possible in iOS. Let's call it Augmented World. In the future, I walk around with phone, or special goggles. When I turn on the camera, any physical object in my world, any location, can have code associated with it. Perhaps I walk up to a vending machine, and the mere act of observing it, presents with me with a 3D menu overlay that lets me order or pay. Or perhaps I walk into a restaurant or cafe, and when I look at the tablet, I can see an interactive menu, perhaps even an NPC interactive hostess.

iOS today is a HUGE barrier to location based commerce. Do I want to install a new app everytime I work into a Chipotles, Five Guys, StarBucks? Why do I need one app per white-label store? And do you realize how this just doesn't scale if mobile commerce progressed to the point where every brick and mortar has a separate app? China solved this by just not using iOS, and simply using QR codes, WeChat, and Javascript/HTML embedding.

If you want any kind of ecosystem that can scale to single-use non-repetitive experiences, like the small shop, it cannot be a system which effectively bans dynamic code loading and execution.

iOS is nice for games and for certain high performance productivity apps, the same way I still run native apps on Windows for say, Overwatch, or Adobe Premiere. But native apps are _overkill_ for something you only will use once. Android Instant is the closest thing approaching the Web for mobile that can handle these kinds of experiences.

If you want the kind of cyberspace envisioned 20 years ago in sci-fi novels, of exploring a vast, network, and teleporting into experiences effortlessly, it ain't the App Store you see in Neuromancer, or in Vinge novels.

</comment></comment></comment><comment><USER153> How about using an app:// protocol for compiled apps with security in mind, meaning sandboxed and no filesystem access? Http is for hyper TEXT, not hyper BYTES.

Wasm is a great opportunity to reinvent web apps. Please don't fuck it up.

<comment><USER154> how many things have been described so far as "sandboxed no file system access" yet the sandbox is breached?

</comment></comment><comment><USER155> So... am I mistaken, or didn't the W3C try to replace the web as we know it today, with XHTML? Didn't that fail?

I don't doubt that the author knows their web history, but reading this, it's like they've got their blinders on.

</comment><comment><USER156> There are lot of bad things here.

Main reason for web apps stay : they can evolve without a distribution life cycle.

Around REST and RPC : No what you see on the web is not REST. And please stop bringing back RPC. It was a bad idea before, it is still a bad idea.

</comment><comment><USER157> > Way back then, the web was locked in a competition with other proprietary > platforms like Flash, Shockwave and Java

Maybe this is just semantics, but it sounds like "web" is being used as synonymous with "JavaScript."

</comment><comment><USER158> Only the giant companies have the power to recreate the web. If they do it will be first and foremost better for their businesses. I don't even want to think about the influence of the secret services of the world.

</comment><comment><USER159> The author is not even mentioning _the_ reason Web apps become prevalent, even in B2B and Enterprise: deployment. _Not_ having to deal with upgrading hundreds of workstations to the latest release.

</comment><comment><USER160> > For the first time, a meaningful number of developers are openly questioning > the web platform.

Definitely not true. People were questioning the web app before there were a meaningful amount of web apps.

</comment><comment><USER161> The fact that I couldn't read this because it redirected me to a Medium web app that I wasn't logged into told me everything I needed to know about the article.

The medium remains the massage.

</comment><comment><USER60> My understanding of HEIST is that it is completely defeated by disabling compression on dynamic content. That doesn't seem to be "the end of the web" to me...

</comment><comment><USER162> silly author - sandboxed binary apps won't solve the problem. your whinges about client-server communication are inherent to, you know, clients and servers. whether the thing on the client side is real app or a web app is irrelevant. what matters is the communication. imagine if that channel could only carry keyboard/pointer input events to the server and static images in return. yep, that would be pretty robust.

</comment><comment><USER46> There is a section heading that reads, "Why the web must die." I almost stopped reading there. I value the web for its longevity, accessibility, and non-proprietary nature.

There are some goods points made in this article, however:

> _My experience has been that attempting to hire a web developer that has > even heard of all [the above-mentioned security] landmines always ends in > failure, let alone hiring one who can reliably avoid them. Hence my > conclusion: if you can't hire web devs that understand how to write secure > web apps then writing secure web apps is impossible._

</comment><comment><USER163> i've been talking about this for ages, but i'm glad people agree with me now. the web is a really shitty application platform. let's do something about it, eh?

[https://sunshinegardens.org/@xj9](https://sunshinegardens.org/@xj9)

[https://heropunch.io/ln/work](https://heropunch.io/ln/work)

</comment><comment><USER164> In my experience, web apps perform way better than native apps. The other problem with native apps is that they need to be installed before use.

</comment><comment><USER165> Nothing you've wrote here is surprising to me. I've never found the web app drumbeat to be compelling. The insistence that it's the be all end all is myopic and usually the domain of those who are trying to protect turf rather than create great experiences that are secure, powerful, pleasing and fantastically useful.

Thank you for stepping up as a full stack developer and presenting a case without obvious bias in favor of the one web to rule them all. I appreciate it.

John-Michael Scott - a guy who's been around a long time and watch this app evolve...

</comment><comment><USER166> I don't know how many times I can read a "web apps are bad because the flux pattern is from 90's windows" articles

</comment><comment><USER167> > a meaningful number of developers are openly questioning the web platform.

And then going back to building their products. On GitHub.

Oh, wait.

</comment><comment><USER168> The only reason I do React-Native apps instead oft web apps now is, the RN ones pay better.

I'd love to keep doing web apps.

</comment><comment><USER169> The web app is the best we have. Please give us an alternative or else it's not actually time to kill it.

</comment><comment><USER170> Uh huh. Well until you have another platform installed on anywhere near as many devices I wish you luck.

</comment><comment><USER171> I guess we shouldn't drive cars anymore because the auto-fatality rate is still greater than zero.

</comment><comment><USER172> I think having separate browsers for web documents and web apps could solve half of the issues.

</comment><comment><USER173> How did this article end up at the top of HN with so many points? It is a misinformed troll.

</comment><comment><USER174> It's time to kill t̶h̶e̶ ̶w̶e̶b̶ rants with little substance on medium platform.

</comment><comment><USER175> The internet existed long before the web and there are other protocols than HTTP - TCP/IP, UDP, SSH, telnet, etc. Desktop applications are still built that use the internet for communication but don't try to ram everything through an HTML document. And they're usually far-superior to webapp versions.

But now many people think that things should all be web-only, over HTTPS only. We built a palace of many ports and protocols, but we've locked ourselves away in one bedroom as our own prisoner. Despite a perfectly nice dining room with silverware and dishes, we instead scoop our food off the mattress with our hands because a firewall or NAT might prevent us from getting to the dining room.

Where the web does claim superiority, and why everyone now wants to use it to build applications that are totally unsuited for it, is primarily four things:

1\. Run-anywhere cross-platform compatibility. This could be addressed by better cross-platform compilation and cross-platform UI/UX for native applications. Most mature languages have that ability now, but it's not perfect - still in the 'needs work' phase. Likewise browser compatibility and responsive design are still not perfect, but they've come far enough now that they're workable enough. But, run anywhere fails if there's no internet connection or the servers aren't responding. Native still wins there.

2\. Simplified distribution and updates. People like that no installation is required and the latest version of the software is distributed from the server every single time a page loads. But in reality almost all modern native software can be built with a simple 'click run to install' installer, and can handle routine updates fairly seamlessly. Native is still more efficient, it just has those two extra 'click to download' and 'click to install' steps. If that could be streamlined, native would win.

3\. Ubiquitous acceptance of network requirement. It's unthinkable to block 80/443 and HTTP/HTTPS, so anything can communicate that way. Programs that use other ports or protocols may have trouble with firewalls, NAT, and other middleware. It's kind of insane to limit everything to one or two ports and protocols. That needs solving. That's where the web really wins - only because we've imprisoned ourselves.

4\. Server dependence. This is not a feature for the customer, although 'cloud storage and synching' is sold as such. It means that the company making the software gets all of the data. If their servers are ever shut down, or even if you're just temporarily offline, you don't have access to your data. And if someone breaches their system, then your data is effectively public. Local native apps leave you in control of your data and can work with it offline, even after the company that made them goes out of business. True, your system can be break (so keep backups) or be breached, but it's more under your control and less of a target than a system containing everyone's data.

Overall, the web is great for document distribution, but it's only real winning point when it comes to applications is that we've locked ourselves into one single port and protocol out of all that are available and that one happens to be the one that the web uses. If we could solve that, internet applications could be worlds better. But no new javascript framework or CSS compiler will solve that.

</comment><comment><USER176> Yes, the browser is now the universal thick client. Full circle.

</comment><comment><USER177> nah. it's at best time to fix javascript and css, the whole concept of browsers as delivery mechanism is awesome and it's here to stay

</comment><comment><USER178> i enjoyed this even if it was more of a hand-grenade-come conversation- starter.

</comment><comment><USER179> You know what would replace the web app if it was replaced today?

Some corporate locked down solution subtly or unsubtly controlled by a single conglomerate or interest group.

Recently certain corporations have been whispering about replacing the web standards with something "better". At the same time as they have been pushing free our-platform-only "internet connectivity" in developing countries. I don't want to name names since multiple corporations are implicated but for the sake of simplicity let's call the imaginary placeholder company "Facebook".

At the same time we literally JUST had a major split in the fabric of the internet with the EFF leaving W3C over DRM and now this is the top-rated comment on Y-combinator?

Venting frustrations is one thing, but anyone seriously advocating for replacing the web standards at this moment in time is either ignorant, ethically bankrupt or a corporate shill. Yes I know: Your mental internet filter has been finely tuned through years of weathering forum flamewars to stop reading any thread after encountering the word "shill" but please let me explain.

This is the first time in the history of the world that humanity has achieved a single standardized application platform supported by all major devices! If that wasn't enough we now have amazing code collaboration tools like git(hub/lab/etc) and `npm publish`, to the point where the hardest part of writing a new web app often comes down to finding the right libraries and sticking them together. This is fucking amazing!

Today's web is a land of unicorns and rainbows compared to what any sufficiently pessimistic human being would have predicted when the internet began. The technology used by the world for most of its communications is largely based on globally accepted standards and open source software!(!!).

Keep in mind that this is despite a global economy that has been trending toward increased corporate control by a decreasing shortlist of major players. In short: Despite the fact that the rest of the world currently appears to be mostly made of burning garbage, web developers should be dancing in the fucking streets!

If there are problems with the web then please remember: It's still the early days of the web and we've only recently begun writing very complex applications for this platform. We'll keep improving what we have and every year things will be better, but it is also always going to be the case that humans will push technology as far as it will go, so if you feel like web technology always sucks then that just means that you're always working at the very edge of what's possible with the state of the art. Changing platforms won't change this fact and the bleeding edge will always be... bloody.

If anyone thinks that throwing away the world's only common application platform because "development is hard" is a good idea then maybe they should try writing a UI-heavy app supporting Android, iOS, .NET and *nix with one- click install and high security, without using any web technologies, and then come back and tell me that this is a better way.

Now let me predict the future:

What's going to happen is that Facebook will come out with some new app framework based on React (or React Native) which will compile to current web standards but also to the new "Facebook browser" (they won't brand it as a browser but rather as a new part of the internet that has been missing until now). They will get more and more people developing for this framework since it makes development less painful (at least for the younger web developers who are fresh out of their corporate sponsored bootcamp and have only ever tried this one framework) and when they get enough developer market share they will start adding more and more "facebook-only" features which will enrich the experience for people using their "browser". Keep in mind that I am still talking about a metaphorical Facebook. Maybe it will be a Facebook/Adobe/Amazon/RIAA/MPAA conglomerate "standards" initiative or some such multibeast.

Anyway: Because "Facebook" is actively developing this framework in-house at the moment they've been pushing public opinion against current web technologies in preparation for launch (honestly given who they are and their available resources they would be incompetent if they weren't).

They were planning to launch this cross-industry collaboration and framework after the W3C DRM incorporation failed to pass, using the fires of industry indignation to bootstrap a corporate replacement for web standards, but now that they actually succeeded in undermining the W3C once, they will simple continue undermining web standards via the W3C while the FCC and the rest of the world is left to attempt to start a new standards organization out of the ashes, and let's face it: The web standards were created when few people cared about web standards and the feat would be very hard to re-create without heavy industry support now that there are so many powerful stakeholders.

I know this post will most likely be buried but at least I'll get the bitter satisfaction of linking to it and saying "I told you so". Or maybe I'll learn not to be so fucking pessimistic. Either way it's a win.

</comment><comment><USER180> I've never heard of the author of this article. Any particular reason we should listen to him?

</comment><comment><USER181> I wish modern web apps were as good as and as consistent as Win 98 apps.

</comment><comment><USER182> No, it's not "time". I hate stupid headlines so much.

</comment><comment><USER183> Ok, alternatives?

</comment><comment><USER184> Internet is at risk of becoming low level plumbing of the snazzy house of proprietary app world. With the advent of app-only companies and products, internet, as we knew it, is slowly taking the backseat. App world is full in control of their masters and it is a very snobby world. Biggest irony of the sharing economy is that apps don't like to share, linked to, looked inside. This world does not have a concept of hyperlinking, a basic premise of the internet. It is surely very un-internet like. It all seems designed to lock in the users to handful of apps and make them so myopic that they don't even realize that there are options.

Let me take a step back. Internet, in my view, is the ultimate manifestation of FREEDOM. Everything is/was free:

* Access to internet is free after you have paid your ISP. Almost everything that has been digitized is available on the internet for free. You could change ISPs and everything still worked.

* There was hardly any government control over the internet. They wished. However, it is designed in such a beautiful way that there are very few central systems. This makes the internet very tough to control (unless of course you are China).

* The real estate on the internet was also very cheap. You could buy a domain name in $10, a cheap server in $5 and go online with your site.

* There was no limit on number of sites you could visit. These sites could not steal your data. They could store some of their own data at your end but not steal much. Once you close the site, they cannot send you any popups or notifications. They cannot run in background and monitor your activity. Track your location, speed, acceleration etc.

* Better still, you could write blog posts which millions could read and cost you zilch. There were these things called RSS feed, which made it even unnecessary to go to sites to read content on them. You could just subscribe to RSS feeds.

* In fact, you could link to other people's property and it was encouraged. People who visited your site, could easily hop to any other site you linked to. You did not have to pay anything for it.

* HTML was written in a way that made even sloppy code work. HTML was so dead simple that anybody could make a site in it. No lock-in. Almost all code written for one browser worked in all browsers. There were tonnes of browsers. This sloppy code could render on almost any device and browser. Again no lock-in. You could look into the html, css and javascript code of any site. It was free for all. Internet was the ultimate open source.

May be internet was too open to make money. So 'they' invented the app world. App economy is a dream for big companies. Huge user base, free & rich media push notifications, ability to steal the ultimate of user social graph (call logs, sms history) and on-ground sensors to enable steal very personal data of users. Lets have a look at this world as to how it compares to the internet.

* Internet fast speed lanes, internet.org, anti net neutrality deals. Enough said.

* Apps do share the internet. However are themselves in control of one company which makes it, one company which distributes it.

* Apps have already made it impossible for a part time hobby dev to produce and maintain 3-4 different apps. Hardly anybody I know, knows obj-c and java both very well.

* Apps have made it difficult to have more than 20-30 of them on your phone. More than that and your phone would be left with no space. Once these select 20 are there, you are locked into them. They steal your data and periodically push you notifications! A we just love them.

* We first managed to kill RSS. I remember there was a huge campaign one time which demeaned RSS. Google then killed reader for no apparent reason. Is the internet world a puppet show ?

* Apps cannot link to other apps. You cannot link to particular page/screen of particular app in a generic way unless the other app wants it and allows it. There exists no generic way to do it. The standard way could be that you talk to the other app dev, sign a contract with them and possibly even pay them. Linking is dead.

* Apps are not free. They are locked in to a platform. If you want to port your code, you would need to rewrite the whole code base. (hybrid apps don't seem like they are happening)

I think we are witnessing end of internet as we knew it. Companies are suddenly trying to kill browsers and generic internet. They are trying to invent a proprietary walled garden internet.

</comment><comment><USER185> I think that most of what's being complained about here is that it's very difficult to write secure web apps that allow the typical business model of web apps to work.

If your business model is getting attention, sharing user data, and pushing ads everywhere, it's hard to leak some data to unknown parties without leaking all data to unknown parties.

It's not by any means trivial to completely lock down a web app. But it is possible to do it well enough that attackers don't bother with technical attacks. Social engineering is an easier vector. And that will always be the case after you close a certain number of holes. That number gets larger over time, but as new attacks get discovered, good frameworks catch up and at least encourage you to close them if not outright doing it for you.

Something something it's unsurprising that a person doesn't understand a point you're trying to make when the person's paycheck depends on them not understanding it.

Same thing with web apps. It's unsurprising that web apps are insecure when the business model for most of them depends on them being insecure.

I'm not arguing that anything is hack-proof. But according to the article, it's impossible to have perfect security in a web app, so let's burn it all down. My counter to that is this: it's impossible to have perfect security anywhere. On any platform. Everything is hackable. Users most of all. So since we're complaining about how impossible this is, then we should all shut down our computers, go home, and find another way to make a living.

That's not going to happen, and it shouldn't happen. But what we can do is take a close look at why the security measures we can deploy are typically not: in my opinion, it's very often a business decision more than it is an engineering failure.

When security comes up as a topic in native platforms, many technologists seems to be willing to take a hard stance: any back door, no matter how well intentioned, will be abused.

Web apps that depend on ad dollars are the definition of back doors.

Here's an idea: create a product that people want and charge people money for it. It simplifies your security model enormously because you don't have to choose what to leak to whom. You treat every leak as an existential threat to your bottom line.

With that as a driving mandate, limiting attack vectors to gaming users becomes a lot more doable very quickly. Then you move on to educating users.

Security of private information and money isn't a new game. People have been finding ways to steal property since the beginning of recoded history.

We're being pretty stupid if we think it's new problem. Do people call for banks to shut down because it's possible to forge a check? Call for the Fed to shut down because it's possible to get robbed? Of course not.

But when a fundamental part of your business model is stealing from people, it can't be a surprise that other people besides you are also stealing from them.

</comment><comment><USER186> I feel like the quote about democracy being the worst system of government except other could easily be adapted to the webapp platform. It certainly has a plethora of issues, I am not trying to gloss over that in the slightest and it would certainly be logical fallacy to assert just because it's the most popular platform it is therefore the best.

However, A lot of what appears to be recreating the same computer technology over and over is actually not recreating but I think selectively rebuilding platforms, picking up pieces of tech and ideas from the junk pile of previous ones and seeing now they might actually be workable. This process also allows discarding the dead weight of bad ideas no one bothers to pick up and bring in.

It's like we do development by tossing useful ideas into a house. Then when they house is literally bursting with the all the orthogonal junk we've tossed in it over the years, but which programs have come to rely on we say ... well that place is a mess, let's start a new house, and we repeat the cycle, taking the best pieces from the old house as we have the resources to carry them over. Sometimes we have a particularly good and consistent plan of what we want in the house, so we can put up a lovely one ... initially. However inevitably, as is the case when you are still discovering new ideas and techniques as we go along, you notice your neighbor with some hot new feature, and rather than lose ... um guests (this analogy is getting pretty stretched) we say, ok we'll add that I guess, not wanting to be hopelessly outdated and lose out on that cutting edge of cool features and dragon chase of increased productivity and nifty little bits of syntax sugar or cool tricks or whatever.

So existing platforms typically can't be hoisted wholesale onto other platforms anymore than a house full of junk can be moved from the country to a different climate on a different foundation. It just usually doesn't work well because the hoisted platform is typically at a stage of high refinement to it's niche, built on a several assumptions, even a few of which failing wipe out the ability of the hoisted platform to function either outright or at an acceptable level.

I think that a variety of competitive pressures from large players capable of making feature bloated browsers is the best we can reasonably expect from a societal system built fundamentally around competition and not collaboration, cooperation, and coordination. Even still we face large locked down platforms like iOS where you cannot run any web rendering engine (e.g. firefox / chrome are just glorified safari browsers due to apple app store policies forbidding custom rendering engines like gecko or blink) or interpreter you please, or my pet peeve even any url with a %s to act as your user set search engine (only a list of 4 options is available), which puts a strong gate in front of users freedom to choose how and what they run on and interact with their pocket computers.

Where am I going with all this? I guess webapps as a platform, as bad as they are only exist as such because they developed as a race between different browser vendors to one up each other with cool features. This process is like throwing useful stuff into a house. Getting each of several different platforms to agree on a standard for applications and then implement that in a consistent portable way seems almost impossible to me.

</comment><comment><USER187> The return of Adobe Flex!

</comment><comment><USER188> This isn't really about killing "the web" though, it's about changing web development as we do it today. At least, when I read that title I assumed it was about the web as a whole, not just web apps and the way we develop them.

<comment><USER189> OK, we added 'app' above. That seems in the spirit of the article, which seems fine with the web as a document platform.

</comment></comment><comment><USER190> Ah yes: this open, ubiquitous platform used by hundreds of millions on a huge variety of devices, let's get rid of it. I hope this person is not one of those techies who claims to love "boring" technology.

</comment><comment><USER191> heavy on vitriol, light on substance. fun to read if you don't ask questions.

</comment><comment><USER192> Just make better webapps... There are too many second rate "developers" making shitty apps...

</comment><comment><USER193> Quite a bit ironic that you need js to actually see the images in that article.

<comment><USER194> I can see the images without JS enabled.

<comment><USER193> What browser are you using and how did you disable the js? With firefox esr and with either ublock origin (dynamic mode) or umatrix to disable the js I am unable to see the images.

<comment><USER194> Firefox + NoScript

</comment></comment></comment></comment><comment><USER195> It is a triumph of programming ingenuity that programmers have been able to accomplish almost anything via a "web browser".

Anyone can argue the benefits. If if there were few benefits the novelty alone might be enough.

But does anyone ever consider the costs?

The analysis I have in mind is: costs versus benefits of using a web browser to do x, where x is anything and everything, no matter how important.

The "costs" are not costs to the programmer to implement but costs to users, e.g., risk of having their personal data stolen.

To give an example, weigh the benefit to Equifax customers in having their data accessible through a web browser versus the cost of having their data exfiltrated without their consent.

Or, weigh the "cost" of having to dial a toll-free number to order a credit report and not have one's data stolen online versus the "benefit" of being able to order a credit report with a web browser and having that data stolen online.

Websites can be used to effectively disseminate public information, with relatively little security risk. For example, djb's tcpserver and httpd to serve static web pages. In continuous use since the 1990's, these have never had any security issues to my knowledge. IMO, this level of software is qualitatively different than _software which is released with security flaws_ , which may or may not be later fixed (sometimes decades later).

IMO, using the web to distribute public information is a benefit that outweighs the costs. I am not worried about static websites, assuming the right software choices are made.

The blog post acknowledges this: "The web has issues as a way of distributing documents too, but not severe enough to worry about."

If Equifax had a static page served by djb's httpd showing number to call to order a credit report, I would be far more impressed than if they were running a "web app" to take orders online that connected to some backend database of user data. Because for that specific use case, a very limited use of the web is the smart thing to do.

I would like to see more people opining that, for "serious uses" i.e., where the risks to the user are potentially serious, the web has _limited_ utility.

The current thinking seems to be that the web has _unlimited_ utility. For everything. We all know that with enough effort the "web browser" can be used to accomplish almost anything.

I remember an RFC many years ago from Marshall Rose that said something like "the web is the new waist". I also remember in the early 1990's, people were afraid to send credit card information via web forms.

"Unlimited utility". Today, many young people, including many programmers, see no difference between internet and web. They are synonymous.

"Unlimited utility". Maybe utility should be weighed against costs such as security risks.

IMO, the web has _limited utility_.

Would you sacrafice a little convenience, e.g. option to order a credit report online, if it meant your data was not part of the data stolen from Equifax? I would.

</comment><comment><USER196> click bait

</comment><comment><USER103> So much truth you get sick of hearing the truth.

</comment><comment><USER197> The Web is fucking awful, and our industry's rapid acceptance of it represents a massive moral failing across all of us. We have ruined everything, and we need to take responsibility for our actions.

<comment><USER197> Nobody likes this nonsense except advertisers. It's garbage, and everyone posting on HN knows better.

</comment></comment><comment><USER198> This article came off as a big whine-fest... Yes, security is an issue. It always will be. Yes, we need to find a better way.. But without proposing a viable alternative or solution, it's just blah-blah, complaint-complaint.</comment>