What should follow the web?

The key to the web's success is its completely unparalleled levels of accessibility. All you have to do is remember a domain name and you have a portal into anyone's personal network application on any device; that feature can never be topped regardless of the tech's quality or the marketing budget.

I didn't see any mention of a plan to make it happen. It seemed more like "It would be nice if..."

That nails it.

Going off tangent here:

On a macro scale, the devices in our hands are executing output from another machine. This output is usually processed by a browser or a native app.

To make our lives easier, browsers need to be more like OSes, otherwise, we have to write code for each platform for executing the same thing - like the present native app scenario. (aware that we can use hybrid dev, but they aren't entirely satisfactory). WebAssembly holds some promise it seems. Or does it?

Browsers will become more powerful and perhaps would become the most important part of an OS. Maybe eventually, the borders between the browser and the OS will merge and the huge collection of devices and servers would look like a distributed OS of sort.

Another thing is the tooling for present web dev scene which needs to lighten. Setting up tooling takes more work than actual dev at times ;)

I agree that most platforms die due to lack of adoption. However isn't this stating the obvious? All new platforms start out with no users. Some clearly gain adoption and don't die. That's not a reason to not think about new designs.

I disagree about marketing budget. The web came from CERN as an academic project. It didn't have a marketing budget. Its primary competitor at the time (AOL) had an enormous marketing budget. In the end it didn't matter.

I also agree that security doesn't motivate developers much right now. I'm thinking about this in terms of both security and productivity for that reason.

However, I think it's possible and likely for people to care more about security in future for three reasons:

1) The consequences of breaches seem to be getting worse. The Equifax C-Suite was just completely cleaned out due to, apparently, a fairly pedestrian XML deserialisation exploit in Apache Struts (which has had lots of them). Corporate America will be sitting up and taking notice of that. When top people start losing their jobs because of mistakes of programmers at the bottom, they'll start to care about security more.

2) The ultimate consequence will be the first major conflict in which 'cyber warfare' plays a part. I hate that term personally, but it's the one governments understand. The day a major industrial nation's power grid is shut down by a much smaller and weaker country is the day that everything will change with respect to computer security. If you have never considered what happens in such a scenario, google the term "Black Start" and learn just how difficult and complex it would be to bring a country back from the brink if its entire national grid had tripped out.

3) Part of the reason nobody seems to care about security is the sheer hopelessness of it. It's impossible to care about security when you know you're going to fail. All developers who aren't delusional know that sooner or later they will fail (and probably they'll never find out). The tools are so bad that it's pointless even trying to keep up with new exploit types. I hadn't even heard of SSRF exploits before last weekend and I read tech news obsessively. If I can't keep up, I don't trust anyone who isn't a full time security specialist to keep up, but unfortunately security isn't something neatly compartmentalised into a single person.

So what can we do?

• Prepare for the worst. There will be more major breaches and eventually some sort of water or grid collapse; it seems inevitable to me. Make sure you have plenty of paper cash at home in case of a breach of payment networks.

• Prepare for the day after the worst. Figure out tools and approaches we can start to use if/when security does become a more important issue.

I and my iOS developer friends don't actually uses storyboards for actual UI in non-demo apps because it gets quirky and it's a lot easier to define from code. In Android (and other UI systems like WPF) declarative markup (XML) is often used directly with the view only used to see changes without having to compile (a problem web doesn't have, and Android is getting better at).

And now, 15 years into my career, I face the painful realization that VB remains the most productive environment I ever worked in. Yes, it was narrow. If Microsoft hadn't implemented an API for a feature, you waited for the next version.

Therefore, this question does give me pause: Why has the web failed to produce an experience as productive as several (Visual Delphi, anyone?) options over a decade ago? Competition is the web's strength. But it's also its undoing. Personally I think this article is Quixotic—and I prefer a decentralized, ineffecient (JS), sort-of secure (HTTP), competitive web to whatever top-down integration visionaries might push—but I think he—and many older developers—are asking the same question: What happened?

[0] https://m.imgur.com/a/m63BW

Also both had a plethora of components for network programming.

Finally many of those applications were a typical three tier architecture not much different than SPAs, but with a much higher developer happiness.

Beyond that, 1994 was a time when RPC was rare in apps that people would run on their desktops. Developers needed a big fat notice that a function call could involve network access because it would be an exception to the norm. Now there are few apps that don't do some sort of RPC, and people are pretty used to dealing with the latency and error-prone nature of making network calls. (Not to say people are always good at dealing with this, but they're at least aware that they're doing RPC without much fanfare needed.)

0) http://knowyourmeme.com/memes/on-the-internet-nobody-knows-y...

Another killer feature would be the ability to never lose website versions or content(like git).

Also I hope we can finally do mesh networking(with IOT?) and remove reliance on ISPs.

It only solves one part of a multipart equation: intermediate format for the web that multiple languages can compile to.

There have been many initiatives over the years to add more languages to the web platform than just JavaScript. I remember one from Google that tried to add a form of Java that had better integrated DOM access and didn't use a separate/traditional JVM (more like another mode on top of V8, iirc). There was NaCL, two attempts. Of course there were plugins as well. They were all killed off with justifications that ranged from the reasonable-sounding to the quite obviously ideological.

