What should follow the web? - <AUTHOR> https://blog.plan99.net/what-should-follow-the-web-8dcbbeaccd93 <comment><USER3> Though I disagree with many of the points made here, I love that this person is taking a position and putting in the real work to to lay out his argument for it.

I think the main point he's missing is that most platforms die due to lack of adoption. The ones that succeed must attract developers and the current state of software regrettably shows that developers (and users) aren't generally motivated by security concerns -- they're motivated by more fundamental questions like "can I get the job done quickly" (users) and "can I get paid" (developers) and (importantly) "can it run on an iPhone" (which kills most new app platforms immediately).

This post focuses a lot on tech, but platforms rarely succeed for having good tech. If history's any guide, they succeed by having adequate tech and a huge pile of marketing money.

<comment><USER4> > _they succeed by having adequate tech and a huge pile of marketing money._

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.

<comment><USER5> > that feature can never be topped regardless of the tech's quality or the > marketing budget.

Never? That's a silly thing to say in the computer industry. I'm going to guess that we'll have an alternative to the web sometime in the next 20 years.

<comment><USER4> "Never" should really be "not in the foreseeable future", but certainly not within two decades. The web is the apex of incumbent systems and there is just no clear path, desire, incentive or business need that would facilitate a transition to an alternative, especially as the web approaches full feature parity with "native" code. The only people that have irreconcilable problems with the web are a certain subset of programmer, but for most people an alternative is unnecessary and perhaps even the opposite of progress.

<comment><USER5> > The web is the apex of incumbent systems and there is just no clear path, > desire, incentive or business need that would facilitate a transition to an > alternative, especially as the web approaches full feature parity with > "native" code.

I don't know about that. Considering the possibilities with AR/VR, quantum computing, machine learning, smart fabrics and environments, and the like and seems to me there could be an incentive for an alternative inside a 20 year timeframe. Will all that run over the web, or have a web interface? I tend to think at some point big technological changes will make an alternative appealing.

But maybe not and it will all be web assembly apps writing to a canvas container ;)

<comment><USER4> > _possibilities with AR /VR,_

The possibilities for multimedia and gaming are quite interesting, but there is no reason to suggest that this technology will have any impact on an any possible alternatives to the web.

> _quantum computing_

Quantum computing is in the "unforeseeable" category, we're not even entirely sure that quantum computing will ever be practical (as far as general purpose computing goes), certainly it has no implications with regard to an alternative to the web.

> _machine learning_

Same situation here. The machine learning discipline is expanding quickly and yielding very interesting developments, however, there's just no reason to suggest that machine learning will provide the impetus for a transition into a web alternative.

> _smart fabrics and environments_

Same here too.

All of these developments are orthogonal to the state of the web and none of them really provide any mechanism or incentive to create or move to an alternative.

</comment></comment></comment></comment></comment></comment><comment><USER6> > Components, modules and a great UI layout system — just like regular desktop > or mobile development.

I don't understand this - I develop for all platforms (web, iOS, Android) and web is always much faster to develop for in terms of productivity. So much that a lot of mobile developers are starting to use web stacks (like react native).

<comment><USER7> Early in my career, having mastered Visual Basic I decided it was beneath me and I'd move on to more sophisticated tools like J2EE. When Ruby was born, Java's IDEs and static tooling became stupid, because Real Developers(TM) use raw editors like vim and emacs. Years have passed, I develop less and manage more, but I still use vim and I've moved on to yet other languages.

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?

<comment><USER6> People often make this complaint with flash rather than with VB (although VB is also a nice example - thank you).

The web platform aims to solve a _very broad_ problem. I don't know if you've used VB for big projects - but as someone with lots of nostalgia for VB6 (and winforms) it got very painful around the 20K LoC mark and didn't really support complex UIs in a very efficient way.

There certainly _are_ visual builders for web design (literally hundreds - google "React UI builder" or "Angular UI builder" for some examples). They just haven't received adoption. I think it's because people always get weird UI requirements and the tools break. How many UI designers worked with you when you built UIs with VB? For me that number was 0.

In general, UI is designed today in sketch/photoshop and then a tool like Zeplin is used to export the design's properties to code automatically.

<comment><USER7> You're absolutely right: the web and its breadth of tooling solves A LOT more problems than VB or Flash could ever dream of.

<comment><USER8> I disagree. I don't know about Flash and I just assume that VB was more or less like an underpowered Delphi. The problem was not tooling at all... at least with Delphi, please see my other comment.

</comment></comment></comment></comment></comment><comment><USER9> In 1994 Sun engineers that worked on RPC published a "Note on Distributed Computing" [1] where they argue that hiding remote interactions behind interfaces that are designed to look exactly like local interfaces is not a good idea. RPC in itself is not bad, but only if the local<->remote interactions are exposed. Web with ajax makes message passing explicit and obvious, so even not experienced developers know which calls are remote (expensive and can fail). If these interactions are hidden behind RPC API the performance and reliability of apps may suffer.

The NewWeb seem to be inspired by past successful frameworks for building desktop applications, such as Delphi or Visual Basic. But these were local frameworks, NewWeb, being a local client - remote server, can't emulate these solutions by masking remote interactions, because it will end in the trap described by the Sun engineers.

