It’s time to kill the web app (opens in new tab)

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.

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.

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.

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.

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.

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

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.

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

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

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.

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.

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.

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.

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.

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.

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

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

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

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.

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

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.

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.

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

2. on how to fix it: 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....

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.

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.

This article is so naive.

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

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.

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.

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.

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

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

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

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!

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

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?

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.

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?

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.

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?

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.

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.

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.

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

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.

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/

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.

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.

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

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

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

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.

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.

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?

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

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.

Until I can block ads in web apps, I'll keep my browser thanks.

Seriously? the web app is the most ubiquitous and flexible app on the planet; adapt or die.

> "Flux, the latest hot web framework from Facebook."

This guy is clearly not a web developer.

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.

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

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

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.

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.

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.

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

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.

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]

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.

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.

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?

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

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.

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.

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

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.

>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 and this: https://joreteg.com/blog/betting-on-the-web#what-sucks-about...

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.

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

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.

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.

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

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/ok-w3c-and-whatwg-dont-die-but-...

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

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.

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

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.

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

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.

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.

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?

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

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

This is a WEB APP 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?

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.

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.

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.

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.

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?

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.

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.

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.

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

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!

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.

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.

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

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?

Reminder me of this article from Wired... back in 2010 "The Web is Dead" https://www.wired.com/2010/08/ff_webrip/

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

> 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

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.

We are using a stateless document model for apps. You can select text on buttons. Madness.

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

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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

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.

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.

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://heropunch.io/ln/work

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.

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

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

> a meaningful number of developers are openly questioning the web platform.

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

Oh, wait.

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.

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

Uh huh. Well until you have another platform installed on anywhere near as many devices I wish you luck.

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

I think having separate browsers for web documents and web apps could solve half of the issues.

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

It’s time to kill t̶h̶e̶ ̶w̶e̶b̶ rants with little substance on medium platform.

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.

Yes, the browser is now the universal thick client. Full circle.

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

i enjoyed this even if it was more of a hand-grenade-come conversation-starter.

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.

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

I wish modern web apps were as good as and as consistent as Win 98 apps.

No, it's not "time". I hate stupid headlines so much.

Ok, alternatives?

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.

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.

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.

The return of Adobe Flex!

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.

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.

heavy on vitriol, light on substance. fun to read if you don't ask questions.

Just make better webapps... There are too many second rate "developers" making shitty apps...

Quite a bit ironic that you need js to actually see the images in that article.

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.

click bait

So much truth you get sick of hearing the truth.

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.

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.