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.

https://sunshinegardens.org/@xj9

https://heropunch.io/ln/work

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

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

Oh, wait.

I'd love to keep doing web apps.

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.

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.

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.

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

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.

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

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

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.

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

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.

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.

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.

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

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.

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?

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.

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 think the future is IPFS and other content-addressable protocols. Why aren't browsers adding them to the web alongside https?

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.

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.

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.

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.

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.

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.

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?

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

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.

This guy is clearly not a web developer.

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

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

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.

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.

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.

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?

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.

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

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.

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"

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.

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

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'm curious to see the second part of the article!

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.

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.

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

https://en.m.wikipedia.org/wiki/Hollerith_constant

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.

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

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

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.

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

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

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.

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

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

The medium remains the massage.

https://imgur.com/a/26oFa

Even Chrome allows for a very fluid editing and debugging experience. Half the time I write my code directly in the browser.

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.

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.

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

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

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

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.

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?

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?

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

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.

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?

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.

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?

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.

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.

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.

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

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

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.

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 the tradeoff probably isn't worth the extra time needed to carefully structure your html and do css acrobatics.

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

But, I would argue that the web platform has produced a bigger productivity boost (in terms of output per unit of time) than any other single paradigm shift in computing history. Who cares if typing is a little more sluggish than the native app if you don't have to email the resulting document to everyone on the team and then converge edits at the end of the editing process?

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

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

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

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

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

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

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

>C is not impossible to secure

Expert compiler writers and computer scientists disagree with this assertion. History seems to be on their side.

Writing "secure" C requires meticulous attention to detail at every level, intimate knowledge of undefined behavior _and_ of compiler optimization, along with the exact options passed to the compiler. It requires comprehensive reasoning about signed integer behavior and massive amounts of boilerplate to check for potential overflow. It also requires extensive data-flow analysis to prove the provenance of all values (as Heartbleed taught us) because a single mistake in calculating a length leads to memory corruption.

To put it another way: No one can write fully secure C code. It has never been done to date. All non-trivial programs written in C contain exploitable security vulnerabilities. The combinatorial explosion of complexity makes it impossible both to formally verify and to permit human reasoning about the global behavior for all likely inputs, let alone unlikely ones.

Instead of thinking of it as buffers, you just have to encode/decode for the proper environment. Such repetitive stuff is easily implemented in stack layers.

Memory-unsafe programs on the desktop should go the same way as the HTML layout model.

This is a very dangerous assumption. The interpreters you use have not been built with security in mind.

Go take a look at PHP changelogs for example.

75% of web devs wont bother to consider it and the other 24% wont care.

it's the job of browser vendors to provide saftey for the masses. of course the giant conflic of interest here is that most browser vendors get a cut of the ad revenue.

there's a massive need for a payment platform that allows for browsing ad-free but still paying directly for content as-you-go. i think Brave is trying to do this.

cryptocurrency may provide the privacy protections for this type of arrangement.

Another advantage is that they are inherently available across OSes, usually across different browsers (but we know what it takes.)

Finally, they used to be much more easy to develop.

Tldr: larger audience, less costs.

The true definition of a full stack developer in those days would make today's definition of full stack faint.

You had to know how to setup hardware with an os with your software and databases, often having to run your gear in a datacentre yourself that you had to figure out your own redundancy for, all for the opportunity to code something to try out. Being equally competent in hardware, networking, administration, scaling and developing a web app was kind of fun. Now those jobs are cut into many jobs.

Activex was what flash tried to be.. The promise of Java of using one codebase everywhere.

Seeing webassembly is exciting.

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

FWIW, I'd take tight control if it was in pursuit of humanitarian values, such as accessibility for people with disabilities, rather than a company's bottom line. The chaotic freedom of the Web isn't very good for accessibility. Yes, yes, accessibility is possible, but in practice, very often it doesn't happen. See this rant on HN from a blind friend of mine (yes, the same one I posted elsewhere on the thread, but it drives the point of this comment home):