WebAssembly is the latest attempt to scale this wall, and what does it give us?

A new bytecode format that nothing uses and which is accepted by no hardware. It looks suspiciously similar to JVM bytecode, featuring a small set of bytecodes and a bytecode verifier, except that there's no support for expressing patterns that all high level languages have, like exceptions or garbage collected memory allocation.

The primary new capability, after years of work, seems to be that you can now embed C into a web page (as long as you bring your own C library, I guess) and run it slowly until it warms up. Although they handwavingly claim that in future they'll add GC support and that'll unlock support for other languages, it will come at a massive performance penalty that makes it effectively useless because such languages require complex JIT compiling runtimes to achieve good performance and you won't be able to do that sort of thing inside a wasm module.

The web's designers had many other options that would have been far more useful but they went with this one. What is their solution to avoid web apps now importing the world of manual memory management vulnerabilities? They don't have one: the best you get is preventing the C code from affecting the browser.

The only thing I find sadder than WebAssembly is the undeserved adulation it seems to be garnering from the web dev community. I get it - at least there's progress of sorts. But, sigh.

> I doubt it would gain traction because almost everything enumerated in this post is a developer concern, not a user concern.

That's true for any developer platform. Users ultimately don't care how software is built, unless problems of the platform hurts the quality of the apps.

I'm not sure this is true. My Mom doesn't really know the difference between an app and a website, but if I showed her the Facebook web app instead of the Facebook iPhone app I'm sure she would complain that it was not quite as responsive or didn't implement the same touch gestures.

a) Bugs. Browsers are already pretty much the most complex software out there, and they have tons of bugs. A meta-browser would be orders of magnitude more complex, and so likely have orders of magnitude more bugs.

b) Security. Special case of a) above. Browsers have had decades to gradually iron out security issues, and we still see periodic flare-ups. A meta-browser would start from scratch and be taking on a much bigger problem. You would need some way to allow people to add new engines without causing them to insert malicious code, interfere with other websites' browser engines, steal people's information, etc. It's hard enough protecting people when all malicious websites have is html and javascript. It's much worse when they have the ability to write Assembly. See https://en.wikipedia.org/wiki/ActiveX for an earlier attempt at this.

c) Adoption. Writing a browser engine is a lot of work, which is why there hasn't been a new one in a decade. If every web app had to provide a browser engine nobody would build web apps for your meta browser. Everyone would end up just using one of your default engines, at which point you're back to the current state of the world but with all the complexity of points a) and b) above.

It's worth backing up and asking yourself: what is the problem you're trying to solve. Then we can talk about whether it's really a problem and what the solution might look like, without immediately barreling down the first solution that comes to mind.

Now we have blockchain tech where names can point dynamically to content or cluster of machines. Ethereum ENS is an early version of this.

Imagine you would want a global map of places on the Internet itself. Like Open-map but so secure you can rely on it, so that self-driving cars can use it. Technically its not impossible anymore. The Web can't do that, because of single authorship of data (way less secure than multi-party authorship).

Ironically Mike Hearn has suggested such system with TradeNet [1], but apparently has missed what is happening with the evolution of blockchain tech.

The next web will be a transaction system, not a communication system - the former is a generalization of the latter. If you're interested in building these kinds of systems - we are startup building the foundations and are hiring.

[1] https://www.youtube.com/watch?v=MVyv4t0OKe4

I didn't read a single word about the idea, but I already like you, because this is the force that drives the change, not that yet another framework based on rotten primitives.

My personal view on topic is that we are in a trap now. Nobody is able to build NewBrowser in sane amount of time (or lifetime at least), so web is the only alternative. But there already are techniques almost always overlooked despite being designed for exactly this sort of thing: virtualization. While wasm looks promising, it is just another waste of engineering in the shadow of hosted full-VMs. Virtual machines already can do anything that web has to provide. Isolation, hardware abstraction, time sharing, quotas, etc. Millions of vds hosting are functioning on the same principles our browsers trying to implement.

I think that newweb must be built as a virtual machine with a little difference that it could actually access the host system to interact with user data or other "sites" or "apps". Not directly, but via networking to 169.254.254.254 or something like that for streaming and shared memory (think DMA) for intensive tasks like video streaming and accel graphics.

For those who's unsure about that approach, I can tell you that I'm running Linux operating system app in a VM hosted by Windows 7 and it talks to host via built-in samba and regular sockets. Moreover, if I need slightly another setup, I simply clone my Linux so that it shares all the data (no copy) but holds distinct changes. The same way your new frontend could just cheap-clone existing VM and apply few fixes over it to actually implement the UI.

Of course, Linux is a bad example, having startup time comparable to modern website loading. It should be really fast and lightweight, I think something like DOS+OpenGL+sound driver should do the trick.

Effectively you'd have web and newweb tabs side by side. You'd get some of the Chromium infrastructure 'for free', like user switching, the nice tab dragging code and so on. NewWeb tabs would not contain the URL bar, back button, reload button, bookmark star, extension buttons etc. But it might reduce some of the mental overhead of having to switch between 'browser' apps.

