16 ms·

What should follow the web?

167 points by telotortium 9y ago

Entangled 9y ago
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
- kbenson 9y ago
  What should app:// support that http:// http:// doesn't? Or, from another direction, what should http:// http:// have restricted that it currently allows that we can allow app:// to handle instead? (and let's ignore the impossibility of carrying that out, since the discussion might be informative anyway)
  - majormajor 9y ago
    The question you have to answer if you want a web-like thing is "how do we solve the problems of the current web for devices like phones, tablets, and TVs?" Then you have something that can potentially stem the move of eyeballs from an open and linkable web back to a bunch of clustered-off apps. In other words, I think the question to be answered first is the fundamental browsing UX challenge for non-desktop devices, where you don't have mouse/keyboard all the time and browser apps are less always-open. The author is mostly focused on security, but that alone won't move big groups of users. Much of what he describes reads to me as copying the current UX state of phone apps, not leapfrogging them.
- irrational 9y ago
  Or app: and http: app:microsoft/word http://www.zdnet.com/article/double-slash-in-web-addresses-a-bit-of-a-mistake/ http://www.zdnet.com/article/double-slash-in-web-addresses-a...
- MentallyRetired 9y ago
  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.
  - ehnto 9y ago
    That doesn't have to be true. An app protocol could have, for one example, a structured always open connection and a new set of useful verbs/actions that are more conducive to apps. It could tell the browser to use a different rendering path with a different more comprehensive base UI set for another example. These are already possible by retrofitting existing technology but the question being asked is what would a reimagined, more app friendly web platform look like.
  - wongarsu 9y ago
    Though in practice, subdomains are rarely used in that sense anymore (both www. and ftp. are declining in usage), while the protocol is used to determine the program that should handle the request. Maybe https+app://microsoft.com is better? (plus signs are valid in uri schemes)
  - EGreg 9y ago
    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? :)
    - MentallyRetired 9y ago
      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.
  - hossbeast 9y ago
    No, it would not be served over http. Consider ftp://microsoft.com - is that also served over http?
- ericflo 9y ago
  I think you're looking for exp:// https://expo.io/ https://expo.io/
  - dikaiosune 9y ago
    (I work on Expo) We just use this protocol/schema to make sure that development URL links are tappable on your phone. Checking a URL domain works for lots of deep links, but not when you have IP addresses or dynamically generated ngrok URLs (like when loading an app from XDE). You might ask, why do this when you can just scan or screenshot the QR code? Fun bit of tech debt: the current QR-scanning system was added to support the offline-only create-react-native-app setup, and the "send a link by SMS" flow predates that. If you've received an SMS with your development URL, it's pretty useful to have it tappable. Related, this detail of the XDE <-> client app connection isn't really what people use for production, it's just for development and sharing with coworkers in most cases. To ship a "production" Expo app, users typically build an IPA or APK for uploading to the App Store and/or Play Store, where this URL is hidden from them.
- kowdermeister 9y ago
  Your added value here is -1 character.
stablemap 9y ago
Myriad discussion of part 1: https://news.ycombinator.com/item?id=15321015 https://news.ycombinator.com/item?id=15321015
aaron-lebo 9y ago
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.
- stuxnet79 9y ago
  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.
  - aaron-lebo 9y ago
    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.