https://news.ycombinator.com/item?id=14580342

Once upon a time, this was a solved problem.

Now it's slow, burns your battery, it's full of ads/tracking and anti-patterns like infinite scroll or SPAs and view source is useless.

For me, a site like HN or amazon (with some reservations) is the pinnacle of what the web is able to offer.

Only web standards are not created by an "inexperienced mob of people" but by large multinationals, multiple CS PhDs, and seasoned developers.

And if we consider every generation of new developers an "inexperienced mob of people", then we have absolutely no claim to ever being called an industry and engineers.

>And, yet, the mob has continued the very fine legacy of those 90s (and 80s and 70s) software developers in pushing software into more places it's never been before. Somehow, it's working

Working in what? Mobile apps, counting in the millions, have actually "pushed software into more places it's never been before", and most of those are usually native, or done with non-web technologies (of course web stacks encroach there too). For most people, those mobile apps on their smartphones is how they interact most of the time with the internet, not www, even if they have a laptop at home or at work. For younger people even more so.

>But, if you show me something better, I'll gladly participate.

Better things come from people feeling the need to create them. They don't appear on their own, and people migrate to them. Else people can be stuck with the same BS for decades, centuries or millennia (consider dynasties ruling for centuries before the people of some country attempt to bring them down in favor of democracy).

But downloading an EXE is basically allowing arbitrary code execution on your machine no matter what. So _even with the security bugs_, webapps are basically safer than installing a native app on desktop, at least in its current state.

I see your point though. There are still a lot of entry points we need to be careful about

I have myself developed GUI application using author's beloved C++ and Qt and I can admit its a far better designed and convenient experience compared to the web, but it's hardly possible to achieve the same amount of flexibility in UI/UX design that is available on the Web. I think the fact that things are changing so fast, standards are badly designed (at least initially) and there are so many inconsistencies are all only because web is a fast moving platform that requires the consensus of many players to happen and move forward. Also the amount of commercial interest and developers working on the web is incomparable to other platforms, hence the fast moving nature.

https://www.office.com/

Let's not forget we've drastically increased security by writing applications in safer languages.

Oh, and newer applications tend to support a far wider variety of devices types, displays, inputs, etc.

Developers definitely be investing a lot more effort into improving the status-quo, but it's unfair to claim stuff is slower without improvements.

Things that are written in C these days are usually written in C for performance reasons. FFMPEG would not have even close to the performance it has if it was written in a memory safe language instead of C and assembly. I doubt that a magical compiler (and/or language) will appear in my lifetime that can compile high level code into performant machine code, especially when it comes to memory management. (note that C also has advantages other then performance)

JS doesn't even have a proper specification, let alone a bug-free interpreter/compiler.

EDIT: AFAIK verifying memory access is part of a formal verification, where memory is also modeled mathematically.

Java apps were on the other hand slow. Ironically, today we have so many languages producing slow code, that Java is considered fast.

C is close to PDP-11 and 8/16 bit computer Assembly, it has hardly any direct mapping to modern CPUs.

The fix for SQL injection is to work with binary APIs and protocols more. Parameterised queries are the smallest step to that world, where the user-supplied data rides alongside the query itself in separated length-checked buffers (well, assuming you're not writing buggy C - let's presume modern bounds checking languages here). They aren't combined back into text, instead the database engine itself knows how to combine them when it converts the SQL to its own internal binary in-memory representation, as IR objects.

Another fix is to move entirely to the world of type safe, bounds checked APIs via an ORM. But then you pay the cost of the impedance mismatch between the object and relational realms, which isn't great. I will provide a solution for this in part II.

That's where I still run into problems with CSS too. However, at some point, and not because I started using flexbox / grid, CSS did click for me and now it's mostly second nature to get the layout that I'm going for.

My feeling on this whole topic is that while as a web developer I have often thought "there must be a simpler way", every time I actually start to imagine what that would look like I end up re-imagining something similar to the web stack as it is now. There is a lot of inherent complexity to GUI-based networked client-server applications that need to be responsive, continuously integrated, database-backed, real-time, etc.