[1] [https://github.com/papers-we-love/papers-we- love/blob/master...](https://github.com/papers-we-love/papers-we- love/blob/master/distributed_systems/a-note-on-distributed-computing.pdf)

<comment><USER10> I think that advice is a little outdated. Not because it's incorrect, but because we've already taken care of that distinction with common patterns. If something returns a future/promise, it's a signal that the operation is at the very least expensive, and likely non-local. That's a pattern used pretty much everywhere now, and I think developers understand what the implications are.

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

</comment></comment><comment><USER11> I know the OP isn't discussing this one until next time:

> 5\. IDE oriented development

But it should also be practical to manually edit text files as a fallback, assuming one is OK with not having niceties such as auto-completion and on- the-fly error checking. Counter-examples are Apple's .pbxproj (Xcode project) and .xib/.storyboard (Interface Builder) files.

The reason I want this is in case part or all of the IDE is unusable or just unproductive for some developers. For example, as far as I know, blind programmers can't practically create a UI in Apple's Interface Builder. Hand- editing markup like XAML is OK though.

<comment><USER12> Build tools can always be replaced. Look at autotools, cmake, scons, etc.

</comment></comment><comment><USER13> Maybe the reason why a lot of "web apps" are so complex and huge has something to do with over engineering, developers loving lazyness as a good trait of their craft. Which results in undiscipline, then you add pressures from management to produce faster rather than focus on simpler solutions. I don't see how these factors would not creep in into any "newweb" platform. Things are complex because of people, not machines. After all we made them so. Unless you have strict standards that are adhered to by lots of parties, i don't see a way out of complexity, clutter, large size .js downloads. Then you add competition which does not have anything to do with rules, rather it loves breaking them to get a higher margin. That doesn't really add simplicity to the mix. I happen to like the way the web is going and this "newweb" business sounds like the ever growing .js framework churn. I agree there are problems but definitely not structural enough to warrant a restructure. Then again that is the power of the web, anyone can pursue this.

</comment><comment><USER14> Something that should be baked in to a "new web" should be anonymity and decentralization.

We need to find a way to get out of this big brother scenario we've got ourselves into.

A "new web" would be the perfect time to fix that.

<comment><USER15> Yes! We need a web on an overlay network, so nobody truly does know that "you're a dog".[0] Or where you are. For both users and websites.

0) [http://knowyourmeme.com/memes/on-the-internet-nobody- knows-y...](http://knowyourmeme.com/memes/on-the-internet-nobody-knows-youre- a-dog)

</comment></comment><comment><USER16> Is the web not salvageable? Look at web assembly. The browser vendors added a VM and a bytecode format that runs on it. And they did it pretty quickly. In my mind, this is the way things are going to improve in web-land. Not "throw it all out and start over."

If someone/a company wants to build an "app browser" and associated protocols and publish it then the market will decide how that goes. I think it's a cool idea, but I doubt it would gain traction because almost everything enumerated in this post is a developer concern, not a user concern.

In software, there's always going to be that temptation to start all over again due to fundamental mistakes that were made years ago. But I feel there are far too many entangled interests in the web for that strategy to make sense. Hey, if someone wants to work on it, god bless them.

<comment><USER17> WebAssembly is symptomatic of the wider problems.

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.

<comment><USER18> AFAIK, WebAssembly is based on asm.js, which can be compiled from any LLVM language, not only C, using Emscripten. There are full implementations of Lua ([https://daurnimator.github.io/lua.vm.js/lua.vm.js.html](https://daurnimator.github.io/lua.vm.js/lua.vm.js.html)), Python ([http://pypyjs.org](http://pypyjs.org)) and even Java ([http://teavm.org/](http://teavm.org/)) in asm.js. You don't need to write in the C language at all.

<comment><USER17> Yes, I'm using C as shorthand for "C and C-like languages", i.e. ahead of time compiled with manual memory management. It can do C++ too if you ship your own STL.

TeaVM has some sort of experimental wasm backend. Presumably it has to ship its own GC and can't do any kind of runtime profiling, which turns out to be a 20% win for Java and far, far more for other languages (like scripting languages).

My view is: if you were looking to bring to the web better performance and higher productivity, let alone more security, _why_ would you combine low performance with low level languages? That's the worst of all worlds! And WebAssembly _will_ be low performance for a while - they have to redo all the work done so far on optimising JIT compilers.

<comment><USER19> It's better than pretending Javascript is a "bytecode for the web," and transpiling to that. It's better than Flash or Java applets. If we want to consider the long-term archiving of software and keeping it runnable through the web (and I think we _really really_ should consider that), we need something better than what we have, and WebAssembly seems like a step in the right direction.

</comment></comment></comment></comment></comment><comment><USER20> What if anyone in the world who had an idea for a "new web", could build it tonight, and have it used tomorrow?

My solution to the "new web" problem is radically different (though to be fair, trying to reinvent the web is in itself a radical idea).

I've posted my idea to many similar threads, so I apologize for repeating myself, but I feel pretty passionately about it and I feel it's a good idea to try to spread. Until I start receiving convincing evidence / arguments that the idea isn't worth spreading I'll probably continue.

Imagine if we didn't have to decide what the "new web" was going to be, BUT we did allow that experimentation to take place? I say we shouldn't make it a requirement to "convince people it's the right thing to do before it gets built and people start using it".

What if users didn't use "browsers". Instead they used "meta browsers". An application which hosts browser engines. And not only could apps / documents / etc. be downloaded by this "meta browser", but the experience of switching between browsers was also seamless to the end user. If they didn't already have that browser engine they would be prompted to download it if a particular app / document developer decided they were supporting it.

In this "new web", the "document / app" developer decides which browser engine the "meta browser" should render their app with.

What if a browser engine developer decided he didn't want to support RFC [https://tools.ietf.org/html/rfc3986](https://tools.ietf.org/html/rfc3986)

It probably feels like they're on a suicide mission (for their browser), but why should it be a "requirement"? If the ideas are bigger and better and eventually catch on (ie. things we haven't even thought of yet) why should "the web" somehow dictate what core set of ideas are the right ones?

<comment><USER21> The WWW uses DNS. Think about it: DNS evolved as an upgraded distributed hosts.txt table. Fundamentally in an entry in that name-ledger is a point to a machine which you would log into. Who gets to change that ledger? Its static.

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 - <USER2> 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](https://www.youtube.com/watch?v=MVyv4t0OKe4)

<comment><USER17> My day job is working on Corda, which is a distributed ledger platform. So I haven't missed it.

When an app identity is based on a public key, you can start to do things like load them from a BitTorrent style network (if you want to). Or define a traditional CDN as the primary entry point but have slower/more decentralised systems as backups. App identity doesn't change so locally stored data and sessions are not lost.

</comment></comment></comment><comment> aaron-lebo You've got browsers today that are finally capable of doing everything from playing interactive media, running real applications, to displaying unstyled text documents. It's really good at all of those, and it's based off of widely distributed open source tech (how many browsers are there, HTTP servers, etc).

You can reach 2 billion people for pennies. What's more, this stuff isn't hard. 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. Seriously, write a small Sinatra or Flask app. It's easy.

Why is that not good enough? We really so ungrateful to believe that reinventing everything is the right step now? Nothing is stopping anyone from taking existing tech and building great, usable, lightweight sites. Seems like focusing on that would be about a billion times more productive, yeah? You can't really expect to throw away 30 years of ongoing progress and build a better experience in months or even years without losing something.

Just seems like a bunch of fluff. He'll never build anything like it. This is like sitting there in 1600 and saying that the printing press sucks because it doesn't encrypt documents. You've got so much potential that remains unharnessed (low-hanging fruit even), and we'd rather build a new system.

<comment><USER22> As someone still familiarizing himself with all the esoteric arcana that makes up modern web development, I'm always open to reading what-ifs. The modern web to me is WTF in a lot of ways. I remember reading an article on HN about the history of CSS that was quite fascinating. I have nothing against the author's article. It is pretty interesting and I even find his other blog posts quite illuminating to read.

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.

<comment> aaron-lebo I'm open to what ifs, but I've seen enough critiques of pretty basic stuff that he's got wrong to let me know that he doesn't really understand the web as well as he thinks he does, and therefore his criticism is pretty biased, and misleading, and unlikely to produce any real solutions.

<comment><USER22> Yea? Do you mind sharing the basic stuff that he's gotten wrong? Because I learned a few things and found the article to be well researched (but what do I know ...)

<comment> aaron-lebo [https://www.reddit.com/r/programming/comments/71y6dy/its_tim...](https://www.reddit.com/r/programming/comments/71y6dy/its_time_to_kill_the_web_mike_hearn/dnepq1l/)

</comment></comment></comment></comment></comment><comment><USER23> You are thinking about how to evolve the web, while meantime the rest of the world has not yet discovered it. I mean people are still sending word documents via e-mail instead of making web documents in HTML and CSS and with an URL. When Dropbox came out you guys thought it was stupid, while normal people found it amazing that you no longer had to e-mail or print the documents in order to share them. People are using the web to search for information. Now we have to make it possible for them to also _share_ information. Sure we have Twitter and Facebook, but that's not "the web" even though many people believe it is.

<comment><USER24> >people are still sending word documents via e-mail instead of making web documents in HTML and CSS and with an URL

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.

<comment><USER23> Maybe a revision system can be baked in. Like the browser could show you what has changed since your last visit. And you could see how a web site looked like on a given date.

</comment></comment></comment><comment><USER25> Let's start with the protocol app:// and build from there.

[http://](http://) is for hypertext, app:// is for apps

app://microsoft.com/word should be explicit enough

<comment><USER26> That's not what protocols are for, though. It would still be served over http, so what you're looking to replace is actually the world wide web, or www. In other words, [http://app.microsoft.com](http://app.microsoft.com) is what you meant.

<comment><USER27> I am not so sure that all protocol schemes require that the transfer be over http. How about if I type ftp://example.com in the browser? Or https? Or gopher? :)

<comment><USER26> They don't because those are different protocols. I'm assuming he means SPAs/PWAs/hell even XUL, and not some kind of byte code application.

</comment></comment></comment></comment><comment><USER6> The reason the web is successful is because it is a relatively _small_ platform that you can build on in userland.

I think ideas like including a single binary serialization format as misguided at best - in 3 years we'll want to do something better and then what? Today we can just use protocol buffers on both sides if we please and be over with it - the web is about capabilities and not about APIs.

<comment><USER17> The web is not small by any stretch of the imagination. It already privileges _three_ different generic data structure formats: XML, JSON and data-foo tagged HTML5. It also contains support for many different image formats, including an entire animated vector graphics language, several quirks modes, an entire OpenGL stack, a low level(ish) audio API, USB support, rich text editing that is hardly used because it's too buggy ... and peer to peer video streaming. That's, like, 1/10th of what the browser alone provides. But nobody uses just the browser these days, they all add frameworks on top!

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.

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

That called organic growth and evolution with natural selection. I find it a much better way than a group of coders sit down in their ivory tower and lay down the "proper" way how I should do things because they know better than me. Good luck with that.

<comment><USER17> What lives or dies isn't actually chosen by natural selection. It's chosen by a variety of arcane closed-door meetings between the major browser vendors where they agree or disagree to implement each others specs.

<comment><USER29> That's still natural selection, with browser vendors executing the selection part.

The problem with the web is ultimately the same as with everything else in this industry - it's that _the fitness function sucks_. And that, unfortunately, is caused by economic incentives being broken, which is not a trivially fixable problem.

</comment></comment></comment></comment></comment><comment><USER30> For apps, I personally like React more than I'm willing to admit. Basically, React is MVw done right and has kindof won the JavaScript framework wars for me. My only wish would be that JSX be based on a standard syntax extension of JavaScript to handle markup literals in the language rather than using transpiling/ babel. And that React could be more readily used with a notion of web components (eg. layered on top of an independent component API).

For docs, OTOH, I think that anything going after this space has to be able to support all of HTML markup, given the massive installed base of browsers and web content. HTML as a markup language, however, has seen no love from WHATWG who focus on APIs instead, and W3C'S XML and RDF efforts for a more declarative web are epic fails. I've spent significant time to bring back SGML to the web, which remains the only standardized technology being able to completely parse HTML ([1]), and having the ability to define new markup vocabularies. One goal here is to come up with a way to publish content on the Web and on p2p at the same time, based on straightforward file replication, including for the case of limited forms of distributed authoring.

[1]: [http://sgmljs.net/blog/blog1701.html](http://sgmljs.net/blog/blog1701.html)

<comment><USER31> It's just client-side CQRS/ES with re-invented terms (due to ignorance or web bubble) slapped on top of a legacy scripting language and a document markup.

</comment></comment><comment><USER32> The part about SQL makes little sense to me. The author seems to be equating relational databases with SQL, but I don't know why. Yes, that's how everyone learns about relational databases (or the approximation thereof that SQL provides), but SQL is just one (not so awesome) language for interacting with a relational database. You could provide a binary protocol instead of or in addition to SQL for any relational database. The protocol is not the implementation!

<comment><USER17> You're right, I used SQL as a lazy shorthand for "relational database management system that definitely supports SQL but could also support other protocols in theory".

</comment></comment><comment><USER33> > To stress a point from my last article, text based protocols (not just JSON) > have the fundamental flaw that buffer signalling is all 'in band', that is, > to figure out where a piece of data ends you must read all of it looking for > a particular character sequence

While this is indeed a drawback of many text-based protocols, there's no fundamental connection between it and being text-based. Many binary protocols and formats have the same drawback. Conversely, netstrings [1] don't require scanning for delimiters, escaping any special byte values, or special behavior for netstrings-within-netstrings. They could easily be used as the basis for a text protocol (and probably have been, somewhere; BitTorrent uses something similar but not identical, mixed with delimited fields, and not text-only).

[1] [https://cr.yp.to/proto/netstrings.txt](https://cr.yp.to/proto/netstrings.txt)

<comment><USER34> tldr, a netstring is a string prefixed by it's length in ascii encoded decimal.

</comment></comment><comment><USER35> This has a "let's start all over" feel to it. That's usually not the optimal way to make big changes.

All of the design principals could be implemented and adopted incrementally within the current system (and to a greater or lesser degree _have_ been). This gives a current system a massive competitive advantage. E.g, to the extent you could convince many people to use a certain unified data representation (we have many dozens to choose between!), they can adopt it without swapping out __everything else __at the same time. They don 't need to switch to the newweb to get the part they want, so why would they? The entanglements of the current web make a wholesale switch to something else an extremely difficult sell.

</comment><comment><USER36> > 4\. Platform level user authentication

Sounds like an awful idea to me, I consider decentralized identities a huge feature of the web

<comment><USER17> Can you explain why email address client certs are less decentralised than what we have now?

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.

<comment><USER37> I may have missed it, but what about shared computers like in a library? I wouldn't want the library browser to have my certs.

<comment><USER17> You wouldn't want the library computer to have your session cookies either. There are already mechanisms to do that sort of thing, like Incognito mode or "log off wipes cookies".

</comment></comment></comment></comment><comment><USER38> How would this be meaningfully different from Java Web Start? Or Adobe AIR? Why would this succeed where those failed?

Why should we expect this platform to be better than Android?

So many choices we make when designing systems are tradeoffs "6 of one, half- dozen of the other." One side is not necessarily "better" than the other, because different tradeoffs are made. You add up thousands of these tradeoffs and now it appears that a system is full of cruft and should be thrown away.

<comment><USER39> Don't know about Adobe Air, but Java Web Start was bloated, slow, ugly, with a complicated API and poor security. Perhaps this new attempt would simply have a better implementation.

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.

</comment></comment><comment><USER40> No mention of Ted Nelson or Xanadu?

</comment><comment><USER41> Myriad discussion of part 1:

[https://news.ycombinator.com/item?id=15321015](https://news.ycombinator.com/item?id=15321015)

</comment><comment><USER42> There should be a name for the fallacy in this type of post -- perhaps the "boil the ocean fallacy".

Something as big as the web is necessarily evolved rather than designed. Obviously every programmer and their mother thinks they can design a better web. But that's not how large systems are built.

I take more of a pessimistic view of systems, as in:

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

This post seems to have a little too much optimism :)

In particular one slogan from that book is "large systems operate in a permanently degraded mode". They perform poorly and some part of them is always broken. There is massive redundancy and inefficiency.

That couldn't be more true of the web. (It's also true of things like governments and health care systems, but those things also serve their purpose to some extent.)

But this post does nothing to convince me why that won't be true of a replacement. It seems oblivious to the facts and forces of technological adoption. There is only one mention of the word "compatibility" in the post, and it's in regard to authentication. I'm not sure where all the binary protocol stuff is coming from.

Without compatibility, it's not very interesting to contemplate, because it will never happen.

There will be something beyond the web, but it won't be "like the web but with certain of my pet peeves fixed". It will have to have a fundamental new capability, like iOS/Android were to Microsoft Windows, which is another platform with an enormous network effect. Whatever new platform that comes along will coexist alongside the web for decades, just like iOS/Android and Windows do.

EDIT: The style and tone of the book can be annoying to some, but there is wisdom there. Here are some nuggets of wisdom relevant to the web:

\- _One of the problems that a system creates is that it becomes an entity onto itself that not only persists but expands and encroaches on areas beyond the original system 's purview._ \-- This is everybody's complaint about the web evolving from a hypertext platform to an app platform.

\- _Complex systems tend to produce complex responses (not solutions) to problems._ \-- Every new technology introduced on top of the web (e.g. PHP, CGI, Java applets, Flash, CoffeeScript/TypeScript, PaaS, etc.) is better viewed as a temporary response than a solution.

\- _Great advances are not produced by systems designed to produce great advances._ \-- I believe this applies to the solution proposed in the original article.

<comment><USER43> It seems as if the author makes a nod to that point:

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

<comment><USER42> Well, I'm talking more about design than implementation.

It's good he acknowledges the point about reusing existing code. But the design still seems to be ignorant of the network effects of the web, or any existing platform. It seems completely incompatible, so I don't see why anyone would use this new platform.

A good analogy: to break the Windows monopoly, superior hardware and OS X being superior barely made a dent, if count by percentages.

What you really need is iOS, i.e. brand new functionality. That's how Apple "beat" Microsoft. Platforms are generally not "replaced" with something similar but slightly better.

(And what he's describing sounds better on some fronts but worse on others.)

<comment><USER17> When Android and iOS were new, they were completely incompatible with everything else including the web. Yet somehow I find myself using Android apps every day and many mobile websites I visit try to push me towards their app version.

Console makers reset their platforms from scratch every ten years or so. New operating system, new hardware platform, often entirely new CPU architecture. Xbox is still around.

I think some people may be over-estimating the difficulty of dislodging the web. Obviously it'd be a long term endeavour. But web apps don't have a lot of network effects. If anything it's the opposite; web apps hardly integrate with each other at all, so using one rarely makes another better.

<comment><USER42> Yes, that's exactly my point... There will be new platforms, but they need significantly new functionality, like being able to carry around the Internet in your pocket.

There's a reason Steve Jobs worked hard to get Google Search, Maps and YouTube on the iPhone, and writing a completely new web browser optimized for it. The iPhone was bootstrapped off the web to some extent, and open protocols like e-mail. (It didn't have apps in the first iteration.)

Or they need a proven customer base which is willing to shell out money for games.

The web is the highly unusual case, because it was not developed by a big company, but by a grass roots effort. It was a distributed RFC/Usenet-type process as far as I can tell. But the web offered significantly new functionality -- at the time nobody in the world was using networked hypertext.

The ideas laid out in the post seem heavy on developer pet peeves rather than user functionality / monetary incentives.

As much as it pains me to say this, security is almost a developer pet peeve, in the sense that users generally don't adopt products for security reasons. I think there's evidence they use products in spite of bad security.

Of course, I would very much like a more secure web. I think it would be a worthy goal to attack only that portion, while leaving out all the rest of your proposal. As far as length prefixes, it probably makes sense for the control channel like HTTP headers, but not for the data channel like HTML.

<comment><USER17> Isn't iOS a good example of my point? Steve Jobs tried the "just write web apps, we'll keep native to ourselves" line. It was rejected by developers.

I think users will happily assign some value to security if it's offered in a meaningful way. The virus-resistance of iPhones (and to a lesser extent Android) is definitely seen as a selling point by many people, mostly for the iPad.

A lot of developers think users don't care about security. I think what is happening is that users aren't being offered real security. Rather, developers say "can I spend X hours this week on security" but the value delivered as perceived by the boss or customer is often very unclear and is often seen as near-zero, because people don't really believe programmers can write secure software. Additionally, security is often seen as a bottomless pit into which you can empty money forever with no perceptible difference in the product. The cost is far, far too high, and the likelyhood of being "secure" in the end is far, far too low.

If a platform gains a reputation for security though, as iOS has done, then people will start to trust that programmers actually mean it when they say "we can make this secure" and users will start to care more.

 _I think it would be a worthy goal to attack only that portion, while leaving out all the rest of your proposal._

It can't be done. Otherwise I'd have made such a proposal. The web is so deeply flawed, security wise, nearly nothing can be preserved. It all has to be reset.

For instance, switching to binary for the HTTP headers is already done in HTTP/2, but that hasn't had any noticeable impact on the rate of security vulnerabilities in web apps. It helps a bit: perhaps HTTP/2 is invulnerable to header splitting attacks (I'd hope so!). But the rest of the stack is still seriously flawed and that's where the bulk of the attacks are.

</comment></comment></comment></comment></comment></comment><comment><USER44> In my opinion we should eliminate _shared_ data formats as much as possible. Instead, try to define the core of this distributed system in a minimal way, perhaps it only needs an inter module messaging system and a module naming system. All other services are not standard but just modules.

So something like the browser is replaced by a micro-kernel style program and all other functionality is in outside processes. Each 'program' has a unique name in a _global_ namespace - they are are downloaded as needed and instantiated. The programming paradigms and stacks of each program are not prescribed. Programs instantiate other programs by the global name as necessary, etc.

</comment><comment><USER45> There are some interesting points. I might be wrong but it seems that the author would like to see a narrow set of technologies mandated from the front end to the backend, much more than HTTP/HTML/CSS/JavaScript (it's pretty much all that matters now). This didn't happen with the web for a reason. You can mandate end-to-end technologies when you completely control a platform (iOS, Android) but control and open web are contradictory. At best a controlled stack can succeed in a controlled subset of the web. The "do as you want" approach is what made the web successful (plus ease of deployment.) So, for example, keep sending data to the browser in the format you prefer. There are many, some good, some bad, appropriate to different needs. There is no need to mandate one which anyway is going to be obsoleted quickly. That would stifle innovation.

And about removing the back button from the browser

> the back button can be provided by the app itself when it makes sense to do > so, a la iOS.

No thanks, IMHO that's the worst UI design decision ever made by Apple. I always have to figure how to go back to the previous screen anytime somebody hands me an iPhone. On Android and in the browser is just the back button, always there in the same position.

About sessions and authentication:

> NewWeb would not use cookies. It's better to use a public/private keypair to > identify a session.

> [...]

> A client side TLS certificate is sufficient to implement a basic single > sign-on system

I'm open to those. I would generate a different key pair for every site (no SSO over the whole Internet please), add a passphrase and that's it. They'll probably going to ask me my email for the user profile so we're back to email and password but at least I'll only have to paste a password from the password manager. Note that I don't use the same email for every site (personal email, business email, customer's email, @mailinator etc) so using different keys is really important to keep separate identities. I guess it's not going to be a simple transition. Cookies provide sessions over a domain, I wonder how it's going to work with keys. Maybe "use this key for all the .x.y domain"?

</comment><comment><USER46> WeChat.

</comment><comment><USER47> Why not just improve Gopher?

</comment><comment><USER48> >> Here's my personal list of the best 5 things about the web: Deployment & sandboxing

Shallow learning curve for users and developers

Eliminates the document / app dichotomy

Advanced styling and branding

Open source and free to use

I would add:

write once, run anywhere; dynamically adapt to any viewport; incremental transfer of resources; no deployment; allows linking of views and resources

</comment><comment><USER49> I think MS got closer to this with Windows RT and its apps. They had/have a central store which causing some problems but that could be expanded.

The apps ran in a sandbox which allowed more than you might want but new, more restrictive, sandboxes could be developed.

</comment><comment><USER50> [https://news.ycombinator.com/item?id=15351141](https://news.ycombinator.com/item?id=15351141) This?

</comment><comment><USER51> The Web is an incredibly productive environment. HTML/CSS, javascript, AJAX are the core tech that make the web so productive. are there any platforms can that can be developed in less time than the web? Loose typing is not bad for productivity -> it's good for productivity.

The problem with the web is when people try to add libraries and frameworks that don't make sense for what your building - and alot of these frameworkss are just really bad for productivity, like Angular 1, etc.

</comment><comment><USER52> I like this far better than the first post, at least the author is proposing some concrete ideas that can be debated, which I think is worthwhile.

However actually going and attempting to implement this idea from whole cloth is a fool's errand. I'm not really cynical by nature, so it pains to be that guy, but in this case I just think it belies a complete naivete about how software ecosystems evolve and thrive, and why the web in particular was successful.

The web you see today bears almost no resemblance to the original proposal. What got the ball rolling was a very simple document format and protocol that made it much easier to share documents. That was a unique value-add over Email/FTP/IRC/Usenet/Gopher that drove early adoption. The reason the web is so crufty is because all the application stuff was bolted on after the fact, but here's the rub—if they had designed it for applications from the beginning it would not have been too complicated and wouldn't have taken off. There were tons of proper app development platforms that could have formed the basis for "proper" cross-platform GUI app development, but none of them could cross the chasm to true ubiquity the way the web has.

By the late 90s, the amount of effort being invested in the web was far greater than any single company or organization could ever bring to bear on a problem. 20 years later it is a deep sedimentary stack of more technologies than anyone can really keep track of, and yes it's been quite tortured and abused, and often feels extremely janky.

But tempting as it might be to think you can design something better, you really can't. You can't solve all the problems the web has solved. It will seem good when you start, but as you go you run up against the edge cases, and the scope grows, and then you have to bring in more people to solve the new problems, and you start to lose control of the design again, and you end up with an entirely new mess that people write hang-wringing blog posts about. Either that or you play benevolent dictator and try to control everything, but then adoption slows and it becomes more of a proprietary platform that never gains ubiquity.

The only tractable way to improve the web is to pick an area and work on improving it, it's not as satisfying because you have to much cruft, but it _is_ possible to slowly improve things. It takes a long time this way, but you are leveraging the millions (billions?) of man-hours that have gone into web technologies to date.

That's not to say the web is invincible, yes the web might be replaced, but it won't be replaced by someone building a better app platform (that will never gain traction, mark my words). Instead, it will be something unexpected, it will be a simple use case that, in unforeseeable ways, over time, creates an entirely new ecosystem that simply makes the web irrelevant.

<comment><USER17> _> There were tons of proper app development platforms that could have formed the basis for "proper" cross-platform GUI app development, but none of them could cross the chasm to true ubiquity the way the web has._

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.

<comment><USER52> > _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?_

Because platforms have different strengths. It's obviously not hard to design a better platform than the web for _apps_. What I'm arguing is that you can't take one of those clean room implementation and turn it into a truly cross- platform standard.

As popular as iOS, Android, Java, Flash, QT and whatever else are or have been, they are still hamstrung by being single-vendor efforts. The web on the other hand is _table stakes_ for any new computing device, _on the manufacturer 's dime_—it's not cost center or support burden for the platform "owner". This is a world of difference that's hard to overstate.

> _The entire "app revolution" that followed the iPhone launch was more or > less a huge slap in the face to the web platform._

Why? Again, they have different strengths. If you need high performance, and access to hardware then you _have_ to go native. Of course all innovation will happen in closed environments where the vendor can control the full stack and move quickly. There was no way a loose set of open standards like the web can compete with that, the results should surprise no one.

But does this mean apps are going to eclipse the web? No! Because there is still a high threshold of trust to install an app. As much as the web security model is a mess, it also has been reasonably successful at isolating the hardware environment from the on-demand functionality it delivers. Can you imagine a world where you only ever install apps for everything and never use the web? Even if you use Google and Facebook's apps, there will always be a long tail that you aren't willing to install, and the web is there for that use case. Because of this, companies _have_ to continue developing websites to serve the top of the funnel, and as they do so, they will demand more and more standards to tie into hardware etc, so slowly web standards will creep in and commoditize functionality which today is only available via native APIs.

More fundamentally, I think you underestimate the sort of worse-is-better strength of the web being document-centric but support app-like functionality. There are far more documents than apps in the world, and many of the apps deal with things resembling documents. So the web has this incredible low barrier to entry where you can throw some documents online, and then slowly build functionality around it. If you're working on apps all day, and living in SV, it's easy to see the warts and lose sight of what a powerful dynamic this is for web adoption.

I hope you can prove me wrong and come up with an idea that can revolutionize the web, it's just that it runs counter to my observation about the forces that shape standards and technology ecosystems at a higher level than individual minds and platforms.

</comment></comment></comment><comment><USER53> My prediction: Nothing is going to succeed the web.

</comment><comment><USER54> Probably something like Johnny Mnemonic

</comment><comment><USER55> So...Android? I mean, I get there's a lot of differences, and Android, the platform, would have to be much more open to begin to compete with the web. But, it ticks off an awful lot of the boxes he's named. If one could run any app in the world on Android without installing it and without significant delay, it'd be a reasonable substitute for the web, I guess (which it can, because it has a web browser, but we're back to the previously listed failings of the web).

Of course, maybe one can argue that openness is the killer feature of the web and unless Google really embraces open, it'll never surpass the web.

But, I still don't buy it. I was critical of the first article, and I'm maybe even more convinced now that the web won't be beaten by a "better 90s", which seems to be what's being proposed, in many regards. The author seems to want to reset the clock just before the web exploded, and build something new from where we were in about 1994, but with a bunch of lessons learned from the web.

Some specific areas of contention I have:

1\. IDE-oriented is a terrible idea, IMHO. IDEs are fine, I guess, but they always strike me as being indicative of insufficient/incorrect abstraction, rather than being a great productivity booster.

2\. I think designing UIs for the web is today better than for desktop apps. Maybe this is indicative of my lack of experience with desktop apps, but even when I've tinkered with Android development, I found UI builders to be tedious and frustrating, _especially_ when it comes to making them responsive. With Flexbox and Grid, and a component library, I can whip up a nice, responsive UI in minutes for the web...and I'm not even good at it!

3\. On data representation and binary formats, I tend to think everybody settling on JSON is Good Enough. It's slightly sub-optimal, but it's standardized on the front and back ends, it is universal, and it can be compressed using standard universally available tools. To me, it looks like a classic "Worse is Better" scenario. Anything else will take years to work its way into common usage.

Which brings me to the biggest issue: By the time a new platform reaches even a tiny fraction of the reach of the web, the web will have likely caught up. It is very difficult to overstate how _fast_ the web as a platform is moving today. No single developer can fathom how advanced a lot of the tools have become just in the past couple of years. I've been sort of giving myself a crash course in Node/React/etc. lately, and it's, frankly, astonishing. You can go down any of dozens of rabbit holes and find incredibly powerful tools in all sorts of domains. Building apps for the web is stupidly easy once you get over the (admittedly large) learning curve for putting all the pieces together and overcome analysis paralysis and stop reading about every new library and framework.

I guess I remain unconvinced. I come away feeling the same optimism I had for the web before reading (maybe even more, because for nearly every point he makes, I can see a clear path where someone is _already_ working on solving the problem for the web, or it already exists in a rudimentary form), and the same strong doubt that anything can beat the web short of being the result of the continuing evolution of the web.

</comment><comment><USER56> Seems like Urbit ticks at least some of these boxes

</comment><comment><USER57> gopher

<comment><USER26> RIP you glorious protocol

</comment></comment><comment><USER58> I'm honestly waiting for the return of Gopher. I'm not kidding.</comment>


Keep your code, commits and pull requests clean - <AUTHOR> https://github.com/danger/danger <comment><USER2> Maybe I miss the point, but I think the time is better invested for instance by teaching co-workers how to write commit messages. I know a lot of people who are annoyed by git to force them writing a commit message, and this attitude is bad. Changing this attitude programmatically seems overkill for me. Better speak with these people...</comment>


Ask HN: Help with Perfectionism - <AUTHOR>

There's no excuse for not delivering my projects. I have the time, and I have the expertise and the capability. When I start a new project though, I have a huge issue with making sure everything is perfect and obviously never get very far.
I know what the problem is, but I can't push past it. I've tried setting deadlines but then I just watch them pass and get into depressed-like states.
I've tried starting with extremely small projects, I was going to do a simple Electron app but I spent the first 8 hours on the icon (no joke, it was a dozen icons and I'm still not satisfied enough to move on).
To give you some background, I worked at a government contractor for a long time, and really judged/hated the code mess I had to deal with, I think that may be causing it.
I'm looking to listen to any books or talks on the subject that discusses the problem more. Has anyone received psychiatric help for this type of issue? I feel it's reached that level of severity.
Or, do I just need to always have someone manage that aspect of my life? I definitely produced a bunch of stuff when I had someone above me, but I always hated my time there because I thought I could do things better. Should I learn to accept that unhappiness? <comment><USER2> This is something I've personally struggled with as well. I don't think there is a one-size-fits-all solution but here's what helped me. Maybe it will apply to your situation.

Shipping a complete project is perhaps one of the best ways that helped me get past the "It has to be perfect" thought. In my case it was doing a few ludum dare competitions and forcing myself to submit whatever I finished after the weekend was over. After a few times of doing that it got a little easier to forgive some of the atrocious code I had written. Coding Horror has a good post on this, [http://blog.codinghorror.com/version-1-sucks-but-ship-it- any...](http://blog.codinghorror.com/version-1-sucks-but-ship-it-anyway/).

Another thing for me was getting involved in open source projects and maintaining my own. The first project I open sourced was a port so once it was in working condition I made it available for others to use. That lead to other projects that I could finally finish even though they weren't "perfect".

I wish you the best and hope you can find a way to cope with it.

<comment><AUTHOR> Thanks, I really appreciate it. I've read a LOT of things based on "shipping is a deadline" and I think I have the type of perfectionism that doesn't want anything imperfect tied to my name. I even used a throwaway for this. As far as open source goes I sometimes held on to even pushing forks to github...

I really like the idea about mini-competitions with deadlines, I have participated in some in the past but I don't know why I didn't return to them. Thanks!

<comment><USER2> I should have also mentioned that I was forced into shipping a personal project at one point because I almost went broke. So perhaps finding a friend that can push (i.e. nicely force) you to finish something would be helpful? It may also add unnecessary stress to the situation so take that advice with a grain of salt.

I'm also guessing you edited your post several times (or maybe that's just me) just to make sure it was perfect, right? So you've figured out how to "ship" your words, now you just have to figure out how to do that with projects. ;)

</comment></comment></comment><comment><USER3> I strongly believe that "perfectionism" is the most deadly way of procrastinate.

The cure is two sided, first you must work with acceptance of your inner resistance/monkey mind - books like the war of art, the dip and do the work can help you here.

Secondly you must work on shipping your product/code/content often and full of errors, this will help you accept that not perfect is okay - my biggest inspiration for this is Seth Godin's blog.

I can also reccomend the letting go book from [http://zenhabits.net/lg](http://zenhabits.net/lg)

<comment><AUTHOR> I definitely get what you're saying. Thank you, I think reading is going to help me the most, I'll check out those resources and here's links for anyone else:

The War of Art: Break Through the Blocks and Win Your Inner Creative Battles by Steven Pressfield et al. Link: [http://amzn.com/1936891026](http://amzn.com/1936891026)

Do the Work: Overcome Resistance and Get Out of Your Own Way by Steven Pressfield et al. Link: [http://amzn.com/1936891379](http://amzn.com/1936891379)

The Dip: A Little Book That Teaches You When to Quit (and When to Stick) by Seth Godin Link: [http://amzn.com/1591841666](http://amzn.com/1591841666)</comment></comment>


Apple iWork, lost features and iOS - <AUTHOR>

<comment><AUTHOR> Apple's Pages (iWork) can no longer open .rtf files!? In fact Pages can no longer open some of my "old" Pages files. I just get an error msg. Has Apple plain given up on word processors?

Or is this a sign that they have given up on file systems? If OSX iWork has been cut off at the legs to make it 100% compatible with iWork on iOS (which has far fewer features) is this then a sign that Apple's long term plan is to eliminate the desktop altogether from its products?

In any case in light of all of this why should I use iWork? I don't feel like I can trust it.

PS I've been using LaTeX for 21 years now and it has never ever let me down. In fact just last week I compiled a 20 yr old LaTeX file with no problems.</comment>


Visual Programming Is Unbelievable (2015) - <AUTHOR> http://www.outsystems.com/blog/2015/03/visual-programming-is-unbelievable.html <comment><USER2> There is one place where visual programming is alive and well and has been for a long time. That's programming PLC (Programmable Logic Controllers). It's easy to forget about PLCs[1], but it's an old and large niche in large corporations that do a lot of industrial automation like assembly lines, (automobile) manufacturing, oil & gas...

Most PLC programming is done using Ladder Logic [2] and various visual tools tools for creating and editing Ladder Logic. Here's a screenshot of one such environment, RSLogix: [https://i.ytimg.com/vi/4yEj065J1q4/maxresdefault.jpg](https://i.ytimg.com/vi/4yEj065J1q4/maxresdefault.jpg)

It's an interesting data point because A) it's a highly technical field where accuracy (and verification) matters B) almost everybody who does PLC programming spends all their time in a visual programming environment.

[1] [https://en.wikipedia.org/wiki/Programmable_logic_controller](https://en.wikipedia.org/wiki/Programmable_logic_controller)

[2] [https://en.wikipedia.org/wiki/Ladder_logic](https://en.wikipedia.org/wiki/Ladder_logic)

<comment><USER3> Another place where visual programming is popular is among music producers, with systems like Max/MSP[1] and PureData[2].

I dabbled in PureData a little, and while it seemed to be ok for simple things, I imagine that for anything even moderately complex, it would quickly become a nightmare.

While visual programming paradigms seem like a nice thing at first glance, they are missing out on whole ecosystems of tools developed over many decades for text-based programming. Things like debugging, version control, grep, search/replace, all the features of advanced text editors like vim or emacs, etc.

[1] - [https://en.wikipedia.org/wiki/Max/MSP](https://en.wikipedia.org/wiki/Max/MSP)

[2] - [https://en.wikipedia.org/wiki/Pure_Data](https://en.wikipedia.org/wiki/Pure_Data)

<comment><USER4> I don't know what your definition of a "moderately complex" program looks like, but I have to say that from my own dabbling with PureData I really enjoyed the way it handled the concepts of abstraction and encapsulation.

It's been long enough that I've forgotten the terminology, but I remember thoroughly enjoying the process of first building a widget, then meticulously arranging all of the little boxes, color-coding, and labeling various sections until it looked visually attractive. Then when I was satisfied, I could take that entire widget and abstract it away as a small box with only the relevant input/output connectors.

I guess it's always just stuck out in my mind as the one time I really dug into a visual language, and the aesthetic aspect of organizing my "code" was very appealing. It's been a decade since I last opened any of those old project files, but I can still picture many of the components I built with my mind's eye. In and of itself, that's got to be worth something.

I imagine that someday we'll see the rise of a programming metaphor that works as a hybrid of code and visual. Even though working with PureData was inspirational, I don't see text-based languages losing relevancy any time soon. However, I think that while text code is great for representing the flow of logic, higher-order organizational constructs (such as class hierarchies) might be better represented by visual relationships. If I give you a paper and pencil and ask you to map out interconnected relationships between a bunch of entities, you're probably going to start drawing boxes and lines-- and end up with something that looks a lot like PureData.

Especially if you consider the potential of future iterations on today's VR/AR concepts, I wouldn't be too surprised if programming languages eventually looked like color-coded interconnected boxes of text code that can be rearranged in space. It wouldn't even be that far-fetched to imagine animations being included to enhance a programmer's ability to visualize the flow of logic. And I don't think that such concepts should be particularly offensive to those who consider themselves to be serious programmers.

<comment><USER5> _I imagine that someday we 'll see the rise of a programming metaphor that works as a hybrid of code and visual._

You're going to enjoy the Eve language...[1][2] :-)

[1] [http://eve-lang.com/](http://eve-lang.com/)

[2] [http://incidentalcomplexity.com/](http://incidentalcomplexity.com/)

</comment></comment></comment></comment><comment><USER6> 'Visual Programming' failed (and continues to fail) simply because it is a lie; just because you surround my textual code with boxes and draw arrows showing the 'flow of execution' does not make it visual! This core misunderstanding is why all these 'visual' tools suck and don't help anyone do anything practical (read: practical = complex systems).

When I write code, for example a layout algorithm for a set of gui elements, I visually see the data in my head (the gui elements), then I run the algorithm and see the elements 'move' into position dependent upon their dock/anchor/margin properties (also taking into account previously docked elements positions, parent element resize delta, etc). This is the visual I need to see on screen! I need to see my real data being manipulated by my algorithms and moving from A to B. I expect with this kind of animation I could easily see when things go wrong naturally, seeing as visual processing happens with no conscious effort.

Instead visual programming thinks I want to see the textual properties of my objects in memory in fancy coloured boxes, which is not the case at all.

<comment><USER7> For fairly simple configuration tasks IMO visual programming is a powerful tool for non-programmer end users to actually create programs which are not prone to syntax errors, misguided loop conditions or such. It also means one does not need to learn yet another syntax. True, the application domains are limited, but for example the common node based computational graph generation done for example in Blender and other visual software works quite well.

It's not meant for professional programming, it's about empowering the end user with programmable tools.

<comment><USER6> But at what point does simple become complex? It's all well and good saying only use it for simple tasks, but when real life complexity comes knocking, you end up with this sort of magic [1] that is far worse than any C++ I've seen in the wild.

[1] [http://scriptsofanotherdimension.tumblr.com](http://scriptsofanotherdimension.tumblr.com)

<comment><USER5> People interested in VP really, really should learn about DRAKON[1], the Russian style guide for structured dataflows.

I've used it for real projects and it actually solves the spaghetti problem. Compare this:[2] with this:[3].

[1] [https://en.wikipedia.org/wiki/DRAKON](https://en.wikipedia.org/wiki/DRAKON)

[2] [http://scriptsofanotherdimension.tumblr.com/image/1386972466...](http://scriptsofanotherdimension.tumblr.com/image/138697246606)

[3] [https://upload.wikimedia.org/wikipedia/commons/0/0f/Dutch_cr...](https://upload.wikimedia.org/wikipedia/commons/0/0f/Dutch_cryo_Moscow.png)

<comment><USER7> A drakon node does not seem to support multiple input values? That's why these visual graphs get convoluted. Compute nodes deal with multiple input and output connections.

<comment><USER5> Good call. Drakon is for control flow specification, not data flow specification. However having a standard for splitting subsystems in separate modules and laying out components using regular rules would benefit any kind of visual graph.

</comment></comment></comment></comment></comment></comment><comment><USER8> "That evolution, which seems so inevitable today, brought us better graphic cards – which lead to better games, brought us the world wide web,"

It should be remembered that in the early days of the web, some people argued that it should remain text-only. Basically, if you couldn't read it on the command line with Lynx, they weren't interested. Of course, the web seemed different at 9600 baud (or even slower).

Being color-blind, I am not enthusiastic about the idea of visual programming, just because a lot of visual tools are color-coded in ways that are hard for me to work with, esp. if the default settings are not easily modified. Even syntax-coloring in a text editor is a chore to deal with.

</comment><comment><USER9> It is a very strange essay form to give multiple reasons why a thing has not worked very well, then end it with the conclusion that people just irrationally don't like it because your brain is just biased against it.

I don't believe in it in the general case simply because I've never seen a general-purpose visual programming language work. Show me one and show me lots of people choosing it freely and I'll believe just fine. I'm not holding my breath, though. (There are certainly specialized ones that meet this bar.)

Most analyses of this problem fall prey to the "anything can be made to look good if you only consider the positives of one side and the negatives of the other" effect. Visual advocates generally make wild promises about the positives of visual programming, which turn out to much harder to manifest than imagine in your head, and then make silly criticisms of textual languages, mistaking accidental issues of complexity for fundamental issues in the language. (Visual languages, just as one example, have no special protection against spaghetti code, any more than anything else does. Spaghetti code is not caused by textual languages, it's caused by developers creating spaghetti code from the spaghetti concepts in their heads.)

So not only are the analyses incomplete, examining only the positives of visual languages and the negatives of textual languages, most of the ones I see are even pretty terrible on those terms.

If you want do this, you need to look at both the pros and the cons of _both_ sides, fairly. And if you haven't got a solid set of positives on the textual side and negatives on the visual side, go back and do it again.

(I'm not saying you _must_ conclude that the net benefit is to text. You may have things that outweigh what I mentioned and your sum may come out in favor of visual programming. I'm simply saying if you can't explain in a sensible manner why text has been successful and why existing visual languages have failed, you do not have an analysis. You have a wish.)

<comment><USER6> To add to this, I present to you screenshots of visual programming spaghetti code in all of it's glory [1].

[1] [http://scriptsofanotherdimension.tumblr.com](http://scriptsofanotherdimension.tumblr.com)

<comment><USER10> So one advantage of visual programming languages, spaghetti code literally looks like a plate of spaghetti!

</comment></comment></comment><comment><USER5> That post has no clue about the shortcomings, which were true in the past but needn't be any longer. Programmers have been doing visual programming since the advent of the visual debugger that shows updated values during program execution, and they are requesting more and more of it with tools for Live Programming like jsfiddle or LightTable (for VP in classic languages) or new languages like Apparatus[1] or Eve[2].

We are in the middle of the Visual Programming renaissance, now that the hurdles that limited composability of visual programs have been theoretically solved in the last decade by Programming Languages researchers, and computers are finally powerful enough to move visual languages without slowing to a crawl.

Unfortunately, Visual Programming suffers the same curse as Artificial Intelligence: for every breakthrough that produces revolutionary new tools, it is no longer considered Visual Programming but merely "how the tools should work".

[1] [http://aprt.us/](http://aprt.us/)

[2] [http://eve-lang.com/](http://eve-lang.com/)

</comment><comment><USER11> Spreadsheets are visual programming languages, and they seem pretty popular, and have been for a while.

<comment><USER12> Not really. You still need to write formulas using a textual language.

<comment><USER11> Or selecting formulas from menus and parameters by pointing and clicking and dragging, directly manipulating rows, columns and cells, and addressing parameters by relative two-dimensional offsets.

<comment><USER12> Selecting text from lists is not visual, neither is relative 2D offsets.

</comment></comment></comment></comment><comment><USER13> At work we use a blend of C++ with Unreal Engine's visual programming language Blueprints. I am going to be honest with you guys here: I love blueprints.

They are very limited compared, lacking even maps. When it comes to connecting existing behavior together they are king. Consider the parts of game development which cannot be made generic. By sticking those in Blueprints we get nice high level code.

<comment><USER14> I was a skeptic of visual programming, but experience has taught me that Blueprints is a good enough language for a large set of tasks.

</comment></comment><comment><USER12> I found it odd there is no mention to Scratch or Scheme Bricks.

[https://vimeo.com/62615513](https://vimeo.com/62615513)

<comment><USER7> This. Scratch is the killer application of visual programming. It's educational, yes, but it's excellent at that (from experiences from my two kids).

</comment></comment><comment><USER15> Visual programming does not work well mostly due to a physical problem: typing characters into a computer is much faster and flexible at generating imperative code than using a mouse. There are declarative domains, such as simple UI building, where that is less true, but even then, when you kick out to the event handler, text is much faster.

IntelliJ has done more for visual programming, by integrating visual/wizard aspects seamlessly into a text-dominant environment, than almost all the visual programming advocates of the last fifty years.

Visual environments do demo well, and sometimes convince businessmen that they won't need to pay those annoying and expensive programmers so much money. Hence its enduring appeal to the business world.

</comment><comment><USER16> I think visual programming would match some problem domains very well, such as games (Unreal Blueprints), music (Reason, Max, PD), Neural Nets (???), UI (Quartz Composer), robotics (???), as well as the already mentioned spreadsheets. Most of these domains focus on flow and transition of scalars. The problem that I've had in the past with PD and MAX is in coordinating of multiple inputs that flow into a node. Sometimes I'd have to create a special node to properly sequence inputs. But, that is a limitation of the tool, not the idiom.

Another problem is how to explore and manipulate a flow graph? I like the idea of using a force directed graph. Here is one, where I mapped a visual music synthesizer to Jeffry Heer's Prefuse toolkit: [https://www.youtube.com/watch?v=a703TTbxghc](https://www.youtube.com/watch?v=a703TTbxghc)

Would love to explore authoring flow, using force directed graphs on an iPad pro + pencil (and its ilk), where one could not only draw arc between nodes, but also between convex hulls of a collection of nodes.

</comment><comment><USER17> I'm currently working on a developer tool that leverages the advantages of visualization not for writing source code, but for navigation and understanding. Coati, a source explorer for C/C++, combines graph visualization and source code interactively. The graph makes it easy to see what relationships a class or a function has, while the code still provides all the details of the implementation.

[https://www.coati.io/](https://www.coati.io/)

<comment><USER18> So it would be like a souped-up Visual Assist (as used in VS C++)?

</comment></comment><comment><USER19> Here is a comprehensive list of different visual programming languages.

[http://blog.interfacevision.com/design/design-visual- progarm...](http://blog.interfacevision.com/design/design-visual-progarmming- languages-snapshots/)

The issue isn't visual programming but rather that we haven't found many good cases to use it still.

I do think visual programming is going to have a bigger and bigger impact in things like robotics, space exploration etc where you need more tactile access to computation power.

It's kind of like with the idea of a 3d interface. It only make sense when the holistic whole rather than the details are important.

It makes no sense to create a 3d warehouse I can walk around when I could just do a search and a list.

But you wouldn't necessarily want to control a robot doing repairs on your spaceship by having to program it every time you wanted it to do something new.

</comment><comment><USER20> Similar discussion here: [https://news.ycombinator.com/item?id=11204017](https://news.ycombinator.com/item?id=11204017)

(From my submission just 6 days ago.)

</comment><comment><USER21> The problem with visual programming is the same as those UML tools where you designed classes with boxes then filled in the code later. First of all it's quicker and easier to define with text than drawing. And second of all the detail is the important bit. You can't design the high level code in isolation and then fill in how it works. You need to build up the components from the details and see how the abstractions emerge. And that's not very visual/.

</comment><comment><USER22> Visual programming is exploding in Unreal Engine with Blueprints to define in- game behaviours.

[https://docs.unrealengine.com/latest/INT/Engine/Blueprints/i...](https://docs.unrealengine.com/latest/INT/Engine/Blueprints/index.html)

I for myself think visual programming is not really programming, since by following that train of thought any GUI like Photoshop Actions could be considered programming.

</comment><comment><USER23> Can't communicate visually. The translation between written and spoken words, even made up technical words, is fast, accurate, unambiguous. Visual means slow, inaccurate, ambiguous, which is sometimes cool for art, but not for communication.

It would be like trying to program musically, or by touch, or by (oh no) smell.

There is also the productivity danger of futzing, or whatever the modern term is. In the early desktop publishing era, we were promised that instead of taking ten minutes writing a memo, we'd type one in five minutes, but reality was we'd spend an hour using a minimum of seven fonts and three text colors and pictures. So much for productivity improvement! Likewise a visual programming language would invite people with authority but no ability to endlessly rearrange "put that box over there, looks nicer" "Make that text red" "that needs a larger font".

<comment><USER24> Except we can perfectly communicate visually, and we do it all the time.

It is common to draw diagrams when you are trying to understand or explain a problem. If you want to give somebody a rough idea of how your program works, it is infinitely more likely that you use some kind of drawing than music, touch or smell.

I don't agree neither with visual programming inviting people to lose time in details. The same you do not lose time thinking about how to structure a sentence to write a program, you would not lose it changing colors and fonts in a visual programming environment with an enforced "syntax".

I do not like visual programming (I have had very bad experiences with LabView), but I think it may be as good (or as bad) as text if the field had evolved differently.

<comment><USER25> Visual communication without language is always much simpler and more abstract than other forms of visual communication. Without invoking a language with syntax, you simply cannot get enough information density to make it useful.

The only time we generally communicate visually is when we want to express something with less detail (e.g. charts, diagrams, graphs, emoji, etc).

</comment></comment></comment><comment><USER26> The title sounds like it comes from BuzzFeed.

</comment><comment><USER27> _...otherwise you might just end up in the wrong side of history._

And I don't believe it worked within the US Army [0][1][2] - unless I'm not correctly remembering the history of Outsystem's Visual Programming there...

[0] [https://www.outsystems.com/company/news/2012/outsystems- us-a...](https://www.outsystems.com/company/news/2012/outsystems-us-army/) [1] [http://www.army.mil/article/96352/SEC_s_Cloud_Mil_solution_f...](http://www.army.mil/article/96352/SEC_s_Cloud_Mil_solution_for_DoD/) [2] [http://www.afcea.org/content/?q=us-army-innovates-cloud- comp...](http://www.afcea.org/content/?q=us-army-innovates-cloud-computing- front)

</comment><comment><USER28> I interned at VPL Research[1] in 1992 and they had a Mac-based VPL for controlling objects in VR called Body Electric[2] that was really fun to use - especially since I'd never seen anything like it. I implemented gravity for objects and a virtual arm using it. If I remember correctly, debugging could be a challenge. It was later interfaced with Macromedia Director[3] to control desktop apps.

[1] [https://en.wikipedia.org/wiki/VPL_Research](https://en.wikipedia.org/wiki/VPL_Research)

[2] [http://www.jaronlanier.com/vpl.html](http://www.jaronlanier.com/vpl.html)

[3] [http://www.art.net/~hopkins/Don/lang/bounce/bounce.html](http://www.art.net/~hopkins/Don/lang/bounce/bounce.html)

</comment><comment><USER29> Software developed using visual programming languages often has the potential/necessity to include content which constitutes a 'visual/non-visual hybrid' as the application becomes more complex: the boxes to which arrows are connected usually contain things which are lines of text/symbols/formulae, i.e. are not 'diagrammatic'. Visual programming languages tend to use diagrams for structure and 'notationally rich text' for content and are therefore addressing requirements for simplifying the representation of and increasing the intelligibility of the structure of application development as their highest priority. The reason why this rationale can seem to be problematic is because justifying/achieving the job of meaningfully 'separating structure from content' in software brings it's own highly contingent/subjective challenges (as any detractor of object-oriented design will be aware). For instance, how far could/should you go in trying to 'diagrammatise' the notational content of boxes in a boxes and arrows language. Is the fact that you are diagrammatising the app at all enough of a benefit in terms of reducing the learning curve/programming aptitude requirement, such that 'further/total diagrammatisation' is nothing more than a 'diminishing returns' consideration? What criteria do you use to decide the 'diagramtic benefit limit'? The biggest growing business in software development today is 'triple A games development' and visual programming languages are used as a way of giving designers the means to create content and gameplay without requiring the designer to have programming skill levels that match those of developers (developers can then optimise the designer's work by converting it into C++ to get the frame rate up and integrating it with the rest of their native codebase). Here's an example of an impressive case in point done in UE4 Blueprints without a single line of C++: [https://www.youtube.com/watch?v=EjCandEgtHo](https://www.youtube.com/watch?v=EjCandEgtHo)

</comment><comment><USER30> I don't get it - isn't the Outsystems Platform (following the link from the blog) a visual programming environment? This article seems very odd coming from Outsystems itself. What am I missing here?

<comment><USER31> They are probably dissatisfied with developer stance toward their RAD framework.

I'm sure various business apps can be built successfully on top of their Visual programming IDE, but even Microsoft has mostly abandoned that route.

But I dislike that even they propagate the lie that systems are slow when built on top of "High level language". That is mostly an optimization problem and you can often optimize well beyond what people would be willing to do in lower level language.

</comment></comment><comment><USER32> I worked quite a bit with Outsystems and like with all the tools that use boxes(/balls) with lines between them as 'visual programming', it depends largely on how you organise things if / when it becomes a big mess. After a while of working with it we usually just wrote what we needed in C# and when we had very abstract things hooked them up. It looks/works well but needs a lot of discipline (and thus training) and it's crazy expensive (for what it does) imho.

</comment><comment><USER33> No mention of the Deutsch limit:

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

</comment><comment><USER34> Smalltalk is pretty close. I use the GNU one (yeah, I know about Pharo) and is awesome you can switch between a Smalltalk scripting and the VisualGST browser.

</comment><comment><USER35> Is there any visual programming language well-suited to implementing complex data structures like red-black trees? What about a recursive descent parser? File system?

I have not used visual languages extensively, but it seems like they are better suited to simple control flows with flat data structures and limited state mutation. This would explain their success for graphics shaders, audio, industrial control, etc.

</comment><comment><USER36> Quartz Composer is a pretty effective visual programming environment. At least as far as a particular problem domain is concerned.

<comment><USER37> To illustrate of what is possible with Quartz Composer: [https://youtu.be/eUEr4P_RWDA](https://youtu.be/eUEr4P_RWDA)

</comment></comment><comment><USER38> We use a visual programming system in our startup's game development tool Construct 2 [1].

We may not be Visual Basic big (yet!) but we're running a successful business on a visual programming IDE with lots of users who love it!

[1] [https://www.scirra.com](https://www.scirra.com)

</comment><comment><USER18> I have many time mused at having visual elements integrated into your code, to better explain or schematize some concepts (which many times cannot be easily explained by mere comments). The future is not visual programming, it's augmented textual programming (ATP). You heard it here first folks.

</comment><comment><USER39> I used RAPTOR in a generic programming class at community college when trying to get into grad school 3.5 years ago. I was somewhat impressed with it, despite the bugs.

[http://raptor.martincarlisle.com/](http://raptor.martincarlisle.com/)

</comment><comment><USER7> Visual programming is doing quite well in editing computational graphs in software such as Maya or Blender.

</comment><comment><USER40> IMO, Visual programming does not have a proper definition yet. Coding frontend and coding backend are altogether two different things and sometimes users confuse the application of visual authoring (programming) in one area with the other.

But I believe it is the future. I bet you won't be carrying your laptop, enslaved by the physical keyboard, which is necessary for traditional 'coding' with you in 2030. You would be dragging and dropping stuff, perhaps in Virtual reality headset or through voice or gesture to build what you want, just like you would author in a visual platform like Adobe illustrator or in a 3d authoring tool.

Visual programming have it's own strength and weaknesses. For e.g. Creating algorithms from scratch in a Visual programming is not very productive (yet), but authoring business logic is highly effective in Visual programming. How many times, as a regular programmer you have had to write an algorithm? Most often it's just business logic that we tag under the category of an algorithm, which is not right. Algorithms are very generic piece of logic and business logic applies to your own problem/data specifically. If you have a closer look you realize that we are simply reusing algorithms or modules (created by a smaller group of people comparatively) to build the rules/business logic. What we do is mostly write glue code. we don't really need to code for that.

There are tons of examples for highly successful application of visual programming. But as an average web developer you never get to see that. Reason - Visual authoring tools are highly expensive and hence are confined to fortune 500 companies. That along with lack of quality open source implementations are the reason for visual programming to never take off among general web programming community. Even the newer generation ones like Treeline (for backend) and Bubble.is (frontend) are also closed source. NoFlo is open source and it almost started to create some buzz, but the team got sidetracked apparently, and they are using dataflow method for authoring frontend which is a highly inefficient.

You want to see successful application of Visual programming in real life? Ever heard of Enterprise Application Integration (EAI) ? Business Process Automation (BPMN/BPEL) ? Extract Transform and Load (ETL)? They all employ Visual programming to a great extend and are multi-billion dollar businesses. Do a google image search of following, in no particular order.

Dell bhoomi (EAI)

Tibco Business Works (EAI)

Snaplogic (Founded by Informatica ex. CEO) (EAI)

MuleESB/Anypoint studio (EAI)

Oracle BPEL (Business process automation)

Tibco iProcess (Business process automation)

Mendix (Web app development)

Webratio (Web app development)

(+lots of others if you dig out)

<comment><USER25> > I bet you won't be carrying your laptop, enslaved by the physical keyboard, > which is necessary for traditional 'coding' with you in 2030.

I disagree. I wouldn't have thought that Microsoft, author of Visual Basic, would be basically forced in 2015 to add improvements to their console system -- but here we are. If anything text-based programming is more prominent now than in the last 10 years.

> You would be dragging and dropping stuff, perhaps in Virtual reality headset > or through voice or gesture to build what you want, just like you would > author in a visual platform like Adobe illustrator or in a 3d authoring > tool.

Your arms will get very tired.

> but authoring business logic is highly effective in Visual programming.

I disagree. We have one giant visual-programmed workflow solution and it's a very modern and powerful system but it's also insane to work with. You can describe the problem in text with much clearer than trying to follow a diagram that won't fit on a dozen screens in either direction.

> Reason - Visual authoring tools are highly expensive and hence are confined > to fortune 500 companies.

They are snake-oil; nearly something you can only sell for millions of dollars to people who make billions of dollars. You need a team of highly paid expert consultants to make changes because nobody else knows these systems or wants to know them. It's like going back 30 years in terms of expressive power.

<comment><USER40> >Your arms will get very tired. Ha ha, What about voice? Even without fancy stuff like gesture or voice, actually it wont be tiring. In fact if you prefer to use keyboard, you can solely work using pure keyboard to perform all of the visual wiring using configured shortcuts. It would be then much less effort (in terms of typing) that in traditional coding, as you don't need to do any boilerplate coding.

> I disagree. We have one giant visual-programmed workflow solution.

Why couldn't you break it up into multiple sub-workflows?

> They are snake-oil

Agreed. we need great open source solutions to move the needle from where it's been stuck for over several decades.

<comment><USER25> > Why couldn't you break it up into multiple sub-workflows?

Oh it _is_ broken up into multiple sub-workflows. There is even a way to call workflows like functions and there is a workflow that decodes XML.

</comment></comment></comment></comment><comment> gat-bitty I loved using labview when I was in test automation

</comment><comment><USER41> Gnu Radio Control is a perfectly fine visual language for its problem domain: [http://www.joshknows.com/grc](http://www.joshknows.com/grc)</comment>