nicklaf 9y ago
No mention of Ted Nelson or Xanadu?
Animats 9y ago
WeChat.
enriquto 9y ago
gopher
- MentallyRetired 9y ago
  RIP you glorious protocol
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
inglor 9y ago
> 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).
- inglor 9y ago
  Even in platforms that _have_ "NetBeans UI Builder" like tools people tend to not use them. I and my iOS developer friends don't actually uses storyboards for actual UI in non-demo apps because it gets quirky and it's a lot easier to define from code. In Android (and other UI systems like WPF) declarative markup (XML) is often used directly with the view only used to see changes without having to compile (a problem web doesn't have, and Android is getting better at).
  - ivm 9y ago
    Xcode's Interface Builder is just dated. Try Unity3d's component-based UI system with live editing during the "Play mode". It's so great to build everything visually with a tool like this.
- flukus 9y ago
  Much of that is because the android tools are absolutely horrid, they tried to make things simple but ended up making them insanely complicated. Compare a hello world tutorial for android (http://www.tutorialspoint.com/android/android_hello_world_example.htm http://www.tutorialspoint.com/android/android_hello_world_ex...) with one for the desktop (https://developer.gnome.org/gtk-tutorial/stable/c39.html#SEC-HELLOWORLD https://developer.gnome.org/gtk-tutorial/stable/c39.html#SEC...) to get an idea of just how crazy android is.
- kbuchanan 9y ago
  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?
inglor 9y ago
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.
- mike_hearn 9y ago
  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.
  - kowdermeister 9y ago
    > 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.
    - mike_hearn 9y ago
      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.
autarch 9y ago
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!
- mike_hearn 9y ago
  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".
mwcampbell 9y ago
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.
- thomastjeffery 9y ago
  Build tools can always be replaced. Look at autotools, cmake, scons, etc.
evmar 9y ago
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.
- projectant 9y ago
  Maybe the future history of the web will be Chinese made. Multiple independent app platform on Android there. Also if standardization is slow and mired by incumbent company interests maybe something capable of a unilateral forward thrust into a big Market will have success
- root_axis 9y ago
  > 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.
  - pjmlp 9y ago
    Surely there is an app for that.
    - fro0116 9y ago
      I think it's called a web browser. ;)
trgv 9y ago
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.
- jacquesm 9y ago
  Web assembly is a step backwards, not forwards.
  - markdog12 9y ago
    Care to expand on that?
    - jacquesm 9y ago
      View Source is a feature, not a bug. Having third party JS was bad, having third party wasm will be a lot worse.
      - markdog12 9y ago
        I like the spirit of View Source, but in practice js is already obfuscated with minification.
        jacquesm 9y ago
        Sure, but that's no reason to make it worse on purpose.
Tenobrus 9y ago
Seems like Urbit ticks at least some of these boxes
arkis22 9y ago
> 4. Platform level user authentication Sounds like an awful idea to me, I consider decentralized identities a huge feature of the web
- Pxtl 9y ago
  I, on the other hand, don't love managing dozens of passwords. And either way, a browser could easily offer multiple identities via multiple email accounts if you desired under their model.
- mike_hearn 9y ago
  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.
  - christophilus 9y ago
    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.
    - mike_hearn 9y ago
      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".
  - arkis22 9y ago
    According to wikipedia: > The decentralization aspects of the protocol reside in the theoretical support of any identity provider service, while in practice it seems to rely mainly on Mozilla's servers currently So we'd be putting all our eggs into Mozilla's basket, and we'd be screwed if they got hacked. There are also websites that do not use email addresses as identity, HN for instance.
chubot 9y ago
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.
- inglor 9y ago
  I think that's why the web is so successful. No one likes the DOM APIs but they provide important capabilities and people just wrap them anyway. The fact you can take the capabilities and evolve the APIs continuously is the big pro here and it's a lot easier to do on the web than on other platforms. The "binary protocol stuff" is a great example of something the web _shouldn't_ do because it can be solved in a library (and already is) and doesn't add a capability. WebAssembly on the other hand is great since it adds a capability. At this point where Chromium has more LoC than the linux kernel I think "boiling the ocean" is a very good analogy - and the only thing that got a little close were mobile apps.
deleted 9y ago
[deleted]
0xcde4c3db 9y ago
> 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
- hossbeast 9y ago
  tldr, a netstring is a string prefixed by it's length in ascii encoded decimal.
RndUsr 9y ago
>> WebAssembly is the only effort to add a new web language, and that language is C … No, it's not. As far as I know C++ and Rust already work. And GC support is coming, isn't it? >> The core of my personal NewWeb design would be the JVM. Should we expect 60 something MB "NewWeb" apps that would require tons of RAM? P.S.: The most important thing about Web is the distribution aspect. I don't have to pay Google, Shmoogle, Apple, ask their permission or whatever. Root DNS could be replaced by a decentralized solution but otherwise it's perfect. OP's posts make an impression that this is the aspect that is not of interest to him. No way I would ever start using Google Play, Ubuntu One or anything like that over Web.
dasil003 9y ago
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.
datashovel 9y ago
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?
- yorwba 9y ago
  Can you explain how your meta-browser should differ from an ordinary operating system? I.e. additional functionality it would have when not compared to a browser, but to the substrate browsers currently run on.
  - datashovel 9y ago
    In a nutshell. It would only be a simple shell, with extremely minimal API (for user settings, etc), which could sandbox browser engines. This (a) makes "switching between browsers" a seamless experience to the end user, (b) makes the development experience much more friendly to the developer [since they're developing for their browser engine of choice].
shalabhc 9y ago
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.
X86BSD 9y ago
I'm honestly waiting for the return of Gopher. I'm not kidding.
tannhaeuser 9y ago
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
- 201709User 9y ago
  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.
SwellJoe 9y ago
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.
Udik 9y ago
>> 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
jv22222 9y ago
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.
- mirimir 9y ago
  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-youre-a-dog http://knowyourmeme.com/memes/on-the-internet-nobody-knows-y...
- whataretensors 9y ago
  Yes, I'm hoping something like IPFS is in our future. Another killer feature would be the ability to never lose website versions or content(like git). Also I hope we can finally do mesh networking(with IOT?) and remove reliance on ISPs.
creatrixcordis 9y ago
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.
rhabarba 9y ago
Why not just improve Gopher?
pmontra 9y ago
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"?
mixedbit 9y ago
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/distributed_systems/a-note-on-distributed-computing.pdf https://github.com/papers-we-love/papers-we-love/blob/master...
- pjmlp 9y ago
  There were tons of Delphi and Visual Basic projects written with DCOM and MTS in mind. Also both had a plethora of components for network programming. Finally many of those applications were a typical three tier architecture not much different than SPAs, but with a much higher developer happiness.
- kelnos 9y ago
  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.)
z3t4 9y ago
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.
- sjy 9y ago
  >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.
  - z3t4 9y ago
    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.
- marcosdumay 9y ago
  The web is a publishing medium. It sucks a lot as a sharing medium. If your audience is any less than the entire mankind, sharing your data by the web requires an unending number of hacks and another medium where you can communicate how to jump through them.
mattacular 9y ago
My prediction: Nothing is going to succeed the web.
aaronhoffman 9y ago
Probably something like Johnny Mnemonic
jmull 9y ago
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.
dangoor 9y ago
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.
- MarkMc 9y ago
  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.
pascalxus 9y ago
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.
type0 9y ago
https://news.ycombinator.com/item?id=15351141 https://news.ycombinator.com/item?id=15351141 This?
jbergens 9y ago
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.

167 points by telotortium 9y ago

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

kbenson 9y ago
What should app:// support that http:// http:// doesn't? Or, from another direction, what should http:// http:// have restricted that it currently allows that we can allow app:// to handle instead? (and let's ignore the impossibility of carrying that out, since the discussion might be informative anyway)
- majormajor 9y ago
  The question you have to answer if you want a web-like thing is "how do we solve the problems of the current web for devices like phones, tablets, and TVs?" Then you have something that can potentially stem the move of eyeballs from an open and linkable web back to a bunch of clustered-off apps. In other words, I think the question to be answered first is the fundamental browsing UX challenge for non-desktop devices, where you don't have mouse/keyboard all the time and browser apps are less always-open. The author is mostly focused on security, but that alone won't move big groups of users. Much of what he describes reads to me as copying the current UX state of phone apps, not leapfrogging them.
irrational 9y ago
Or app: and http: app:microsoft/word http://www.zdnet.com/article/double-slash-in-web-addresses-a-bit-of-a-mistake/ http://www.zdnet.com/article/double-slash-in-web-addresses-a...
MentallyRetired 9y ago
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.
- ehnto 9y ago
  That doesn't have to be true. An app protocol could have, for one example, a structured always open connection and a new set of useful verbs/actions that are more conducive to apps. It could tell the browser to use a different rendering path with a different more comprehensive base UI set for another example. These are already possible by retrofitting existing technology but the question being asked is what would a reimagined, more app friendly web platform look like.
- wongarsu 9y ago
  Though in practice, subdomains are rarely used in that sense anymore (both www. and ftp. are declining in usage), while the protocol is used to determine the program that should handle the request. Maybe https+app://microsoft.com is better? (plus signs are valid in uri schemes)
- EGreg 9y ago
  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? :)
  - MentallyRetired 9y ago
    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.
- hossbeast 9y ago
  No, it would not be served over http. Consider ftp://microsoft.com - is that also served over http?
ericflo 9y ago
I think you're looking for exp:// https://expo.io/ https://expo.io/
- dikaiosune 9y ago
  (I work on Expo) We just use this protocol/schema to make sure that development URL links are tappable on your phone. Checking a URL domain works for lots of deep links, but not when you have IP addresses or dynamically generated ngrok URLs (like when loading an app from XDE). You might ask, why do this when you can just scan or screenshot the QR code? Fun bit of tech debt: the current QR-scanning system was added to support the offline-only create-react-native-app setup, and the "send a link by SMS" flow predates that. If you've received an SMS with your development URL, it's pretty useful to have it tappable. Related, this detail of the XDE <-> client app connection isn't really what people use for production, it's just for development and sharing with coworkers in most cases. To ship a "production" Expo app, users typically build an IPA or APK for uploading to the App Store and/or Play Store, where this URL is hidden from them.
kowdermeister 9y ago
Your added value here is -1 character.

stablemap 9y ago

Myriad discussion of part 1: https://news.ycombinator.com/item?id=15321015 https://news.ycombinator.com/item?id=15321015

aaron-lebo 9y ago

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.

stuxnet79 9y ago
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.
- aaron-lebo 9y ago
  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.

nicklaf 9y ago

No mention of Ted Nelson or Xanadu?

Animats 9y ago

WeChat.

enriquto 9y ago

gopher

MentallyRetired 9y ago
RIP you glorious protocol

deleted 9y ago

[deleted]

deleted 9y ago

[deleted]

inglor 9y ago

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

inglor 9y ago
Even in platforms that _have_ "NetBeans UI Builder" like tools people tend to not use them. I and my iOS developer friends don't actually uses storyboards for actual UI in non-demo apps because it gets quirky and it's a lot easier to define from code. In Android (and other UI systems like WPF) declarative markup (XML) is often used directly with the view only used to see changes without having to compile (a problem web doesn't have, and Android is getting better at).
- ivm 9y ago
  Xcode's Interface Builder is just dated. Try Unity3d's component-based UI system with live editing during the "Play mode". It's so great to build everything visually with a tool like this.
flukus 9y ago
Much of that is because the android tools are absolutely horrid, they tried to make things simple but ended up making them insanely complicated. Compare a hello world tutorial for android (http://www.tutorialspoint.com/android/android_hello_world_example.htm http://www.tutorialspoint.com/android/android_hello_world_ex...) with one for the desktop (https://developer.gnome.org/gtk-tutorial/stable/c39.html#SEC-HELLOWORLD https://developer.gnome.org/gtk-tutorial/stable/c39.html#SEC...) to get an idea of just how crazy android is.
kbuchanan 9y ago
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?

inglor 9y ago

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.

mike_hearn 9y ago
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.
- kowdermeister 9y ago
  > 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.
  - mike_hearn 9y ago
    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.

autarch 9y ago

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!

mike_hearn 9y ago
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".

mwcampbell 9y ago

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.

thomastjeffery 9y ago
Build tools can always be replaced. Look at autotools, cmake, scons, etc.

evmar 9y ago

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.

projectant 9y ago
Maybe the future history of the web will be Chinese made. Multiple independent app platform on Android there. Also if standardization is slow and mired by incumbent company interests maybe something capable of a unilateral forward thrust into a big Market will have success
root_axis 9y ago
> 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.
- pjmlp 9y ago
  Surely there is an app for that.
  - fro0116 9y ago
    I think it's called a web browser. ;)

trgv 9y ago

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.

jacquesm 9y ago
Web assembly is a step backwards, not forwards.
- markdog12 9y ago
  Care to expand on that?
  - jacquesm 9y ago
    View Source is a feature, not a bug. Having third party JS was bad, having third party wasm will be a lot worse.
    - markdog12 9y ago
      I like the spirit of View Source, but in practice js is already obfuscated with minification.
      - jacquesm 9y ago
        Sure, but that's no reason to make it worse on purpose.

Tenobrus 9y ago

Seems like Urbit ticks at least some of these boxes

arkis22 9y ago

> 4. Platform level user authentication Sounds like an awful idea to me, I consider decentralized identities a huge feature of the web

Pxtl 9y ago
I, on the other hand, don't love managing dozens of passwords. And either way, a browser could easily offer multiple identities via multiple email accounts if you desired under their model.
mike_hearn 9y ago
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.
- christophilus 9y ago
  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.
  - mike_hearn 9y ago
    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".
- arkis22 9y ago
  According to wikipedia: > The decentralization aspects of the protocol reside in the theoretical support of any identity provider service, while in practice it seems to rely mainly on Mozilla's servers currently So we'd be putting all our eggs into Mozilla's basket, and we'd be screwed if they got hacked. There are also websites that do not use email addresses as identity, HN for instance.

chubot 9y ago

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.

inglor 9y ago
I think that's why the web is so successful. No one likes the DOM APIs but they provide important capabilities and people just wrap them anyway. The fact you can take the capabilities and evolve the APIs continuously is the big pro here and it's a lot easier to do on the web than on other platforms. The "binary protocol stuff" is a great example of something the web _shouldn't_ do because it can be solved in a library (and already is) and doesn't add a capability. WebAssembly on the other hand is great since it adds a capability. At this point where Chromium has more LoC than the linux kernel I think "boiling the ocean" is a very good analogy - and the only thing that got a little close were mobile apps.

deleted 9y ago

[deleted]

0xcde4c3db 9y ago

> 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

hossbeast 9y ago
tldr, a netstring is a string prefixed by it's length in ascii encoded decimal.

RndUsr 9y ago

>> WebAssembly is the only effort to add a new web language, and that language is C … No, it's not. As far as I know C++ and Rust already work. And GC support is coming, isn't it? >> The core of my personal NewWeb design would be the JVM. Should we expect 60 something MB "NewWeb" apps that would require tons of RAM? P.S.: The most important thing about Web is the distribution aspect. I don't have to pay Google, Shmoogle, Apple, ask their permission or whatever. Root DNS could be replaced by a decentralized solution but otherwise it's perfect. OP's posts make an impression that this is the aspect that is not of interest to him. No way I would ever start using Google Play, Ubuntu One or anything like that over Web.

dasil003 9y ago

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.

datashovel 9y ago

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?

yorwba 9y ago
Can you explain how your meta-browser should differ from an ordinary operating system? I.e. additional functionality it would have when not compared to a browser, but to the substrate browsers currently run on.
- datashovel 9y ago
  In a nutshell. It would only be a simple shell, with extremely minimal API (for user settings, etc), which could sandbox browser engines. This (a) makes "switching between browsers" a seamless experience to the end user, (b) makes the development experience much more friendly to the developer [since they're developing for their browser engine of choice].

shalabhc 9y ago

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.

X86BSD 9y ago

I'm honestly waiting for the return of Gopher. I'm not kidding.

tannhaeuser 9y ago

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

201709User 9y ago
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.

SwellJoe 9y ago

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.

Udik 9y ago

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

jv22222 9y ago

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.

mirimir 9y ago
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-youre-a-dog http://knowyourmeme.com/memes/on-the-internet-nobody-knows-y...
whataretensors 9y ago
Yes, I'm hoping something like IPFS is in our future. Another killer feature would be the ability to never lose website versions or content(like git). Also I hope we can finally do mesh networking(with IOT?) and remove reliance on ISPs.

creatrixcordis 9y ago

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.

rhabarba 9y ago

Why not just improve Gopher?

pmontra 9y ago

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

mixedbit 9y ago

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/distributed_systems/a-note-on-distributed-computing.pdf https://github.com/papers-we-love/papers-we-love/blob/master...

pjmlp 9y ago
There were tons of Delphi and Visual Basic projects written with DCOM and MTS in mind. Also both had a plethora of components for network programming. Finally many of those applications were a typical three tier architecture not much different than SPAs, but with a much higher developer happiness.
kelnos 9y ago
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.)

z3t4 9y ago

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.

sjy 9y ago
>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.
- z3t4 9y ago
  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.
marcosdumay 9y ago
The web is a publishing medium. It sucks a lot as a sharing medium. If your audience is any less than the entire mankind, sharing your data by the web requires an unending number of hacks and another medium where you can communicate how to jump through them.

mattacular 9y ago

My prediction: Nothing is going to succeed the web.

aaronhoffman 9y ago

Probably something like Johnny Mnemonic

jmull 9y ago

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.

dangoor 9y ago

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.

MarkMc 9y ago
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.

pascalxus 9y ago

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.

type0 9y ago

https://news.ycombinator.com/item?id=15351141 https://news.ycombinator.com/item?id=15351141 This?

jbergens 9y ago

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.