Sure thing. If you know exactly what you need and design for that, than the outcome is allways better, than just randomly adding things here and there. So yes, a newly designed web would be something awesome. The thing is just, that it is somewhat complicated to design such a thing in the first place. And then build it. And while you build it, you discover many new things that also absolutely have to go into the design, so you redesign, ...

So in other words, I am curious for his thoughts on a new design and I would welcome it, if it leads to anything. I am just very sceptical, that there is something really awesome and concrete behind it. Vague ideas how to improve things, are allready floating around since the beginning.

Similarly Microsoft Office on mobile is a native app, and I can't seem to find good stats for how Office on Windows/Mac compares to the Docs suite on desktop but my guess is that it's not a pretty comparison for Google Docs...

Sure, but that's just the standard solution that hides the mismatch. The mismatch is still there. Which is why when performance becomes an issue, there's a whole bag of tricks for tuning the ORM or just sidestepping it and writing a sane query. It's also part of why the SQL database went from the only thing people could conceive of using to one tool among many for data persistence.

As 1970s paradigms go, SQL has had a good run. But the main problem it solves, easily finding and changing your data somewhere on a small number of spinning metal disks, is just not the central problem of computing that it was for a few decades.

I refer to these as "unstable industries" - they all exhibit the dynamics that the consequences of success undermines the reasons for that success in the first place. So for example, the key factor that makes an editor or new devtool popular is that it lets you accomplish your task and then gets out of the way, but when you've developed a successful editor or devtool, lots of programmers want to help work on it, they all want to make their mark, and suddenly it gets in your way instead of out of your way. For a social network, the primary driver of success is that all the cool kids who you want to be like are on it, which makes everyone want to get on it, and suddenly the majority of people on it aren't cool. For a review site, the primary driver of success is that people are honest and sharing their experiences out of the goodness of their heart, which brings in readers, which makes the products being reviewed really want to game the reviews, which destroys the trustworthiness of the reviews.

All of these industries are cyclical, and you can make a lot of money - tens of billions of dollars - if you time your entry & exit at the right parts of the cycle. The problem is that actually figuring out that timing is non-trivial (and left as an exercise for the reader), and then you have to contend with a large amount of work and similarly hungry competitors.

And I hope, that all the missing things like schemas can and will be added at some point, when there is a consensus on how ... And TOML and Dhall look interesting, but I like the block approach with brackets to data like JSON does it.

On a more serious note, it has it's faults but it works. Maybe people are asking too much of it? Maybe they need to adjust their expectations?

There are lots of ways that it can be improved. I can think of one innovation coming down the pipe and it impresses me. HTML5 doesn't, by itself, really impress me. WebVR, or whatever they are calling it, doesn't impress me - I remember VRML and the fiasco that was. No... The new DRM spec doesn't scar me - I figure it's just going to give a standard interface to what is already going on.

What does interest me is the webassembly. That I find interesting though a part of me expects it to end up similar to Java applets from back in the day. It interests me because I am expecting it to be a boondoggle.

The rosy-cheeks on the starry-eyed youth have assured me, quite breathlessly, that this is a game changer. This time, this time it will be different. We're finally killing Flash and they've gone and reinvented it. I'm probably going to have to add another 32 GB of RAM, just to use a browser. But, it's going to be different this time. They've got a plan.

So, I'm interested in seeing how that turns out. I'm the quintessential optimist. I have every hope in the world that someone will come up with a way to selectively block it.

Really, the web is doing okay. When we stop and look at all the crap we've shoveled ont TCP/IP, I'd say it has held up nicely. I really can't think of a single bit of tech that has taken more abuse than TCP/IP. HTML and CSS are up there, but I'm pretty sure TCP/IP can lay claim to the most abused spec.