IMO what's rubbing people the wrong way is not his specific points but how he is framing them. It really does not matter how brilliant his alternative is ... it's clear that HTTP is firmly entrenched and the network effects run so deep, it would require a miracle to really "start fresh". I'd really like to be proven wrong though.

I don't think "why isn't what we have good enough" has ever been the mantra of pioneers in their field, but ok

I don't get why you seem to take such exception to the stance that "we can do better". We can always do better.

Do you imagine 500 years from now the same technologies and web models in play as today? Even 100 years from now? Do you really think they are the pinnacle of the web.

If you really do, I'd sincerely love to read your counter blog post on this, as I reflect on this quite a bit and have generally always come to the conclusion that there's a long way to go.

> This is like sitting there in 1600 and saying that the printing press sucks because it doesn't encrypt documents

If that's so, isn't your comment akin to saying "why isn't the printing press good enough for you"? :)

On the other hand, would we have cell phones, ubiquitous credit card-capable point of sale machines, and airplanes with in-flight Internet, if people hadn't dared to dream that things could be better?

Yes, children can learn basic HTML, CSS, and JavaScript. But what if we had a platform that was easy to learn and not full of security pitfalls? One can dream. And the OP has some concrete suggestions for how to get there.

And sometimes, you have to drop existing systems, or aspects of them, to get to that better future. For example, on a cell phone, you don't actually get a dial tone and send DTMF in real time, as one did on a touch-tone landline phone. (This reminds me of jacquesm's contrast of DTMF and GSM [2], posted in the comment thread for part 1.)

[1]: https://www.youtube.com/watch?v=q8LaT5Iiwo4

[2]: https://news.ycombinator.com/item?id=15322196

Just about every feature you list (apart from the distribution, got to give the web that) is stuff that we could do 20 years ago, so yes, I'm ungrateful that we've traveled so far but still gone no where, backwards in many ways.

> Children can learn HTML and CSS, modern web frameworks make it so that you can build great stuff on the back or frontend in a matter of days or weeks

Kids were doing that with basic since the 70's or 80's.

What's so bad about this? I know how to make web documents but I still do this. Email attachments are available for as long as the recipient chooses to keep them, and can't be changed once they've been sent. Sometimes that's a feature.

If your audience is any less than the entire mankind, sharing your data by the web requires an unending number of hacks and another medium where you can communicate how to jump through them.

app:microsoft/word

http://www.zdnet.com/article/double-slash-in-web-addresses-a...

But you know, that's also fine. There's nothing wrong with large platforms, especially if the reference implementation is open source. Big platforms do more work for the developer. The problem with the web platform is that it's such a bizarre mishmash of things, often designed in isolation without any specific app driving the platform forward. So you get design-by-committee standards that may or may not be implemented on any given browser.

In practice all web apps use the email address as the underlying identity. Email addresses are a decentralised identity, to a large extent. But the fact that it's so awkward for end users is pushing people towards solutions like Facebook and Google OAuth, which aren't bad, but it seems like a better design to let the browser present identity credentials instead of always having to go back to a big centralised network to get it. The scheme I propose is somewhat similar to Mozilla Persona, if that helps.

Currently the most common development approach is to develop a web app, then later an iOS and Android app. So there must be a deficiency with web apps if so many companies develop a native app even when they have already developed a web app. If Android apps also ran on Windows, Mac and iOS then they would most likely dominate web apps.

The fact you can take the capabilities and evolve the APIs continuously is the big pro here and it's a lot easier to do on the web than on other platforms.

The "binary protocol stuff" is a great example of something the web _shouldn't_ do because it can be solved in a library (and already is) and doesn't add a capability.

WebAssembly on the other hand is great since it adds a capability.

At this point where Chromium has more LoC than the linux kernel I think "boiling the ocean" is a very good analogy - and the only thing that got a little close were mobile apps.

>We also need to focus on cheapness. The web has vast teams of full time developers building it. Much of their work is duplicated or thrown away, some of what they’ve created can be reused, and small amounts of new development might be possible … but by and large any NewWeb will have to be assembled out of bits of software that already exist. Beggars can’t be choosers.

I think this is the heart of our disagreement.

App platforms that were actually designed, like iOS, Android, Java etc have all been very popular. Smartphones are ubiquitous, but the smartphone that bet most heavily on the web platform (Palm Pre) was wiped out by the smartphones that bet on relatively cleanroom designs.

Heck, the Android API isn't going win many awards for simplicity or elegance, but the BeOS and Danger people had OS design experience and pretty much knew what they were doing. Android gets far more right (in my view) than it gets wrong. The entire "app revolution" that followed the iPhone launch was more or less a huge slap in the face to the web platform. If it was really so hard to beat the web, why is all the innovation on smartphones in the native app space, with web devs getting the crumbs years later after various Apple/Google/Microsoft talking shops have finished finalising and shipping WebTiltSensor or whatever feature we have in mind?

The key difference between mobile and desktop, in my view, is deployment. Android and iOS handle deployment and upgrade for you. Desktop platforms only started trying to tackle that recently, and mostly screwed it up. The web has a great deployment story.