Yet, the 'net lumbers on. It's kind of amazing and it is a great time to be alive.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- "When the cookie meets the blockchain: Privacy risks of web payments via cryptocurrencies", https://arxiv.org/abs/1708.04748

Firstly, I did try and solve the block size problem. Myself and Gavin did Bitcoin XT. It resulted in large DDoS attacks that took out entire regional areas because they contained a single XT node, any mention of XT being banned from the Bitcoin forums, large companies like Coinbase being banned too for simply experimenting with it, and so on. Miners also refused to run it because they were told that this would be democracy, and democracy was dangerous (they were almost all in China, so no surprises there). There was a large, organised and extremely hostile effort to ensure that the solutions we proposed could not be adopted even by those who wanted to. I did a lot more than just write articles.

As for this article, it says there's a second part coming where I propose concrete solutions.

https://expandedramblings.com/index.php/facebook-mobile-app-...

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

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

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

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

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

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

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

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

This is the important takeaway here. Changing the encoding simply swaps out one set of vulnerabilities and attacks for another. Separating control flow and data is the actual silver bullet for this category of attacks.

Unfortunately, there’s rarely ever a totally clear logical separation between the two. Anything you want to bucket into “control”, someone else is going to want the client to be able to manipulate as data.

Granted, if you made that control channel stateful, you'd make a lot of problems go away. But you could do that with a combined control/data stream too.

What am I missing? How would an out-of-band control channel make things easier?

That said, I think many issues with the web could be solved by implementing new protocols as opposed to shoehorning everything into HTTP just to avoid a firewall...

LaunchPlan2017Q4Final4Draft1Beta.doc with Track Changes on.

All security issues are due to human error. Those are solved by building better tools.

> If this was the case, it would be near-impossible to write HTML by hand.

If, besides the text form, there would be a well-defined length-prefixed binary representation, we could simply compile HTML to binary-HTML, which would immediately made the web not only safer, but also much more efficient (it's scary if you think just how much parsing and reparsing goes on when displaying a web page).

If programmers paid more than lip service to responsibility, the whole dumb paradigm of "worse is better" would not exist in the first place. As it is, we let the market decide, and we even indoctrinate young engineers into thinking that business needs is what always matters the most, and everything else is a waste of time (er, "premature optimization").

How many hacks, data breaches, and privacy violations does it take for consumers to start giving a shit?

Also, any programmer will tell you that just because an issue is tagged "security" doesn't mean it will make it into the sprint. Programmers rarely get to set priorities.

The incentives for someone to break into a major retailer, credit card company, or credit bureau are much different from Widget Cos. internal customer service web database. What I think the article is missing, even though it makes alot of good points, is that if there's a huge paycheck at the end of it, there will always be someone trying to exploit your system no matter how well designed it is. And if they can't hack the code quickly, they'll learn to "hack" the people operating the code.

You are oversimplifying. Dunno in what programming area you work (or if it's software at all) but "we work with languages X and Y" is something you'll find in 100% of all job adverts.

Tech decisions are pushed as political decisions from people who can't discern a Lumia phone from an average Android. That's the real problem in many cases.

That there exist a lot of irresponsible programmers is a fact as well.

It used to be that RandomBusinessApp would hit this stuff, now most of it ends up in Java so it might still crash but usually it's mitigated better.

Most programmers want to dio their job quickly and easily, and go home.

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

I'd say OpenSSH (since SSH2) has a better track record than most webapps, as unfair a comparison as that is. In terms of local robustness, there's SeL4, which is also a bit unfair (since it took about a decade for a team of geniuses to prove enough properties to make it probably not very buggy).

I guess it would have to be protobufs over TLS, and abuse port 443, to get through firewalls from hell.

The only issue is having to manually convert the string.

[0] https://en.wikipedia.org/wiki/ISO_8601

That's what I call server deciding for the user. And now you're in real trouble with security.

This has been implemented in HTTP (not HTML); you can enable the requirement right now by serving your pages with an appropriate Content-Security-Policy header.

    (html "user content")

    user content := " (script "something malicious")"

    (html "" (script "something malicious"))

Also css lacks properties for controlling wrapping limits and non-linear image scaling. And for some reason I always have to optimize on either width or height, I can't control both perfectly.

Edit : just want to make it clear that I'm trying to paraphrase here, I don't know if I agree (although I do want to point out that HN is built in this philosophy)

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

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

The security gain is that it you are only able to run queries that the DBA allows you to. If you can't write arbitrary queries, you won't get arbitrary results. If you can only run a stored procedure, you are abstracted away from those side effects. Another way of saying this -- the security risk is shifted from the app developer to the DBA. Someone is still writing a query (or procedure code), so there will always be some risk.

Of course, there are books and guides to help people, but how would someone figure out which guides are worth it? There are a lot of highly rated books on the topic of web development and if you don't already know what you need, it can be daunting.

But yes, flexbox is great.

Injection in general is simply a trust problem. If you can trust all inputs fully (hint: you can't, because nobody can), then you will never have an injection attack.

I think you're missing another two obvious explanations:

1. Lack of education when picking a tool (copy paste from bad SO answers is a frequent source of bad code).

2. Developers don't care. If it works, why bother wrapping your head the rest of the way around to understand why it works or whether it's secure?

> By itself, it is not an XSS. But if the backend is/was running Ruby on Rails (presumably some old version by now) then it could turn into an XSS due to a combination of features that all look superficially harmless.

Sure, ERB before RoR essentially had security turned off by default (as I noted). And this issue could happen with any other non-web system, turning into any other kind of vulnerability. This isn't a web problem, it's a system security problem. Bad inputs in a "native" app could lead to security issues in the output of apps on other devices. Badly implemented binary data decoders in a desktop application could do far worse than a XSS in the browser.

This problem is misattributed as a "web problem" because there are far more complete systems on the web than there are on nearly any other platform. It's like the tired argument that Mac is more secure than Windows, but Windows has historically had an overwhelmingly outsized market share, making OS X issues far less valuable to attackers.

> When I argue that the web is unsafe by design, it's because cases like that aren't rare, they're common.

I don't disagree that these issues are common, but I disagree that the web is unsafe by design. The web is a platform. If everyone wrote their Python APIs without a framework, I can guarantee they would be littered with security holes. If everyone wrote their own text renderer in C++, just displaying strings on the screen would be a dangerous task.

There are good tools that make it really hard to fuck up on the web. Seriously, try to accidentally have a XSS vulnerability in an isorendered React app with Apollo. The problem is folks that want to jQuery-jockey their way across the finish line and don't understand that they are making terrible mistakes.

Oh thank God. I'm going to forward this to my wife.

Agree.

> harder to unit test

Disagree. I've implemented unit tests that connect to the normal staging instance of our database, clone the relevant parts of the schema into a throw-away namespace as temporary tables, and run the tests in that fresh namespace. About 100 lines of Perl.

That was five years ago. These days, it's even easier to do this correctly since containers allow you to quickly spin up a fresh Postgres etc. in the unit test runner.

This will be a legal problem. At least in my jurisdiction, transforming source code (which is what prettifying is) is not subject to legal restrictions, but decompiling binary machine code into readable source code is forbidden by copyright law. (For the same reason, I'm concerned about WASM.)

The way that Linq works and the fact that it’s actually compiled to expression trees at compile time and that the provider translates that to the destination at runtime whether it be database specific SQL, MongoQueries or C#/IL, does make this type of testing possible.

Plugins were killed by most browser vendors more or less at once, and Mozilla wasn't even the first one.

Dart was opposed by every browser vendor who wasn't Google, though the reasons may have differed. Same thing for NaCl.

WebSQL is the one thing that I am aware of that Mozilla in fact opposed when others were broadly in favor, but the reason was not NIH. It would have been pretty simple to implement WebSQL in Gecko. The opposition came down to two things, I believe. The first was a simple observation: the W3C process at the time required two interoperable independent implementations, and there weren't any for WebSQL; the only implementation that the spec allowed, if you were going to achieve interoperability, was a particular version of sqlite. There were various ways to solve this problem, including abstracting away the database more (i.e. developing an actual Web SQL with well-defined semantics that were not tied to a particular implementation), but none of the WebSQL proponents were willing to go ahead and put in the time to do that, as far as I can tell. The second issue was the fact that WebSQL had synchronous database queries going on. The storage API really should be async, if it's going to be accessed from the "main thread" (the one the Window object lives in). I do think we could have done better than IndexedDB, though. It, like many other recent web specs, feels way over-engineered to me.

[Disclaimer: I work for Mozilla, and did back when most of the things you mention were being discussed, but was not actively involved in the WebSQL/IndexedDB discussions.]

But I actually have some anger as well on them for enforcing indexedDB and killing everything else. So now we have to use f indexedDB for storing things locally. You apparently would have prefered WebSQL, I would have liked FileAPI.

Still, I don't believe it is out of evil attempt, just limited ressources mixed with stubbornness.

So, the reasoning is that UI is fundamentally the same (or worse if not done right) to native UI from the 90's, yet it hasn't had a massive speed increase which seems wasteful.

But modern UI in Office is only an evolution of what was there in the 90s and hasn't changed fundamentally either yet it doesn't feel any faster.

UI is only a small part of an app, a well designed app will have most of the work performed outside of the UI thread and it shouldn't feel any slower than a native implementation. My thoughts are rendering speed isn't the issue but application design.

There are lots of things they could do. Linking data between spreadsheets or between excel and powerpoint sucks (a significant part of the user base needs to prepare decks and reports that contain lots of charts and numeric tables).

They could learn from Apple's approach with numbers where a worksheet is a canvas on which you can place multiple tables or charts or diagrams, which makes a lot more sense than the single grid per worksheet approach (think having to display two tables one above the other, you are forced to align columns of different widths, and how does the top table overflow?).

Users who need to script or create UDF are stuck with a VB6 editor that hasn't seen any update in 20y and an antiquated language.

I could continue the list for a while. These are basic core features. There might be 1000 people in the world who use power BI, and only because their IT dept set it up for them. But millions of users who's life would be made easier with the suggestions I made above.

Numerous similar apps depending on what online platform you prefer.

This is what gets lots on most people.

The power users create some "nifty" spreadsheet that runs some "important" piece of a business. That "nifty" spreadsheet now requires Microsoft Excel and forces everybody in the company to have a copy if they want access to it.

Now of course we are using more JSON and XMLHttpRequest is being replaced by Fetch API.

AJAX means Asynchronous Javascript and XML.

The fact that the html5 spec does not permit self-closing CDATA elements is precisely the kind of legacy trash we'll be dealing with for yet another 10-30 years. (I understand that html5 didn't change the parsing rules from HTML 4 in order to be backwards-compatible, but it's still infuriating).

As I recall there was a fight about getting it in and the creators called it XMLHttpRequest because XML was the hotness at the time and that got it past the project managers and PHBs.

That was the general point, but I was responding to a side comment that I disagreed with.

> "because of feature additions"

Adding features does not require slowing an application down. The reason modern apps (desktop and web) are slow is to do with inefficient use of computing resources, which has very little to do with available features.

A user can run a few things even on the low-end netbook. Tabs are cheap. And if they hit the limits of their machine, they can either pay in a reasonable number of user-minutes to actively manage resources or a modest number labor-hours to get something beefier.

I personally would like to see things better optimized. After all, I started programming on a computer with 4K of RAM. But I recognize that there is very little economic incentive to do so.

Yes, you have webworkers for multi threaded development. They're basically independent applications which run on different threads and you pass messages (which are simply objects) between them. The browsers themselves are also moving their layout and rendering engines to be multithreaded.

A well designed app would do very little on the UI thread and would pass messages between the UI thread and the webworkers, it would also spin up webworkers on demand to offload work. It's not as easy as some environments to develop in, but it's also fairly straight forward once you make the effort to do it.

If I was designing react for instance I'd have all the virtual dom / diffing stuff being handled by a webworker and then would only pass the updates through to the UI when computation is completed.

> Or, how much speedup would you estimate, if we convert all GoogleDocs functionalities into Word97? I'd estimate 1000 times. :) Or perhaps, the computation power for drawing a cursor alone will far exceed the whole Word97.

Whatever the speedup would be the speedup the users would likely not notice or will only notice a slight improvement.

And yes, drawing the cursor as a 1px wide div is computationally intensive, I guess you're referring to that article posted on HN awhile back that VS Code used 13% of the CPU just to render the cursor? :) Doing stuff outside of content editable is not ideal for writing applications as you lose a lot of system settings (like keyboard mappings, cursor blink speed, etc) that the browser automatically translates to the built in cursor.

This is especially true as people are promoting everyone moving to a platform that is substantially worse.

How about getting more performance and battery life out of the same machine which effects more than netbook users.

Microsoft stuff was going for fixed screen size/resolution, fixed layout, and using a quite limited set of controls.

Web browsers try to be accommodating by default - any screen size (including mobile), zoom built in, and significantly more powerful control primitives that allow enormous flexibility in the way to design things.

If you're building forms applications that only need to work on a PC, the old way was certainly easier, and in fact, Microsoft has WebForms (regular ASP.NET - not MVC or API) that is pretty similar (and doesn't horribly break down so long as you color within the lines, so to speak).

Try to imagine your vb6 app being able to scale down to window the size of a phone screen, and how the WYSIWYG editor for that works even work - I imagine it would be fair to describe it as "hot garbage" also.

Much of the complexity of web design is not in the tools; it's in the fact that users don't expect a standard whatsoever, they just expect their UIs to be as slick and customly designed as magazines. If every website was written using the same standard, predefined set of widgets and components, the complexity would disappear.

Properiatery low-code tools built over the web are a better starting point.

You can certainly handle different window sizes with traditional UI layout managers. The only thing they don't do much of is totally changing the entire UI layout based on window size, and that's only because it's so rare to have a single app that's actually identical between tiny and huge screens.

It's just that nobody wants to make a Win32 style app with absolute positioning on the Web. That's because responsive apps are superior to nonresizable, manually positioned UIs.

At which point you can basically throw the designer away, since you'll be writing code to manage layout for all widgets anyway.

Exactly. At least 90% of the functionality of my forms-based applications use nothing more than the standard UI components Tk provided in the early '90s. Why the web of 2017 still cannot grasp this is unfathomable. To be perfectly honest, I've never seen any toolkit match the productivity of Tcl's Tk of more than two decades ago, and it's even better today:

http://www.tkdocs.com/tutorial/

But yes, these days, people do expect windows to be always resizable and that does add some complexity.

When I click on some languages (I am not native English and my native language, Dutch, is not very high on the list of priorities for most companies) in some of the biggest companies in the world, you notice it just wasn't designed for that. From just making it wrap and enlarge to break the design to simple sticking outside the box.

For some localizations (Chinese for one) you will have to redesign anyway because 'our' (not sure how to describe) designs simply do not work/sell over there.

Most global companies have a local presence doing their local sites; I know some, even inside the EU, very big companies that have a site per country and have the html/css look 'the same-ish' for the user but completely different when you check the source to accomodate for local taste / language.

I like the dream of this working, as I am a programmer, but I don't see it in real life and I find html/css just painful to work with; not difficult but painful compared to most desktop GUI tech. Flexbox etc is changing that a bit but still it looks like people are shoehorning everything in this html5 stuff just because they desperately not want to use/learn other things instead of using the best tool for the job.

Disclaimer: I am old and have seen this before. I do create webapps and use React (new license makes it workable outside hobby projects), but I will gripe about it like the author of the blog post.