15 ms·

It’s time to kill the web app

• dispo001 9y ago
  So much truth you get sick of hearing the truth.
• snakeanus 9y ago
  Quite a bit ironic that you need js to actually see the images in that article.
  • ovao 9y ago
    The links are also indistinguishable from text, at least on iOS.
  • jwilk 9y ago
    I can see the images without JS enabled.
    • snakeanus 9y ago
      What browser are you using and how did you disable the js? With firefox esr and with either ublock origin (dynamic mode) or umatrix to disable the js I am unable to see the images.
      • jwilk 9y ago
        Firefox + NoScript
• daenney 9y ago
  This isn't really about killing "the web" though, it's about changing web development as we do it today. At least, when I read that title I assumed it was about the web as a whole, not just web apps and the way we develop them.
  • dang 9y ago
    OK, we added 'app' above. That seems in the spirit of the article, which seems fine with the web as a document platform.
• fictionfuture 9y ago
  This article is so naive. It completely negates all the benefits of the open web while presenting problems along with non-sensical "fixes"...
  • chime 9y ago
    I apologize in advance for a political analogy but this sounds like "Obamacare is bad so we must repeal and replace it. I'll show you the replacement later." I've been a webdev for two decades now and while the author highlights the problems correctly, almost all of them have known fixes and there are 'best practices' to avoid them. Humans are not done with engineering and technology. We're still coming up with better ways to do things. Building for the browser is one of the best things we've done as a civilization. I can build something, send a link to my dad, and he can look it up on his phone with literally a single touch. How is that not amazing? It blows my mind every time I stop to think about it. It sounds ridiculous to say that since buildings fall every now and then, it's time to kill dwellings or since cars crash frequently, it's time to kill transportation. So without seeing the author's replacement, I am not yet ready to throw away the browser and JS-ecosystem just yet. It's terrible that Authy's 2-factor was bypassed with one simple trick but that doesn't mean HTML/CSS/JS need to die. You could have the same exact issues with mobile apps, installed software, or even hardware devices.
    • goatlover 9y ago
      > It sounds ridiculous to say that since buildings fall every now and then, it's time to kill dwellings or since cars crash frequently, it's time to kill transportation. It's more like, since cars crash frequently, time to replace human drivers with machines. I take his argument as replacing the web as an application platform with something designed from the ground up for applications.
  • generalpf 9y ago
    I mean, he worked at Google for 8 years, so he probably picked up some of their attitude. cough AMP cough
  • imtringued 9y ago
• agumonkey 9y ago
  Even though it's a bit forced, I agree that the whole mainstream computer field as a weird non ROI. Machines 10000x faster, personal value/productivity: flat or below.
  • closeparen 9y ago
    Web properties have invested growing processing power to the immense benefit of their customers, advertisers. Of course users have not reaped productivity gains from something we don't pay for.
  • Alex3917 9y ago
    > personal value/productivity: flat or below Except for that there are a thousand times more computer users than there were 30 years ago, now that we have the computer power to render talking paperclips or whatever to make computers usable by the average person.
  • SwellJoe 9y ago
    How do you measure that, though? It seems like you have to ignore all value derived from networks in order to come to the conclusion that software is no more powerful than in the 90s. In the 90s I couldn't have met with my team, with members in Moscow, California, Pennsylvania, and Texas, in any reasonable way...today I can chat, including video and sound, on a whim! Managing source code today is massively more productive than in the 90s. CVS (or, heavens forbid, RCS) on a central server was how it was done back then, if you had revision control, at all. It's not merely a better revision control system (git), it's the web-based infrastructure around it (github/gitlab/web-based CI/whatever). That wouldn't be possible on any platform that's less connected and less widely available than the web. The rise of package managers is another massive productivity booster that maybe goes unheeded (we all love them, but I think their productivity value is wildly underestimated...how else can you add 100,000 lines of code, that probably works, in a couple of minutes, and reliably allow every member of your team to do the same?). Web technologies have enabled that. There's a reason npm has the largest package selection the world has ever seen, and I think it's the massive interconnectivity of the web platform. (This feels sort of vaguely defined, I guess...but, there is a magic to the web platform.) There's so many areas where we're more productive today because of the network effects of the web as a platform. Also, because the web is universal, I don't have to use Windows, ever. Everything I ever want to do has a Linux version. Anything that falls short of complete platform independence is probably a step backward, IMHO, even if it has other benefits like smaller/faster binary builds. Also...WebAssembly is coming. We're going to see a fast/efficient web, long before a new platform could possibly be delivered.
• notatoad 9y ago
  >In part 2 I’ll propose a new app platform that is buildable by a small group in a reasonable amount of time, and which (IMHO) should be much better than what we have today... Next time: how we can do that. i look forward to that article. This one, on the other hand, seems a little pointless. Does the web have problems? yes, absolutely. But I have a hard time believing the best way to solve them it to tear down everything we've built so far and start over.
  • KGIII 9y ago
    I agree. People seem to think that there was a time when the internet was better than it is today. Well, I've been 'online' since before the web was world wide. Frankly, it was never good. In fact, it is better now than it has ever been. It's just people choose to use the worst parts of it. I've seen the various tech that was supposed to rebuild and revolutionize the web. It's just created more kludge. It's just lipstick on a pig. It's just one more set of standards that get half-ass implementations and even worse support. If you tear it down and rebuild it, it's just going to end up the same except it is using different names for the protocols. I'm not angry when stuff breaks. I'm amazed it works at all. And, truthfully, I kinda like it the way it is. We have, at our fingertips, vast amounts of information and entertainment. It works, after a fashion and for some definition of 'works.' If the Internet sucks for them, maybe they should look elsewhere? The Internet is huge. It's not hard to find parts that don't suck. Tearing down and rebuilding isn't going to work and nobody is going to invest in that. Hell, we can't even get ubiquitous IPv6 adoption. Not one browser is fully compliant with HTML5. And it's okay. It works, mostly.
    • resu_nimda 9y ago
      Everyone has a different definition of what's good and what's bad about the web. A lot of smart programmers seem to think almost all software is bad. Probably all software that is actually used is not as good "as it could be." Any evolutionary process is going to be like that. HTTP and HTML were absolutely not designed for many of the things they are used for today. A bunch of really smart people probably could come up with a much better solution for modern usage, and lots of them have tried. But the web has too much inertia (the users are there and don't care about these problems) and, as you say, it more or less works, or can be made to work. It does seem inevitable that it will be superseded eventually, but how far off is that?
• randcraw 9y ago
  Until I can block ads in web apps, I'll keep my browser thanks.
  • diminish 9y ago
    And you can't block ads in youtube, instagram or fb apps.
• SwellJoe 9y ago
  I find this unconvincing. Every negative thing said about the web is true of every other platform, so far. It just seems to ignore how bad software has always been (on average). "Web development is slowly reinventing the 1990's." The 90s were slowly reinventing UNIX and stuff invented at Bell Labs. "Web apps are impossible to secure." Programs in the 90s were written in C and C++. C is impossible to secure. C++ is impossible to secure. "Buffers that don’t specify their length" Is this really a common problem in web apps? Most web apps are built in languages that don't have buffer overrun problems. There are many classes of security bug to be found in web apps, some unique to web apps...I just don't think this is one of them. This was a common problem in those C/C++ programs from the 90s the author is seemingly pretty fond of. Not so much web apps built in PHP/JavaScript/Python/Ruby/Perl/whatever.
  • disordinary 9y ago
    Yep, also on speed: it seems to me that the microsoft office suite for instance slows down every generation despite only having minor improvements and not actually being that different now than from 95. The nature of developers is that they will use whatever resources that they have. Faster computers don't necessarily mean faster applications but faster software development cycles from bigger teams with less need for the discipline and rigor that was required before. In some ways we've traded speed for productivity.
    • ZenoArrow 9y ago
      > "the microsoft office suite for instance slows down every generation despite only having minor improvements and not actually being that different now than from 95" I can't comment on most of the Office suite, but Excel evolved quite a bit since 95. Tables, PowerBI, Apps for Office, etc... If your needs are basic enough then even VisiCalc will do the job, but new features do make an impact for more demanding users.
      • disordinary 9y ago
        That's not the point though. The example given in the article was Google Docs which has the same UI paradigm to Word. Under the hood it's massively different obviously with real time collaboration and constantly up to date syncing. So, the reasoning is that UI is fundamentally the same (or worse if not done right) to native UI from the 90's, yet it hasn't had a massive speed increase which seems wasteful. But modern UI in Office is only an evolution of what was there in the 90s and hasn't changed fundamentally either yet it doesn't feel any faster. UI is only a small part of an app, a well designed app will have most of the work performed outside of the UI thread and it shouldn't feel any slower than a native implementation. My thoughts are rendering speed isn't the issue but application design.
• bitwize 9y ago
  All the more reason to switch to Urbit. Have you accepted Curtis Yarvin into your heart as your personal BDFL yet?
  • mixedCase 9y ago
    As soon as it does something useful, sure. As a power user I could not be any less interested in whatever I've been able to understand Urbit does.
    • bitwize 9y ago
      Sorry, forgot the '/s'. :)
• mwcampbell 9y ago
  What about the fact that the Web platform isn't owned by any one company, but is supported (to varying degrees) by every major native platform? A shiny new app platform won't have that. That's important.
  • zdkl 9y ago
    In theory indeed. In practice there's 3 vendors and the standard defining organisation represents commercial interests in the platform, not you.
    • mwcampbell 9y ago
      On balance, and having read the whole article now, I think you're right. I shouldn't have reacted before reading the whole thing and really considering it.
    • aidenn0 9y ago
      3 vendors is still better than one.
      • zdkl 9y ago
        Name one other platform/deploy target that is as centralised on the vendor side, even though everyone calls it "open"
        • aidenn0 9y ago
          OpenGL
• disordinary 9y ago
  When you've got things like new multi threaded renderers, all browsers now 64bit, web assembly, service workers, faster processors etc. It seems that in actuality app development with web technologies is finally practical. But, why are these things framed as an either or? Surely the best thing is always to use the best technology for the job and in many cases the speed and security trade off is worth it in order to utilise existing assets and expertise from a businesses web application.
• avaer 9y ago
  I sympathize with the sentiment, but the web app only sucks if you're using the stuff that sucks. Like any technology with decades of evolution it has a thick sediment of peat. Half of Javascript, half of Windows, even half of *nix is garbage you should never use, but it's all there because old things would stop working without it. It's just that the web has a very low barrier to entry and very high reach, so the compost doesn't get thrown out as quickly as it should. So people still pack jQuery when they need to select elements, or pull a left pad from npm without realizing it's in the language core. Or pack Reactiflux when they want to do a form. In an age where you can literally compile existing, GPU-heavy C++ code to WebAssembly and run it in the browser with no fuss, you can't complain the web doesn't let you do things right, or at least the way you want. It's just admittedly easy to hop on the wrong library bandwagon and complain when things go wrong. But it's not a problem with the web.
  • vvanders 9y ago
    Having written things targeting WASM, when you can provide me an environment like Visual Studio that has breakpoints(including data) and a debugging I can step then we can talk. Until then WASM is cool, but not nearly as productive for C++ as the native platforms.
    • smitherfield 9y ago
      We could've had that years ago if Mozilla had not (as all the browser vendors do depressingly often[1]) decided to torpedo NaCl for nonsensical reasons that boil down to "NIH," in favor of creating a far-inferior, crippled spec practically designed to be aimlessly bikeshedded for years. [1] Mozilla usually pulls such NIH moves to sabotage the introduction or use of languages (even DSLs) other than JS on the web. See also: WebSQL, Dart, HTML5 vs plugins, HTML5 vs XHTML2. Whether you agreed with their position on those disputes or not, you have to admit there's a pattern. Again, not picking on Mozilla, everyone's an offender: Microsoft generally slows things down so their browsers don't get too outdated, Apple pursues vendettas against competitors and is myopically focused on moving mobile forward while neglecting desktop, Google's constantly attempting to muscle through user/privacy-hostile misfeatures and highly-specialized features that improve their own web apps more than the web as a whole.
• mikebenfield 9y ago
  It's probably not realistic, but I would love to see the web be completely thrown out and replaced with something reasonable. I write a decent amount of native code. I write Rust, C, and x64 assembly. I think I'm pretty good at this stuff. But the web is too much for me. Any time I think I'd like to do something with the web and sit down to learn, it's completely overwhelming. I've never been able to put together a coherent mental model of the architecture of a web application or figure out what the best practices are for web development. The amount of complexity you have to wade through to get anything done is just silly. There's the idea floating around that web developers are less competent than programmers on other platforms. I'm only half serious when I say this, but I sometimes wonder if, to the extent that this is true, it's because web developers have so much incidental complexity to deal with that there's just not much brainspace left over for classical CS or software development concepts.
  • bitexploder 9y ago
    That's cause the web is full of hype. Try Python Flask. A three line Python function and you are going. No magic. Just request and response. It is easy. Bang out a model class and read the SQLAlchemy tutorial. The web and RDBMS with just enough magic. Screw HTML front ends. Write the ugliest HTML you want. Never spend time in HTML. Make your app / idea work. Get your data right. Front ends and modern front end tech stacks are an unholy time suck that offer little for hobby or small apps.
    • untog 9y ago
      > Write the ugliest HTML you want. Never spend time in HTML. Make your app / idea work. Huh? That HTML is what your users will spend 90% of their time interacting with. They won't care one bit what RDBMS you're using. Front end development is deeply frustrating but it's also incredibly important.
      • Typhon 9y ago
        Yeah but users don't read the HTML, the browser does, and it doesn't care that you're using ten <br> tags for vertical spacing instead of an elegant CSS styling property. Edit : just want to make it clear that I'm trying to paraphrase here, I don't know if I agree (although I do want to point out that HN is built in this philosophy)
• leeoniya 9y ago
  the biggest security blunder of the web platform is allowing third party domains to inject code into https pages, which completely violates the trust that https is meant to establish. and it's here to stay, folks! because the entire trillion-dollar ad industry is built upon it, vacuuming up data about users across the internet. a huge amount of security and privacy issues would vanish overnight simply by requiring same origin. the fact that my banking backend has third-party metrics scripts injected [without uMatrix/uBlock Origin] is unforgivable. and of course half the web is broken without allowing 2 or 3 CDNs or cloudflare to track me everywhere i go.
  • untog 9y ago
    I agree and disagree. From the perspective of anyone making a web site it's very easy to secure yourself against JS running on a third party domain: don't load any. That sites do load these scripts says a lot more about their priorities and the state of online advertising than it does about browsers themselves.
    • leeoniya 9y ago
      i dont expect site authors to give 2 shits about security when the alternative is ad revenue. that's assuming they even understand the security/privacy implications of spending 5 seconds to add that one-liner social sharing widget. 75% of web devs wont bother to consider it and the other 24% wont care. it's the job of browser vendors to provide saftey for the masses. of course the giant conflic of interest here is that most browser vendors get a cut of the ad revenue. there's a massive need for a payment platform that allows for browsing ad-free but still paying directly for content as-you-go. i think Brave is trying to do this. cryptocurrency may provide the privacy protections for this type of arrangement.
      • jodrellblank 9y ago
        "We show how third-party web trackers can deanonymize users of cryptocurrencies. We present two distinct but complementary attacks." - "When the cookie meets the blockchain: Privacy risks of web payments via cryptocurrencies", https://arxiv.org/abs/1708.04748 https://arxiv.org/abs/1708.04748
• csours 9y ago
  Magic Sorcerer Hat Mode: Part 2 is going to detail something like Plan 9, where you don't have to worry about where the disk is, or the information feed comes from; where authorization and authentication are baked into services - not tacked on later; where UI forms are composable, etc etc. My surmise is that all of these things can be accomplished now with careful choices of how you do things. And if you aren't Microsoft or Google, maybe you don't need to make Word or Excel on the web?
• modeless 9y ago
  There's one big problem with killing the web: Apple's App Store. You can make all the new platforms you want, but they will never be allowed to replace the App Store for distribution. The web is the only platform that can do distribution outside of the App Store on iOS and Apple will never allow a second one. That means your platform can't have hyperlinks between apps, can't have a no-install experience, can't do just-in-time code delivery. Without those features you can't replace the web.
  • pjmlp 9y ago
    > hyperlinks between apps Sure you can. iOS - https://developer.apple.com/library/content/documentation/General/Conceptual/AppSearch/UniversalLinks.html https://developer.apple.com/library/content/documentation/Ge... Android - https://developer.android.com/training/app-links/deep-linking.html https://developer.android.com/training/app-links/deep-linkin... UWP - https://docs.microsoft.com/en-us/windows/uwp/launch-resume/web-to-app-linking https://docs.microsoft.com/en-us/windows/uwp/launch-resume/w...
    • generalpf 9y ago
      One problem I've had when developing for iOS is that universal links don't "trigger" after a redirect, which is very relevant for sending emails though something like MailChimp with click-tracking.
      • alanh 9y ago
        The irony of complaining that native, here portrayed as an alternative to a hopelessly multi-party web platform, won’t let you interject arbitrary parties between a link and its destination…
        • adtac 9y ago
          Basically a case of "I want it to behave exactly like the web, but don't call it that."
    • 9y ago
• auchenberg 9y ago
  Said the author who wrote the post inside a rich text edition app, a web app, which happen to be this thing called Medium. Oh the irony!
  • dmitriid 9y ago
    Please read Medium's own posts on how they implemented this capability and the pain they went through implementing it.
• bikamonki 9y ago
  Kill the browser as an app platform and go back to installation/dll hell? No thanks :)
  • cellularmitosis 9y ago
    Statically-linked binaries would get around that. Not as space-efficient, but modern computers can afford to waste some storage. This is basically already happening with Electron apps.
• partycoder 9y ago
  I disagree. - Web apps remove the need for installing an application. This alone has multiple positive implications, such as lowering the entry barrier for usage. - Most of the time you can use them from any operating system. - Security-wise, locally installed apps are not more secure. A locally running app if anything gives a larger attack surface to the end user. - The level of security major browsers have is not within an average business budget. Finally, the most important point: Security is a 2 way street. Just like you can attack software installed in your computer, the software itself can as well be malicious and attack you. Web browsers provide guarantees on what a web application can do and what they cannot. Without these guarantees, it would be much harder to trust an application. Mobile operating systems try to solve this problem with permissions, and it has been rather effective, but not all people pay attention to them. With desktop apps you are largely on your own.
• alexjray 9y ago
  Seriously? the web app is the most ubiquitous and flexible app on the planet; adapt or die.
  • SquareWheel 9y ago
    No kidding. I'm at the point of almost exclusively developing webapps. Universal, instant, and powerful. It's the perfect platform.
    • goatlover 9y ago
      It's really not. HTML and CSS are far from ideal for making applications. JS has gotten better, but it still lacking in some ways. And there is no IDE for the web, whereas Smalltalk had one in the 70s, and numerous ones have existed for other platforms since then.
      • artursapek 9y ago
        You have to wonder why it is, then, that the web has gotten so big and all of those other "platforms" are marked with tombstones.
        • goatlover 9y ago
          Obviously for other reasons, like the fact that everyone has a browser for free on their device, and everyone knows how to use Google. There are very strong network effects in favor of the web. It is a great platform in some ways. But it's not ideal for creating applications.
      • kowdermeister 9y ago
        Try VSCode it's one of the best IDE, it has code completion, built in documentation and even code autocomplete for JavaScript. https://imgur.com/a/26oFa https://imgur.com/a/26oFa
        • goatlover 9y ago
• flavio81 9y ago
  Excellent article. It's time to scream aloud that the emperor has no clothes. This farce has gone too far: Most of the facilites for implementing a web app started as a quick and dirty hack, creating abuse of HTTP Forms, DOM manipulation, etc. Aided by Javascript, itself a hack (the creator was under heavy time pressure to deliver a language.) We've built a whole empire using these flawed pieces. I'm bookmarking this article.
  • mmcnl 9y ago
    What is your definition of flawed, then? It is the most widely used distribution network of applications. Personally, I would argue the exact opposite. The web in its current state is a brilliant piece of technology that is vastly undervalued.
• jtchang 9y ago
  > First, use an XSRF token as discussed earlier to make sure that JSON results containing confidential data are only returned to your own pages. Is this necessary for GET requests that return JSON? You need to include a XSRF token in the request headers?
  • codedokode 9y ago
    Ideally browsers should block cross-domain requests by default (so no XSRF is possible), but sadly this would break compatibility with older sites. Maybe we should make new HTTP methods (like SAFEPOST) with builtin XSRF protection and switch new apps to them?
• diminish 9y ago
  >> We desperately need a way of conveniently distributing sandboxed, secure, auto-updating apps to desktops and laptops. What's the proposal? * App stores controlled by juggernaut companies, doing the app-screening? * Signing web apps bu an authority? * Writing in "safe" languages in java/rust/..? * Java applets? * Adobe Flash? Silverlight? * Uglified, minimized encrypted JS code? * or Win95 style self-extracting installers for downloaded apps, installed by users with no package management? * Debian style package managers?
  • codedokode 9y ago
    Screening apps by a large company is not bad. Users don't want to guess whether the app contains malware or not. They would prefer someone do it for them.
  • krapp 9y ago
    Webassembly? Probably Webassembly.
• JoshMnem 9y ago
  The article doesn't make sense without an alternative. What open standard is being proposed to replace the open WWW? Mobile apps and app stores are not a replacement for the open Web, and it can't reasonably be argued that locked-down mobile devices loaded with craplets and no root access are better than the WWW.
  • Kwastie 9y ago
    I agree, this article doesn't make any sense without proposing an alternative. Sure, I think most people would agree that the web is still a bit rough for (large) apps. (compared to desktop apps) But nothing that can't be fixed, right? I can't imaging that native phone apps will still be popular in 10 years. I think that they will be replaced by the web in a similar fashion as web-apps have replaced desktop apps.
    • goatlover 9y ago
      There are still popular desktop apps. Native Office is still used widely despite Google Docs and web versions of Office. Adobe applications are still widely used. Most programmers use desktop editors and IDEs. I use a lot of the Mac applications.
• a1371 9y ago
  > It’s time to kill the web ... I’m going to review the deep, unfixable problems the web platform has: I want to convince you that nuking it from orbit is the only way to go gee, those statements are bold. Not only JS or even the front-end stack, the author wants to kill the whole web and make a new one. I can say it is not a first time I've seen an engineer seeing something imperfect and suggesting that everybody should immediately abandon it to make something better from the scratch. Like many of you, I am looking forward to see the second part for a web alternative. What I am interested in is how the author wants to make his proposal as beginner-friendly as the web already is.
• codedokode 9y ago
  Flux is not equivalent to Windows Events. The analogy is DOM Events. Also, Flux is not required for building web apps. After this I thought that it makes no sense to read the article further. For me the problem with web apps is low performance, slow load time. Another problem is people who try to push programming patterns from functional languages (like immutable values) into mainstream JS libraries. Please use Haskell instead if you love immutable values that much.
  • addicted 9y ago
    Despite the slow web performance I find web apps open much faster than their iOS app equivalent. This is despite the fact that iOS apps have 100-200MB downloaded in advance while the web loads your binaries and assets on the fly.
    • codedokode 9y ago
      Maybe those iOS apps have a browser inside?
• bobsil1 9y ago
  We are using a stateless document model for apps. You can select text on buttons. Madness.
• quonn 9y ago
  Fun fact: The colorful Windows 98 explorer sidebar that is shown in the first screenshot was implemented as HTML (and Javascript), along with the desktop background (called active desktop).
  • fredsted 9y ago
    Actually the folders themselves were too. You could edit the actual CSS and HTML behind them – changing the colors, putting in backgrounds – by placing specially named files in the directory. Windows 98 was a glorious thing.
    • bandrami 9y ago
      Yup. I once got paid an absurd amount of money to "customize Windows 98" meaning, write a couple of lines of HTML and Javascript.
  • alanh 9y ago
    Indeed. I once built an “Active Desktop” web app — if you will — for my mom as a holiday gift. It just rotated through some pics of the family as wallpaper.
  • davesque 9y ago
    I remember when the services supporting that UI would crash and you'd just get a generic, blank webpage with one link as a desktop. Those were fun times. And boy...Outlook back then would do some wacky stuff. I seem to recall you could trick it into executing javascript in a system context which was hidden in png attachments or something to that effect.
• marenkay 9y ago
  ... I feel like I've read the same about terminal apps, tons of programming languages, etc. and it's again missing the point. Nothing is reinventing anything. The code you write these days in Go, JavaScript whatever is still following the same principles as in the 1980s. All we do is swap out tools and languages, add comfort.
• untog 9y ago
  It's probably not possible to evaluate this post without waiting for part two, where the author says they'll outline their plan for The One True Platform, because after reading part one I come away saying "yeah, so what?". I don't think many people working on the web platform evangelise it as the most amazing software development platform that's ever existed. But they do recognise the reasons why it has proven to be as popular as it is, and what can be done to improve it. That's why we've got WebAssembly for native code, Service Workers for offline capabilities, WebGL for performant graphics, so on and so forth. Yeah, it's scrappy, but it has much more chance of being successful than some start-from-scratch idealised standard (that will have no security vulnerabilities, naturally) that someone just brewed up. But hey! Maybe I'm wrong. Maybe part two will blow the web dev world away. But I'm not holding my breath.
• hexmiles 9y ago
  While i understand the article and agree with it, i love programming webapps. The combination of html/CSS is much easier (for me at least) to work with than most other rendering framework, also JavaScript while not perfect is very good for fast moving target, and with "extension" like typescript you can even manage very large application in a progressive way (you can mix js and typescript). I also work with the android layout system and a bit of the iOs one, and they are a lot more confusing, (Constraint-layout fixed a couple of problem on android recently). Currently i work manly with legacy asp.net app at work, and shiny all-js webapps at home, but i done a lot of work also with winform and android apps Also the ability to update the app "on the fly" and be able to download only the part of the application that you need is pretty cool. Your can make your user always use the last version and quickly deploy hotfix. I understand that this are not propriety desirable for every type of application but sometimes are game-changer. What i really want to have is a lighter implementation, i think that Facebook did something similar with is Facebook lite app. Here's a gist with what i really want for a layout/app runtime. * Using a Url style system for retrieving resource. * A binary protocol similar to protobuf,capnproto etc.. for talking with the server. * A clear separation between the template and the data, so that i can cache the entire page and only request the data for populating it. * A Module and a Permission system, with versioning (for backward and forward compatibly),maybe integrated. * One way to store data (i personaly like key-value system, but i think a document system would be more suitable). * A Unified syntax for html and css. * a Component system(this is a big one), ideally the spec should only define a div-style generic container that can be specialised in a new component by adding to it, a name, style and optionally a script witch control is behaviour, (I'm not a fan of the web-component spec as it is). What would you want from an alternative layout/runtime system for web-like app? I'm really curious! PS: I really hope there will be more engineering post about the Facebook lite app, it seem a concept really cool that could be used for a lot of other apps! edit: adjusting formatting
  • dmitriid 9y ago
    > The combination of html/CSS is much easier (for me at least) to work with than most other rendering framewor Html+css is not a rendering framework. Also, come back with your "much easier" when you need to do anything even remotely resembling iOS's screen transitions, animations, and capabilities for constrained layout. Even properly implementing the seemingly simple toolbar in Google Docs is an excercise in endless frustration.
• hyperpape 9y ago
  I don't get the section on JSON, which seems to assert that XML is more secure than JSON. It does this by linking to a Wikipedia page that includes the security consideration that you shouldn't call eval on JSON. True, but at least that's a tractable problem. Your linter can check for code that calls eval. In contrast, there are plenty of XML attacks (DOS with billions of laughs, entity references), and parsing XML is a lot more complicated, which matters a great deal if you're using non-memory-safe libraries for parsing. Also, because XML is so general purpose, you get things like libraries allowing deserialization of arbitrary objects from XML, which is a security nightmare. That last point isn't a clean win because sometimes the same library will handle JSON and XML, and so you have to audit the use carefully. However, if you're sure that your serialization libraries only use JSON, its simplicity means that it shouldn't have that kind of deserialization vulnerability. P.S. If you want to rag on JSON, that's fine. It's not a great format. But "it's less secure than XML" is not the tack I'd take.
  • hutzlibu 9y ago
    "If you want to rag on JSON, that's fine. It's not a great format" JSON is simple and powerfull. It's success justifies it, to call it a great format, I think. But I am curious, what whould be a great format, in your opinion?
    • jaltekruse 9y ago
      A standard way to at least represent common data types, dates/times, integers/longs and fixed precision decimal would be nice. I know that the JSON format doesn't specify any limit or precision limitations on the size of numeric values, but almost all libraries assume they should be read as doubles. It is a real pain for people doing analysis on semi-structured JSON after apps have been deployed for a while and the data model has evolved over time.
    • hyperpape 9y ago
      JSON gets the most important thing right: it's simpler than XML. I probably should have rephrased my comment. I literally mean that it's a decent format, but not a great one. One issue is that it's surprisingly poorly specified: http://seriot.ch/parsing_json.php http://seriot.ch/parsing_json.php. As a data-interchange format, it lacks first class dates/timestamps, the issues about specification are a pain when dealing with numbers (depending on language, you may not be able to use the full range of 64 bit ints), and has no builtin concept of schemas. That said, I'm not sure what I'd recommend above JSON, though you clearly wouldn't use it for really high performance servers. It's also used as a configuration language, where more issues surface. It doesn't accept trailing commas or comments (I can see the argument for requiring all keys to be quoted, but that's a pain to write as well). For configuration, I think I prefer TOML to JSON. Dhall looks cool, but I've never used it.
• aidenn0 9y ago
  My understanding of HEIST is that it is completely defeated by disabling compression on dynamic content. That doesn't seem to be "the end of the web" to me...
• jimbobimbo 9y ago
  The reason the web platform is "ugly" is because nobody owns it. Multiple players need to get on the same page in order for things to happen. The end result is not pretty (different browser versions behave differently, incomplete specs, etc.), but one thing is constant - nobody owns the platform. This is important because of things like this [1]. You may dislike some apps' mission, or approach to moderating content, but you cannot outright ban it from your platform, if you don't own the platform. [1] https://arstechnica.com/tech-policy/2017/08/gab-the-right-wing-twitter-rival-just-got-its-app-banned-by-google/ https://arstechnica.com/tech-policy/2017/08/gab-the-right-wi...
• nadiad 9y ago
  This article sounds like it's written by far from a mad lunatic programmer. Look kid no one said desktop apps are secure too, what's your point? Google and many other decent companies are developing webapps years now without any single leak. Of course desktop apps are way more secure but there is no good or bad here. It's like comparing two different things like "electric guitars are better than classical guitars". Stop acting like a 10 years old kid and grow some balls.
• fiatjaf 9y ago
  > "Flux, the latest hot web framework from Facebook." This guy is clearly not a web developer.
• fiatjaf 9y ago
  > All this adds up. I feel a lot more productive when I’m writing desktop apps (even including the various “taxes” you are expected to pay, like making icons for your file types). That made me remember something: compatibility. I like web apps because they will run on my Linux machine and on all other people's Windows machines. What is your solution to that, angry guy from the article? Also, please provide solutions to: * the dangers of installing other people's software to your computer -- dangers that practically inexist in web apps; * the friction of getting people to try out your apps.
• intrasight 9y ago
  I wish modern web apps were as good as and as consistent as Win 98 apps.
• pjc50 9y ago
  Firstly, rewrites never work and people won't abandon a working solution for a "better" one unless it has a killer feature. But the real thing is: the "web platform" is not the result of a design process, it's the result of a war. It's the stalemate point between so many competing technologies. It's the no-mans-land between warring monopolists. Any monopolist could have given us a "tidier" solution (although probably not secure either!) We could have had the ActiveX future, or even a global Minitel system. The web is uniquely in persisting without yet fully falling to any "winner takes all" effect.
• andrewstuart2 9y ago
  This reads like an article about web applications written by somebody who doesn't have any meaningful amount of experience writing web applications (which I've just seen he admits further down in the comments). The number of false statements and false assumptions in just the first section is enough to make it hard for me to continue reading, since it's supposedly the foundation for the rest of the suggestions. > Web apps can't use real sockets. Because security is an important consideration, and websockets are designed to live within the constraints of the same-origin policy, which helps immensely in creating apps that are secure by default. > Things as basic as UI components are a disaster zone. [Links to article about web components] Web components are a failed/failing/doomed (IMO) proposed standard and are nothing but an implementation of the idea of UI components. The design of web components is about building component object hierarchies, and is doomed to fail (IMO) in a markup language built around content composition. Saying UI components are a disaster because (one guy says, though I agree) web components are a disaster is like saying "a square won't fit here, so obviously no rectangles will fit." > HTML5 has peer to peer video streaming No, it doesn't. Browsers support the completely-separate WebRTC specification and its related javascript APIs. No HTML spec says anything about WebRTC. My suggestion would be that if you want to replace something, you need to actually grok it first, or at least have a sufficient understanding of the complexities (and the reasons they exist) you're trying to argue against. Otherwise it's way too easy to point out that you don't really know what you're asking to replace, and your opinions, while potentially valid, are going to be tossed with the rest of the bath water.
  • dmitriid 9y ago
    > Web components are a failed/failing/doomed (IMO) proposed standard and have nothing to do with the common UI component frameworks that exist today. The design of web components is about building component object hierarchies, and is doomed to fail (IMO) in a markup language that excels at composition. 1. Exactly 2. Instead of building a set of native (to the platform) common UI elements w3c ended up ckreating an incomplete low-level API for something, no one knows what exactly. 3. Existing UI frameworks re-invent a huge amount of things, poorly and inconsistently.
• StevePerkins 9y ago
  > For the first time, a meaningful number of developers are openly questioning the web platform. Lost me in the opening paragraph. "For the first time"? Please, people have been openly questioning the web platform for a decade now. Ever since mobile (and their native apps) starting "killing off the desktop". Ever since people downloaded their first PhoneGap/Cordova app, and saw how badly it looks and behaves compared to native widgets. Ever since people pulled up a task manager, and noticed how much RAM and CPU that Electron-based app was using. On the other hand... we've been openly questioning native too, ever since basic social media apps starting weighing a hundred megs each. Every platform has its problems.
  • da02 9y ago
    Are there any alternatives to Phonegapp? Ever used Flutter or Kotlin?
    • smw 9y ago
      I'd probably look towards react native if I were trying to build a phonegap-type app.
  • davesque 9y ago
    They've been openly questioning the web platform since its inception.
• addicted 9y ago
  The 2arguments presented are: 1)Reinventing the 90s - Why is this necessarily a bad thing? The author links to a blog post discussing how Flux is similar to Windows 1.0 but that author of that post does not claim that makes Flux bad. In fact they agree it works well and scales well as well. The only thing they say is that based on the experience in the 90s it’s likely we will have further developments on this model. Why should those developments not be on the web platform itself (also who thinks that if we are gonna start a completely new platform we wouldn’t reinvent the 90s on it again?). 2. Impossible to secure - Yes security is a huge issue with the web. But a large part of that is older designs and many have been mitigated (as an example, the wiki section the author links to show why JSON is insecure has 2insecurities. Security issues in parser implementations which are not written in web technologies anyways and the fact that before 2009 and the widespread availability of JSON.parse and JSON.stringify people used eval to parse JSON). I’ll be honest that I do think the web needs to be improved/changes/replaced. I don’t think this article makes the point well and possibly focuses on the wrong things. But my biggest concern is with the idea that improvements need to be achieved by replacing the web instead of the kind of incremental improvement we are already seeing. I would be interested in Part 2 to see if the replacement the author has in mind is really worth it. It would need to at least be an order of magnitude better to sacrifice the compatibility advantages the web has, but it may still be worthwhile to think of what a platform written today from scratch would look like to focus the kind of improvements we would like to see on the web.
• ashitlerferad 9y ago
  click bait
• alanh 9y ago
  There is a section heading that reads, “Why the web must die.” I almost stopped reading there. I value the web for its longevity, accessibility, and non-proprietary nature. There are some goods points made in this article, however: > My experience has been that attempting to hire a web developer that has even heard of all [the above-mentioned security] landmines always ends in failure, let alone hiring one who can reliably avoid them. Hence my conclusion: if you can’t hire web devs that understand how to write secure web apps then writing secure web apps is impossible.
• jkelsey 9y ago
  I agree with the premise but the problem is developing apps in any other ecosystem decreases your overall audience. You're either in the corporate world with their walled gardens, or in the FLOSS world where there's all sort of rough edges and things don't work as smoothly (and I say that with nothing but respect and admiration for all the well-meaning hard work from folks that's gone into both ecosystems, but it's the stark reality of matter). The web is as close as we've gotten to making tech as user friendly and accessible. I bet Mr. Hearn has a bunch of technical proposals lined up for part 2, but how we cross all the factionalism, corporate or idealogical, that's formed in the software community at large since the birth of the web?
• tarikjn 9y ago
  Apart from some justified points on how confusing origins can be, the author fundamentally misunderstands Web development. Not only do users want fast sites and multiple of them open, so the performance point bears little weight, but the authors points to OOP techniques, presenting them as necessarily superior to FRP because they came later to Windows. Next the criticism on productivity and size of developer teams. Productivity has gone up tremendously in my experience e.g. by doing universal apps using React/Webpack/CSS Modules and following FRP principles, all of which you can do while maintaining Web semantics. If you haven't noticed gains in productivity, your workflow is wrong and you aren't taking advantage of the current tools. From my point of view, things used to be much worse and it is finally maturing. I won't bother commenting on the rest because the article just go down from there in confusion mixing up services with applications. The author just basically wants to write desktop apps, but also be able to take advantage of the Web's discoverability.
  • ZenoArrow 9y ago
    > "Next the criticism on productivity and size of developer teams." Were we reading the same article? The main criticisms made by the author of the article were about web app security. If there was a mention of productivity it was only made in passing. > "The author just basically wants to write desktop apps, but also be able to take advantage of the Web's discoverability." Is this a bad approach?
• dmitriid 9y ago
  One of my rants is linked in the article (Failed promise of Web Components). Here are two more rants on the insanity of the web and what we could probably do with it: - https://medium.com/@dmitriid/w3c-and-whatwg-should-die-a-quick-and-horrible-death-a7cff5e1da8f https://medium.com/@dmitriid/w3c-and-whatwg-should-die-a-qui... - https://medium.com/@dmitriid/ok-w3c-and-whatwg-dont-die-but-7952221fcbe4 https://medium.com/@dmitriid/ok-w3c-and-whatwg-dont-die-but-...
• deleted 9y ago
  [deleted]
• nostrademons 9y ago
  It's worth remembering that in the late 1990s, as Microsoft was facing its own security crisis and everybody hated the Wintel monopoly and how bloated Windows had become, several people put out calls for new systems to replace Windows. This was the era of Java applets, of Linux on the desktop, and of cross-platform widget libraries like Qt and WxWidgets. What we actually got instead was the Web. And the reason we got the web was because it was never conceived to be an application platform, and Microsoft crushed the only company who was calling it as such (Netscape) and declared victory, and then were caught completely unaware when new challengers like Google and Facebook sprung up and adopted the web for what it was and then totally ate Microsoft's lunch with it. By not looking like an OS, the web was able to differentiate itself in consumers' minds and not force comparisons to a much bigger, more mature platform until it was so entrenched it was impossible to make go away. If you want to build a replacement for the web today, your first priority should be to think of something that millions of people will use daily. It can (and should!) be really simple initially - the Web was first used for sharing scientific papers, and then for creating WebRings of band fanpages, and then for porn, and it took 20 years or so before full webapps became viable. But thinking about it from the perspective of how you make a secure, performant, maintainable programming environment for developers is exactly the wrong approach. History is littered with projects that do exactly that and fail to get anywhere.
  • davesque 9y ago
    I would add that anyone looking to replace the web should think about what problems the web doesn't solve. I think you could argue that this was what made the web itself successful. Mr. Berners-Lee saw that there was no system which had gained market acceptance that organized information in the way that people actually tend to organize it (which is not hierarchically). As you may have been alluding to, simply coming up with a more elegant, well-architected version of the web has no value to anyone outside of the engineering room.
• osrec 9y ago
  I wished the author had taken a more developmental view. Personally, I think the web as it currently is, has a few shortcomings, but on the whole I feel it can be refined into something quite brilliant. Also, with regards to the title "it's time to kill the web app", I feel the web app has only just started to emerge as a solid competitor to native. To kill it now would be a travesty! I believe that soon it will replace a large chunk of native apps and the innovation we will see in browser APIs in the next few years will be quite remarkable. I think the USP for the web is ubiquity and uniformity - having a single, uniform platform that runs on any machine while being unlimited in the variety and nature of things it's capable of. There are issues to be addressed (security being the obvious one), but still, to me web apps are a step in the right direction, not the wrong one!!
• k__ 9y ago
  The only reason I do React-Native apps instead oft web apps now is, the RN ones pay better. I'd love to keep doing web apps.
• amelius 9y ago
  The web is our best bet to converge to a single platform. I find it extremely intellectually unfulfilling to write my code for three platforms (web/Android/iOS) instead of just one. So until there is a better common denominator, the web is my first choice, because at least it is accessible from all three platforms, and from the desktop.
• davesque 9y ago
  The web became as popular as it did precisely because it sucks. A lot of the supporting technologies made design decisions that favored easy of use over stability and things that experienced developers like. Every argument I hear about how the web sucks basically boils down to an argument that it should be more consistent and well-designed. But most well-designed technologies fail because engineering doesn't win the day -- delivery does. I say all this even though I consider myself an engineer with a penchant for the craft of writing software. I love beautifully architected systems, but I have to sadly admit that they're often not relevant to the bottom line. I don't think it's time now or in the near future for the web to die. Just as we often still mindlessly adhere to the 80 character limit for terminal width, even though this limit has its origins in the size of punch cards, we'll still be using traditional web stack technologies decades from now.
• scottmf 9y ago
  I’m tired of seeing this same article on HN every week. I’ve begun to feel that a lot of HN is stuck in 2010, a lot of people refusing to adapt to a changing industry who want me to get off their lawn. I’m in desperate need of some links to alternatives. Perhaps something with the same vibe as this site had several years ago. Not to say there isn’t still a lot of good discussion on here. But at least when it comes to the web there’s far too much noise. It’s toxic.
• hoodoof 9y ago
  The return of Adobe Flex!
• Cozumel 9y ago
  >Hence my conclusion: if you can’t hire web devs that understand how to write secure web apps then writing secure web apps is impossible. That..that doesn't even make sense.
• Exuma 9y ago
  No, it's not "time". I hate stupid headlines so much.
• ivanhoe 9y ago
  People used to do that, in 90s CGI scripts were usually written in C, or even assembly. And let me tell you since I'm old enough to remember it: no, it wasn't a great experience at all. It was actually quite horrible for web developers from the today's perspective. Development was slow and painful and hard to debug as hell. Also, it wasn't secure at all, hacker usenet groups were all about stack overflows back in those days. One of my first jobs in late 90s was a complete rewrite of a huge web app into perl. It was originally written in pure C, and it had so many security and stability issues due to bad castings and stack overflows and null pointers and all that usual C stuff, that today it'd be considered completely unusable (back then corporate users were far more tolerant I guess). Perl rewrite fixed it all, no stack overflows, no worries about casting every input every freaking time, no sql injections (perl DBI used prepared statements), everything worked like a charm. And it took us only a fragment of the time it took for the original development. Programming cycle was like 10x faster since you didn't have to compile it first (just that was worth it), code was easier to read, we were much less likely to make stupid errors, etc. That's why everyone moved to perl and then php, python, ruby, etc. in the first place. They are simply better tools for the job, history has proven it already like 20 years ago.
  • 3chelon 9y ago
    And can anyone still read all that Perl? I used to speak Perl but I know I'd be far better able to understand some C I'd written 20 years ago than any of the Perl I did back then.
    • ivanhoe 9y ago
      To quote the Matrix: "You get used to it, though. Your brain does the translating. I don't even see the code. All I see is blonde, brunette, redhead."
• mmcnl 9y ago
  This article addresses web apps at the micro level. Comparing a React based webapp to a 20-year old UI, the end result. It fails to address distribution. How did that UI end op on your display? Through 13 floppy disks. How did the React based web app end up on your display? In the blink of an eye. Distribution is key. Real artists ship.
• a-dub 9y ago
  annoying clickbait title and irrelevant trolltastic comparison to '90s windows garbage designed to incite anger. 1) yes, large webapps are hard to secure. but they're also infinitely easier to patch. 2) yes, the fact that google just shits out random things so people can get promotions (SPDY, NaCL, whatever) and it becomes a thing is a problem. this was not how the decentralized web was designed... but that doesn't mean that it's "time to kill the web."
  • ksk 9y ago
    You seem to be conflating the web with webapps.
    • a-dub 9y ago
      nope.
      • ksk 9y ago
        > this was not how the decentralized web was designed... but that doesn't mean that it's "time to kill the web." Its not "time to kill the web", because that was never under consideration.
        • a-dub 9y ago
          click the link and read the giant 18 point text heading. thx.
          • ksk 9y ago
            Ah, I assumed you read the article. So sorry..
            • a-dub 9y ago
              i did. i started with the title.
• hexrcs 9y ago
  I agree that the web platform is kind of messed up, but web apps are just so accessible and convenient... For essential apps, I believe most people would always prefer native versions. They are more convenient that way. (I don't want my local media player to be a tab in Chrome.) People generally are not using Google Docs because they are robust or feature packed. They use them because they could just load it up in a few seconds on a new machine, with nothing to install and everything synced in the cloud. Actually, I think if there is a platform which allows users to run ANY apps with just one click, it has to be a platform just like the web we have right now. Sure, if JavaScript were not made in a hurry, we could have got a lot of efforts spared - but dialects and attempts to “reimagine” and "personalize" our weapons are still going to show up, maybe just like all those frameworks and workflows we have right now. (Seriously, why are there so many NATIVE UI libraries? So many OS's? So many NATIVE programming languages?) Yes, we ARE reinventing the wheels, but for a good reason - accessibility. All apps from every generation do similar things: typing docs, filling in spreadsheets, instant messaging, playing music... In fact, humans ALWAYS have done similar things - they wrote stuff and kept lists long before MS Office came along. The web is an upgrade, thanks to the better computing power we have to allow "inefficient" non-native rendering nowadays. The "native" apps we have now can do their fancy new 2017 stuff. Maybe soon we will have full blown AutoCAD as a web version. Many native apps we have today are almost awesome enough - the natural tendency would be to make them more accessible.
• sunseb 9y ago
  Yeah, I have been working on the web for 10 years. When I started, it was fun, because I knew nothing, and that seemed magical to me, but the more I work on this platform, the more I realize it's crap. We are now at peak crap. Did you see all this JavaScript bullshit code needed nowadays to just render a fucking web page and fetch some data? I hope OOP would die too, I mean, it's often an over-engineered bloat that only works for trivial Programming 101 courses (using Bike, Vehicle classes). In real world, I found OOP to make things messy with pseudo-objects like Service, Manager, (Abstract?!)Factory and so. Just using params and functions feels more natural I think. Sorry for the rant. I think we all do an unbelievable job pushing these tools to their limits, but it's just made me sad that we may building on ugly foundations.
• valuearb 9y ago
  I deleted Facebook from my iphone because i don’t want to give them that much access, and now only use their web app on my iphone. And it’s horrible. If Facebook can’t get it right, who can? My latest example is from 30 minutes ago, where I tried uploading s video; and almost gave up after 5 mins. The UI was hard to understand, extremely slow and never let me understand what was happening. Professionally I’m an iOS lead on a dual platform (iOS @ Android) app that has hundreds of thousands of users. I’ve occasionally wondered about whether we should switch to React Bative and using Web Facebook always cures me of that idea. And the fact that i’ve spent hundreds of hours optimizing our app and every view to ensure they launch and open as quickly as possible, down to managing every bit of memory use as ruthlessly as possible. And letting our users use our app offline. Every second costs us users and dollars. Then there are new technologies like ARKit. Native is still the best way to go if you can afford the time and people to do it the best way possible.
  • rocqua 9y ago
    Facebook has decent incentive to move people from their web app to their mobile app.
• Entangled 9y ago
  How about using an app:// protocol for compiled apps with security in mind, meaning sandboxed and no filesystem access? Http is for hyper TEXT, not hyper BYTES. Wasm is a great opportunity to reinvent web apps. Please don't fuck it up.
  • foolfoolz 9y ago
    how many things have been described so far as "sandboxed no file system access" yet the sandbox is breached?
• fckurpropaganda 9y ago
  Just make better webapps... There are too many second rate "developers" making shitty apps...
• ivancamilov 9y ago
  The author seems to think that most developers think the Web sucks and needs to be killed. While this may have a sliver of truth behind it —in that a lot of us are dissatisfied with certain aspects of the platform— there's one thing the author fails to address: If the Web (and Javascript) suck so badly, then what's up with all those Electron desktop apps? And all those react native/nativescript/ionic mobile apps? IMHO, the author fails to address the only reason the web is popular as an application platform: its still the only reliable way to make sure your code runs everywhere with as little effort as possible.
• microcolonel 9y ago
  > Hence my conclusion: if you can’t hire web devs that understand how to write secure web apps then writing secure web apps is impossible. Furthermore, the web devs that understand how hard it is to write secure web apps generally don't want to do it for a living. I've found that the most straightforward way of avoiding problems on the web is to sidestep them as much as possible. Draw UI with canvas or WebGL, overlay native widgets, use RPC over a WebSocket for everything except for public assets.
• tomchristie 9y ago
  > a meaningful number of developers are openly questioning the web platform. And then going back to building their products. On GitHub. Oh, wait.
• grahamburger 9y ago
  I wonder if there's a market for a WebApp store. Like a curated WebApp library - centralized billing, some form of vetting before apps can be listed, maybe even some apis for notifications or whatever. WebApps tested on a few major browsers and platforms before they're allowed to be listed. I'd probably be more willing to pay for WebApps if they were delivered that way.
  • albertgoeswoof 9y ago
    Most consumers don't know the difference between a web app and a native app, so no one would care
• marcrosoft 9y ago
  The web app is the best we have. Please give us an alternative or else it's not actually time to kill it.
• LarryMade2 9y ago
  Why web Apps? Because you can hit just about every platform with one codebase, you got instant distribution, you got near universal compatibility. And, If you are inclined, you have minimal licensing. Desktop has big compatibility cross/platform hurdles (does it run on Linux, MacOS, Windows, Android, iOS, and Playstation?), difficult distribution, and at times licensing (even moreso on walled-garden platforms). You are also dependent on the desktop/PC manufacturer (ever have Microsoft, Apple, Google, etc pull the rug from under your product? it happens regularly especially with OS updates and "trusted" platform initiatives) Not to mention the development platform whims ("Sorry guys, we are selling to MS. We're sure they'll keep those MacOS and Linux versions up to-date, they are really excited about it!") Maybe if its a open platform with high adoption on the scale of LibreOffice or GIMP... maybe.
• andrewflnr 9y ago
  I agree that the web is kind of a catastrophe. However, the problem is not really that it confused documents and apps. I would actually like to see this distinction get blurrier, in the form of better support for active documents, ranging from interactive illustrations of ideas to spreadsheets with formulas.
• mrcabada 9y ago
  Long live web apps. It’s not that they need to be killed, it’s that they are evolving and need/urge to evolve more. With so many OS, HTML works perfectly to distribute one single source-code in all platforms. I see it the other way around, “web apps” are here to stay and evolve.
• mwcampbell 9y ago
  This post reminds me of a few old blog posts by Glyph Lefkowitz (of Twisted Python fame): 1. on what's wrong with web development: http://glyph.twistedmatrix.com/2009/09/oh-atangled-web-we-weave-from.html http://glyph.twistedmatrix.com/2009/09/oh-atangled-web-we-we... 2. on how to fix it: https://glyph.twistedmatrix.com/2009/09/web-untangled.html https://glyph.twistedmatrix.com/2009/09/web-untangled.html 3. earlier, on the problems with generating HTML through string concatenation: https://glyph.twistedmatrix.com/2008/06/data-in-garbage-out.html https://glyph.twistedmatrix.com/2008/06/data-in-garbage-out.... Also, my own personal plea: If anyone tries to create a new platform or front-end framework, targeting the browser or otherwise, please don't neglect accessibility for people with disabilities, i.e. with screen readers and the like. At least the Web sort of gets this right.
• pocketsquare2 9y ago
  The fact that I couldn't read this because it redirected me to a Medium web app that I wasn't logged into told me everything I needed to know about the article. The medium remains the massage.
• jimnotgym 9y ago
  If, as the article (and much of this thread) seems to suggest, the problem we are trying to solve is 1) Serving a GUI application to multiple users in a way that they can trust 2) Maintaining up to date versions without client side updates 3) Storage of data on a remote server over the internet, enabling saas etc. 4) Easier GUI development using an IDE. This points to needing something more akin to Citrix/RDP/Terminal services. Run full blown GUI apps on the server and serve an image of them over the network. This needn't be as bloated as the MS implementation, but seems to solve those issues above
• johnny22 9y ago
  > For the first time, a meaningful number of developers are openly questioning the web platform. Definitely not true. People were questioning the web app before there were a meaningful amount of web apps.
• markhahn 9y ago
  silly author - sandboxed binary apps won't solve the problem. your whinges about client-server communication are inherent to, you know, clients and servers. whether the thing on the client side is real app or a web app is irrelevant. what matters is the communication. imagine if that channel could only carry keyboard/pointer input events to the server and static images in return. yep, that would be pretty robust.
• LoSboccacc 9y ago
  nah. it's at best time to fix javascript and css, the whole concept of browsers as delivery mechanism is awesome and it's here to stay
• hutzlibu 9y ago
  I rather think, It's time, to completley ignore sensationalistic rant's like this one. First of, killing a technology does not solve anything. It just means less options. So do propose your better solution (and build it) - then we can talk about killing the current thing. But the way it is today, the web works. Definitely not flawless and in large parts really ugly (just browsing with open dev-tools is horrifying, when you see all the errors and warnings thrown at you) - but it is big and reduntant enough, that you can mostly choose only the nice parts. XMLHttpRequest is ugly? (I allways thought so) Well, there are WebSockets now. Javascript lacks typesupport etc? - Use Typescript The whole DOM and *script languages in general are ugly? Skip it all and use only WebGL and Wasm. And your app will still run allmost everywhere. That's the power of the web - that's why it became so important. It just works. And it is very easy to start doing it ... so many people did this, who do not have a CS background. And obviously they made horrible things from an academic point of view. But things still kind of worked for them. And security ... well, so far I have not yet heard of a save language/OS/Plattform where people can work productivly without years of studying the theoretic backgrounds. So in general yes, I am very open for better designed alternatives. In fact I am looking for one since I started web-developement, but not so much for angry hyperbolic rants like this one. They are not helpful.
  • kowdermeister 9y ago
    What's odd is that this article is so well written that it really clicks with bitter developers who are just confused in the vast sea of alternative technologies with the web. At least that's my guess why there's so many upvotes here. I feel that anyone who rants like this comes from a low level micromanagement world where they have extreme control over everything any they can't have it with web technologies. Fine, but why shit on other developers carpet? I think the web platform is one of the best innovation the software industry has experienced since the 80's. Can it be better? Of course, yes, definitely and it's getting better. I have to agree that posting bitter, "everything is wrong" type of articles is really not constructive. And for god's sake, learn to use your effin' tools.
    • deleted 9y ago
      [deleted]
• benjaminjackman 9y ago
  I feel like the quote about democracy being the worst system of government except other could easily be adapted to the webapp platform. It certainly has a plethora of issues, I am not trying to gloss over that in the slightest and it would certainly be logical fallacy to assert just because it's the most popular platform it is therefore the best. However, A lot of what appears to be recreating the same computer technology over and over is actually not recreating but I think selectively rebuilding platforms, picking up pieces of tech and ideas from the junk pile of previous ones and seeing now they might actually be workable. This process also allows discarding the dead weight of bad ideas no one bothers to pick up and bring in. It's like we do development by tossing useful ideas into a house. Then when they house is literally bursting with the all the orthogonal junk we've tossed in it over the years, but which programs have come to rely on we say ... well that place is a mess, let's start a new house, and we repeat the cycle, taking the best pieces from the old house as we have the resources to carry them over. Sometimes we have a particularly good and consistent plan of what we want in the house, so we can put up a lovely one ... initially. However inevitably, as is the case when you are still discovering new ideas and techniques as we go along, you notice your neighbor with some hot new feature, and rather than lose ... um guests (this analogy is getting pretty stretched) we say, ok we'll add that I guess, not wanting to be hopelessly outdated and lose out on that cutting edge of cool features and dragon chase of increased productivity and nifty little bits of syntax sugar or cool tricks or whatever. So existing platforms typically can't be hoisted wholesale onto other platforms anymore than a house full of junk can be moved from the country to a different climate on a different foundation. It just usually doesn't work well because the hoisted platform is typically at a stage of high refinement to it's niche, built on a several assumptions, even a few of which failing wipe out the ability of the hoisted platform to function either outright or at an acceptable level. I think that a variety of competitive pressures from large players capable of making feature bloated browsers is the best we can reasonably expect from a societal system built fundamentally around competition and not collaboration, cooperation, and coordination. Even still we face large locked down platforms like iOS where you cannot run any web rendering engine (e.g. firefox / chrome are just glorified safari browsers due to apple app store policies forbidding custom rendering engines like gecko or blink) or interpreter you please, or my pet peeve even any url with a %s to act as your user set search engine (only a list of 4 options is available), which puts a strong gate in front of users freedom to choose how and what they run on and interact with their pocket computers. Where am I going with all this? I guess webapps as a platform, as bad as they are only exist as such because they developed as a race between different browser vendors to one up each other with cool features. This process is like throwing useful stuff into a house. Getting each of several different platforms to agree on a standard for applications and then implement that in a consistent portable way seems almost impossible to me.
• WWKong 9y ago
  The biggest advantage for a hobbist developer like me is that web development makes a single code base possible. One code base runs on phones, tablets, desktop, across OSs etc. It would be impossible for me to write and distribute solutions otherwise. Multiple programming languages, deployment overhead across app stores etc. I miss the provision of notifications the most. With PWA I can cover Android, but I don't think anyone allows notifications from websites (I don't).
• erikpukinskis 9y ago
  Call me when some other platform gets: 1) sub-100ms installs and upgrades 2) a secure sandbox in which to run untrustworthy code 3) distribution without gatekeepers Until then every other platform is playing catch up. And maybe in the meantime ask yourself why is the web so popular if it's so bad? Is it just complete stupidity, or is there maybe some form of natural selection happening and you're not understanding the fitness function?
• cromwellian 9y ago
  I was about to say, it's time to kill monolithic native apps that live behind DRM'ed App Stores, can't talk to one another effectively, can't be composed, must be explicitly managed by users lest they run out of storage, and have an enormous transactional cost to trying them out. Or I could point out that explicitly designed application protocols with native clients over the years have also shown themselves vulnerable to attack (e.g. IMAP, SMTP, etc), or that most of the attacks on the Web have not been XSS/XSRF but server-side hacks. Or that Android's native app platform is full of malware and viruses that even Google hasn't been able to completely eliminate with deep scanning. Is the price of security that we throw away the Web and HTTP and implement everything as silo'ed IOS style monolithic apps? It's a price too high to pay in my opinion.
  • cromwellian 9y ago
    Two -1 but no rebutal tomy points about epmerality and drm
  • neotek 9y ago
    Personally, I vastly prefer the iOS ecosystem precisely because apps are silo'd and sandboxed. I have never had to worry about whether I can store data securely on my phone, never had to worry whether any particular app I've installed is going to do something nefarious to the underlying filesystem or to other apps, never had to bog down my device with (largely bullshit) anti-virus / anti-malware apps or anything like that. iOS apps Just Work™, and incidentally the "transactional cost" of just tapping a button once to install any particular app hardly seems onerous to me. And the fact remains, as is always the case with these debates, that the uncountably vast majority of users could not care less about the underlying technology that lets them play Candy Crush. Nobody is ever going to build a mass-market consumer product targeted specifically at people like you or me regardless of what preferences we have. All users want to know is that their device works the way they expect it to work and is as easy as possible to manipulate. Having said that, I'd be interested to hear you expand further on what price you think you're actually paying and why you consider it to be too high. What is it about the iOS model that's holding you back so much, and how do those drawbacks outweigh the benefits? In concrete, real-world terms, what is your use case?
• thegigaraptor 9y ago
  I almost signed up for that site, only so I could respond to that article. Why kill the platform that can be accessed from devices available to everyone, everywhere. Cross platform support on applications is taxing, even with an engine like unity that offers multiplatform builds, if you want to get a product in the hands of the world, you build it on the web.
• uberemployee 9y ago
  Some of the assertions from the author about how things were in the past are pretty off. Office 2000 wasn't happy with 75 MHz and 32 MB ram at all. I would say the average computer at that time was at least 200MHz with 128MB of RAM. In addition in 1995, developer "platforms" were rarely Windows-based. Borland was still hugely popular at that time, and DOS-based compilers were still big. The assertions he makes about the developer platforms are a complete joke: "Support for graphing of data, theming, 3D graphics" were completely not a thing, nor was "Sophisticated support for multi-language software components". I'm pretty sure the author didn't develop back in 1995.
• mplewis 9y ago
  Sure, and what's your plan to replace the webapp? Remember, webapps replaced desktop distribution because they: • Work on all platforms • Run without installation • Provide a quick development and update cycle So whatever you'd like to replace the webapp with has to do at least _some_ of those things better. And unless it rolls out to nearly everyone who already has access to a web browser, you're going to be competing with the imperfect but "good enough" platform. Further – the author criticizes open standards because they're not perfect. Sure, no one will be implementing the full HTML5 standard from scratch, and there's a lot of waste in what the W3C produces. But what's your proposed alternative? A return to closed, vendor-proprietary UI frameworks and DLL interfaces?
• youdontknowtho 9y ago
  i enjoyed this even if it was more of a hand-grenade-come conversation-starter.
• AdeptusAquinas 9y ago
  >But Office 2000 was happy with a 75 Mhz CPU and 32mb of RAM, whereas the Google Docs shown above is using a 2.5Ghz CPU and almost exactly 10x more RAM. The pixel count of that win 98 screenshot could probably fit in the top left corner of the menu in google docs.
• ianamartin 9y ago
  I think that most of what's being complained about here is that it's very difficult to write secure web apps that allow the typical business model of web apps to work. If your business model is getting attention, sharing user data, and pushing ads everywhere, it's hard to leak some data to unknown parties without leaking all data to unknown parties. It's not by any means trivial to completely lock down a web app. But it is possible to do it well enough that attackers don't bother with technical attacks. Social engineering is an easier vector. And that will always be the case after you close a certain number of holes. That number gets larger over time, but as new attacks get discovered, good frameworks catch up and at least encourage you to close them if not outright doing it for you. Something something it's unsurprising that a person doesn't understand a point you're trying to make when the person's paycheck depends on them not understanding it. Same thing with web apps. It's unsurprising that web apps are insecure when the business model for most of them depends on them being insecure. I'm not arguing that anything is hack-proof. But according to the article, it's impossible to have perfect security in a web app, so let's burn it all down. My counter to that is this: it's impossible to have perfect security anywhere. On any platform. Everything is hackable. Users most of all. So since we're complaining about how impossible this is, then we should all shut down our computers, go home, and find another way to make a living. That's not going to happen, and it shouldn't happen. But what we can do is take a close look at why the security measures we can deploy are typically not: in my opinion, it's very often a business decision more than it is an engineering failure. When security comes up as a topic in native platforms, many technologists seems to be willing to take a hard stance: any back door, no matter how well intentioned, will be abused. Web apps that depend on ad dollars are the definition of back doors. Here's an idea: create a product that people want and charge people money for it. It simplifies your security model enormously because you don't have to choose what to leak to whom. You treat every leak as an existential threat to your bottom line. With that as a driving mandate, limiting attack vectors to gaming users becomes a lot more doable very quickly. Then you move on to educating users. Security of private information and money isn't a new game. People have been finding ways to steal property since the beginning of recoded history. We're being pretty stupid if we think it's new problem. Do people call for banks to shut down because it's possible to forge a check? Call for the Fed to shut down because it's possible to get robbed? Of course not. But when a fundamental part of your business model is stealing from people, it can't be a surprise that other people besides you are also stealing from them.
• suixo 9y ago
  One advantage of the web is that you can browse, discover, and test new apps directly inside your browser without needing to install anything on your system. Image you had to install a software any time you visit a new interactive website or check out a new webapp. I'm curious to see the second part of the article!
  • MarkMc 9y ago
    Sure, that is an advantage but I wouldn't say it is a strong advantage. With app stores I can view screenshots and videos before installing the software. The app runs in a sandbox and I can uninstall it very easily.
• zAy0LfpBZLC8mAC 9y ago
  > The fix: All buffers should be length prefixed from database, to frontend server, to user interface. If you think that that is a solution to anything, you must be living in a universe where ASN.1 implementations have not ever had bugs, in particular they must never have had any vulnerabilities. It's certainly not the universe that I live in. In that same universe, packet sniffers/protocol disectors probably also never had any vulnerabilities due to blindly trusting length values?
• smashingfiasco 9y ago
  So... am I mistaken, or didn't the W3C try to replace the web as we know it today, with XHTML? Didn’t that fail? I don't doubt that the author knows their web history, but reading this, it's like they've got their blinders on.
• ptr_void 9y ago
  I think having separate browsers for web documents and web apps could solve half of the issues.
• feelin_googley 9y ago
  It is a triumph of programming ingenuity that programmers have been able to accomplish almost anything via a "web browser". Anyone can argue the benefits. If if there were few benefits the novelty alone might be enough. But does anyone ever consider the costs? The analysis I have in mind is: costs versus benefits of using a web browser to do x, where x is anything and everything, no matter how important. The "costs" are not costs to the programmer to implement but costs to users, e.g., risk of having their personal data stolen. To give an example, weigh the benefit to Equifax customers in having their data accessible through a web browser versus the cost of having their data exfiltrated without their consent. Or, weigh the "cost" of having to dial a toll-free number to order a credit report and not have one's data stolen online versus the "benefit" of being able to order a credit report with a web browser and having that data stolen online. Websites can be used to effectively disseminate public information, with relatively little security risk. For example, djb's tcpserver and httpd to serve static web pages. In continuous use since the 1990's, these have never had any security issues to my knowledge. IMO, this level of software is qualitatively different than software which is released with security flaws, which may or may not be later fixed (sometimes decades later). IMO, using the web to distribute public information is a benefit that outweighs the costs. I am not worried about static websites, assuming the right software choices are made. The blog post acknowledges this: "The web has issues as a way of distributing documents too, but not severe enough to worry about." If Equifax had a static page served by djb's httpd showing number to call to order a credit report, I would be far more impressed than if they were running a "web app" to take orders online that connected to some backend database of user data. Because for that specific use case, a very limited use of the web is the smart thing to do. I would like to see more people opining that, for "serious uses" i.e., where the risks to the user are potentially serious, the web has limited utility. The current thinking seems to be that the web has unlimited utility. For everything. We all know that with enough effort the "web browser" can be used to accomplish almost anything. I remember an RFC many years ago from Marshall Rose that said something like "the web is the new waist". I also remember in the early 1990's, people were afraid to send credit card information via web forms. "Unlimited utility". Today, many young people, including many programmers, see no difference between internet and web. They are synonymous. "Unlimited utility". Maybe utility should be weighed against costs such as security risks. IMO, the web has limited utility. Would you sacrafice a little convenience, e.g. option to order a credit report online, if it meant your data was not part of the data stolen from Equifax? I would.
• draw_down 9y ago
  Ah yes: this open, ubiquitous platform used by hundreds of millions on a huge variety of devices, let's get rid of it. I hope this person is not one of those techies who claims to love "boring" technology.
• di4na 9y ago
  There are lot of bad things here. Main reason for web apps stay : they can evolve without a distribution life cycle. Around REST and RPC : No what you see on the web is not REST. And please stop bringing back RPC. It was a bad idea before, it is still a bad idea.
• k2xl 9y ago
  Reminder me of this article from Wired... back in 2010 "The Web is Dead" https://www.wired.com/2010/08/ff_webrip/ https://www.wired.com/2010/08/ff_webrip/
• city41 9y ago
  > web apps fix those but then re-introduce their own very similar mistakes: SQL injection... Any system using a SQL database is susceptible to SQL vulnerabilities, web based or not. Not to mention SQL injection is a largely solved problem. Creating concatenated strings for your database to execute is hardly the web's fault.
• miguelmota 9y ago
  It’s time to kill t̶h̶e̶ ̶w̶e̶b̶ rants with little substance on medium platform.
• deleted 9y ago
  [deleted]
• crispytx 9y ago
  Just my opinion, but developing for the web is much easier than building native mobile applications. This is a good thing from my point of view. Native development has some catching up to do in this respect.
• unclebucknasty 9y ago
  He's spot-on with a lot of his analysis, including security around REST/JSON. A few weeks back, I made similar, though less-detailed comments on another HN-thread, particularly in a SPA context. The responses I received were essentially "it's not a problem if you do it right". But, of course it's inherently less secure when you now have data flying off of the server to be rendered on the client vs. consuming it all on the server and rendering the view there. You're kind of doubly-exposed. It's not that there are no techniques for attempting to secure it. It's that it adds more complexity and that it's easier to leak data to your client (or an unsanctioned client) without realizing it. Because, of course a REST endpoint just sitting there on the open Web, intended to serve up raw data to an app is less secure than an app that holds on to its data and serves up text/html requests. So, with a SPA app, you'll find yourself doing a lot of things twice (client and server side), and that includes security. The arcaneness of the techniques for securing all of this that he mentions is also accurate. It just amplifies the problem. The Web was not designed to be an application platform, let alone a secure one. It's hard to ignore this fact in any earnest discussion.
• Chiba-City 9y ago
  The Web is a failure of cheap tool distribution by attention seekers distracting possibly greater talents wasted on short lived skills or failed projects. We mostly lack use-case qualification, support metrics, documentary weight or programmatic contract between tool makers and users. None should take commercial interest in tools without references, tutorials, cookbooks, i18n support and road maps shared between stakeholders. The ecosystem of Unix and Windows literature was exceedingly well written and stable. Backward compatibility was important or breaking changes well flagged. Real software for profitable operations (not entertainment) requires stakeholder analyses for costs, adaption cycles, business models, risk and so forth (no screens or code yet) taking weeks or months even in "move fast startup" mode. Chasing tooling and testing against API changes in a code dump is unwise. Sadly pop promotional blogs make breathless lottery winning with "bailing wire and chewing gum" seem desirable or probable. That's nonsense. We never need hear more "dorm room miracle" stories or "DB2 rewritten in Forth" fantasies. Anything rushed is a bad bet for talents wasted on shifting sands. The use-cases absolutely matter for tool applicability in a multi-stakeholder (contract obligations) profitable operation. Everything else is a distraction. I suspect voices of endless tool fetish, "exploratory programming," consumer gaming and "content scripting" might disagree. They do not matter. Those people suffer special needs. The Web as a tool platform has mostly failed. The most "convenient" tools for people measuring fake productivity in keystrokes have failed the hardest. [Edit: typos]
• BjoernKW 9y ago
  An article about the web and it doesn't mention quintessential terms like 'link', 'network' or 'platform independence' even once. Do you know why your 1990s app was so much 'better' than today's web apps? Because it was only supposed to run on Microsoft Windows, and a specific version of Windows at that! The same applies to layouts. If all you have to deal with is SVGA and Windows 95 layout constraints are a piece of cake. > Really impressive software would be embeddable inside Office documents, or extend the Explorer, or allow itself to be extended with arbitrary plugins that were unknown to the original developer. Those were only reinventing the datatypes system introduced in AmigaOS in 1992. > In part 2 I’ll propose a new app platform that is buildable by a small group Yeah, because that's always worked so well in the past. > there’s no Web IDE worth talking about Save for Intellij IDEA / WebStorm, Visual Studio Code ...
  • deckar01 9y ago
    > Because it was only supposed to run on Microsoft Windows, and a specific version of Windows at that! I worked on an ebook editing tool in 2013 that only supported the two most recent versions of Chrome. If you have a product that is truly valuable to your customers, they will install dependencies to make it work.
    • AndrewCHM 9y ago
      chrome is free, windows ain't
  • LeoNatan25 9y ago
    > WebStorm, Visual Studio Code ... You clearly have no idea what an IDE, as opposed to code editor, is.
• nly 9y ago
  > The fix: All buffers should be length prefixed from database How does this fix anything? When you compose length prefixed data (in e.g. arrays, nested stucts) you still have to check if these length and offset fields are coherent. If these length fields get passed over the wire from the user, you still can't trust their values. Binary protocols don't solve this problem, they just make doing the validation less CPU hungry.
• beager 9y ago
  I know it's cynical, but every time I see an "It's time to kill [x]" piece, I assume the author has some competing solution they're trying to hawk. In this case, very much no solutions are offered (but promised in future installments). The web sucking is a symptom of its success, not an indication of some intrinsic inadequacy. HTML is fault-tolerant. JavaScript is an add-on, not a runtime requirement. CSS degrades gracefully. The web is resilient, forgiving, and accessible. And yeah, a little slow and broken, but so?
• topspin 9y ago
  I strongly disagree with the part about REST being a workaround for browser limitations. REST is about manipulating an arbitrarily large namespace with a small number of verbs; an elegant and powerful design pattern that actually deserves a better platform than what HTTP provides. It transcends browsers and protocols and will be reinvented in any well designed system that manages to survive its own evolution. The rest can basically be summed up as "the web is a mess," and I agree with that. Can it be otherwise? I have often thought the coercion of HTML+CSS into a platform for complex interactive applications has been pretty terrible. Some of the links to other blog posts that supposedly support Mike's argument are actually criticisms of "JavaScript development." Yet JavaScript is just a programming language, like any other; it isn't limited to web development and the flaws it has are being addressed. JavaScript is the baby in the bathwater and there is no reason it shouldn't be a big part of whatever comes next. Show us something small, powerful, clean, open and that unifies desktop and mobile and maybe you'll get somewhere. I am not one who believes the current paradigm is immortal; if this blog post contributed anything of value I think it is the observation that the web stack has effectively failed mobile; native tool sets work better in almost every way and are indeed the first choice when you need to make high fidelity mobile applications. That shows the limitations of the web stack and provides and opportunity for a competing solution.
  • kgilpin 9y ago
    Although REST generally boils down to SELECT, INSERT, UPDATE, DELETE. For an inspirational interaction model, look to SQL.
• creatorkarma 9y ago
  Nothing you’ve wrote here is surprising to me. I’ve never found the web app drumbeat to be compelling. The insistence that it’s the be all end all is myopic and usually the domain of those who are trying to protect turf rather than create great experiences that are secure, powerful, pleasing and fantastically useful. Thank you for stepping up as a full stack developer and presenting a case without obvious bias in favor of the one web to rule them all. I appreciate it. John-Michael Scott - a guy who’s been around a long time and watch this app evolve...
• peterwwillis 9y ago
  You can't kill the web, it has to die of natural causes. Even if everyone agreed to abandon the web tomorrow we couldn't. Make a good replacement for the web, get everyone to want to switch, and then migrate. You might accomplish this in 10 years.
• datashovel 9y ago
  "...unless you work at Google or Microsoft you can’t meaningfully impact the technical direction of the web" I think this is a great argument for why we need a (for lack of a better name) "meta-browser". An application on the user's machine that contains and runs browsers. Then flip the control to the developer. If I'm only going to design for [name of obscure but super secure browser], my success doesn't have to be dictated by the fact that 99.99% of users didn't originally open my browser of choice. If they come across a page only supported by this little-known browser, they are prompted that they can install it, or they can decide to move on to the next website if the developers didn't write any fallback. This doesn't just ensure the web can remain open, but makes the whole architecture (the web itself) an open question and allows all aspects of "the web" to evolve more smoothly.
• RogueIMP 9y ago
  This article came off as a big whine-fest... Yes, security is an issue. It always will be. Yes, we need to find a better way.. But without proposing a viable alternative or solution, it's just blah-blah, complaint-complaint.
• iaabtpbtpnn 9y ago
  The Web is fucking awful, and our industry's rapid acceptance of it represents a massive moral failing across all of us. We have ruined everything, and we need to take responsibility for our actions.
  • iaabtpbtpnn 9y ago
    Nobody likes this nonsense except advertisers. It's garbage, and everyone posting on HN knows better.
• johnvega 9y ago
  This is a WEB APP https://3d.delavega.us https://3d.delavega.us using 3js. It can run on most iOS and Android smartphones, most Windows and macOS machines and Linux computers. It is likely to run on over a billion devices. It should just take a few hours to a few days to code depending on your coding skill level. Did I mention no installation required. Can a non web app or native app be better than this?
• paradite 9y ago
  The fact that this article is written and distributed with medium (web app) invalidates everything the author says. It's working fine, you are using it, and millions of other people are happily using it. Web is great for users because they can do arbitrary operations with just a browser without needing to install anything. I don't know about you, but I build web apps to help users, so it's okay for me to suffer a little pain to make users happy as a developer.
• oblib 9y ago
  From an engineering standpoint there are surely some valid points here but I have to say that I don't think things are all that bad. HTML,CSS, and Javascript separate the layers of a web app fairly nicely. It's all free for the learning and using and even distributing, and it comes with a huge community to lean on for support where many, if not most, of any questions you might have are already answered. Those parts work pretty well and have a huge user and developer base. You don't just toss that out and tell everyone they need to start over. To even imagine that you first have to ignore the real value of it, which is truly immense. So much so that in reality you cannot ignore it so whatever you do has to be compatible with it, or at least accommodate it. I have to admit this leaves me curious about what "Part 2" will offer.
  • jiggunjer 9y ago
    > HTML,CSS, and Javascript separate the layers of a web app fairly nicely. Except they don't. Most devs aren't even aware of what divs they are using for pure styling vs semantically correct ones. They think all the html they write is by definition semantic. Then there are the less frequent but even more insidious cases where css is used for content.
    • oblib 9y ago
      Does that really make a difference? Seems to me that's a feature that's generally described as "more than one way to do it" and the goal is getting the app working and shipped not to appease some outside critic's sense of semantics.
      • jiggunjer 9y ago
        Styling separable from content is the direction W3 wants to go. So being aware and adhering as much as possible should improve performance and long-term maintenance burden. I agree the tradeoff probably isn't worth the extra time needed to carefully structure your html and do css acrobatics. I just get triggered when someone claims the holy trinity idea works good with html/css/js. It doesn't, but that's OK.
• overgard 9y ago
  At my last job, the app we were creating had both a web frontend and a Qt ui, so it was pretty easy to compare the relative difficulty of the two approaches since we were generally doing the same thing in both. Honestly it was kind of a wash. Qt was a little nicer as a developer because it meant never leaving visual studio, but I can't say that Qt offered some great advantage over HTML/CSS in terms of UI paradigm. I'm skeptical of this premise in that, yeah, the web isn't that great a development platform, but the alternatives aren't significantly better overall.
  • jiggunjer 9y ago
    You can program in much more complex scaling behavior. Bet you just tested on a single 21" monitor at 96dpi.
• Grom_PE 9y ago
  The "unfixable design flaws in the web platform itself" that enable HEIST attack are trivially fixed by disabling third-party cookies, on the client side — in the browser's settings, and on the server side — by using SameSite tag in the Set-Cookie header. I'm just left wondering why browser vendors don't apply this behavior by default, it would've been much cheaper to fix the broken sites than mitigating the security hell that 3rd-party cookies provide.
• EGreg 9y ago
  There is only ONE major thing that's bad with web apps: you have to trust the server. Which makes them unusable for truly secure applications like bitcoin clients. Because you can always say you didn't authorize an action! I think the future is IPFS and other content-addressable protocols. Why aren't browsers adding them to the web alongside https?
• dan-f 9y ago
  I'm not impressed with this article: - The author failed to draw a clear distinction between "The Web" as an application platform and "The Web" as a network of semantic information. - Digging deeper, "The Web" the application framework is pretty flexible. There are plenty of ways to use hypermedia and HTTP, while using your own non-HTML/CSS UI tooling. - The article strikes me as ill-researched -- the author writes "Here’s a good blog post on Flux, the latest hot web framework from Facebook". Flux is definitely not the latest from Facebook, and some of the linked articles were from 2015. For better or worse (I think better), front-end is moving really fast, and the web platform roast listicles don't age well. - The point about "UI Complexity" is just odd. UIs should not be complex. Comparing the windows explorer to Google docs is comparing fruits to vegetables. The point "look! we still have toolbars and shades of grey" has nothing to do with the web and everything to do with UX metaphors and familiar affordances. - "Things as basic as UI components are a disaster zone". UI "components" are not basic! What is a component? No seriously, ask a programmer content with OO languages, and then ask someone who prefers functional languages. Then ask those developers to agree on an interface. Though I do agree with: - Web apps are slow. Painting is really complicated. - So many apps are written with the assumption that they're always online. The author is right that users have low expectations when it comes to good offline experiences. - The web wasn't designed with our contemporary single-page application use case in mind. - JS could obviously be way better. - The need for backwards compatibility is pretty crippling. - Security is difficult to get "right".
• BuckRogers 9y ago
  Agreed. This is why I'm retraining myself on C# in 2017. Native is better and the web should remain a primarily lean and fast text document delivery system. I'm loving C#/.Net so far, It's almost as good as Java serverside but has the (well-supported) ability to natively produce iOS and Windows apps (the two most important platforms IMO). One stop shop, and it's output is native code. It'll also support wasm when that's a widely used thing as well. Having to learn one platform like Java or C# and work out the rest of my career is a bonus too. I've had it with fashionable technology one year to the next and I certainly don't want to maintain these leaning Tower of Pisa stacks. Not to mention, on a similar chord as the author stated, we learned a lot of lessons over the decades. Part of that lesson is industrial-strength tooling (IDEs) and languages (typed) are important. C#, Java or discard IMO for most greenfield projects. At least if I'm to maintain it longterm. Others may differ and that's fine, but at least all of this is my philosophy at this point with everything that I've seen and experienced. I'm really looking forward to his part two.
• brlewis 9y ago
  If you're trying to prove that a platform is unfixable and present as evidence the assertion that it's reinventing things from a previous era, you're doing it wrong. Even assuming it's true, reinventing in no way makes the platform unfixable. Quite the opposite; you're asserting it's being fixed. If you're trying to prove that a platform can't be made secure and present as evidence security issues that have been made into non-issues (SQL injection, XSSI) you're doing it wrong. If you're arguing that it's time to start over from scratch don't criticize things that could be fixed without starting over from scratch, e.g. lack of a binary RPC format.
• mgalka 9y ago
  > Way back then, the web was locked in a competition with other proprietary platforms like Flash, Shockwave and Java Maybe this is just semantics, but it sounds like "web" is being used as synonymous with "JavaScript."
• Falkon1313 9y ago
  The internet existed long before the web and there are other protocols than HTTP - TCP/IP, UDP, SSH, telnet, etc. Desktop applications are still built that use the internet for communication but don't try to ram everything through an HTML document. And they're usually far-superior to webapp versions. But now many people think that things should all be web-only, over HTTPS only. We built a palace of many ports and protocols, but we've locked ourselves away in one bedroom as our own prisoner. Despite a perfectly nice dining room with silverware and dishes, we instead scoop our food off the mattress with our hands because a firewall or NAT might prevent us from getting to the dining room. Where the web does claim superiority, and why everyone now wants to use it to build applications that are totally unsuited for it, is primarily four things: 1. Run-anywhere cross-platform compatibility. This could be addressed by better cross-platform compilation and cross-platform UI/UX for native applications. Most mature languages have that ability now, but it's not perfect - still in the 'needs work' phase. Likewise browser compatibility and responsive design are still not perfect, but they've come far enough now that they're workable enough. But, run anywhere fails if there's no internet connection or the servers aren't responding. Native still wins there. 2. Simplified distribution and updates. People like that no installation is required and the latest version of the software is distributed from the server every single time a page loads. But in reality almost all modern native software can be built with a simple 'click run to install' installer, and can handle routine updates fairly seamlessly. Native is still more efficient, it just has those two extra 'click to download' and 'click to install' steps. If that could be streamlined, native would win. 3. Ubiquitous acceptance of network requirement. It's unthinkable to block 80/443 and HTTP/HTTPS, so anything can communicate that way. Programs that use other ports or protocols may have trouble with firewalls, NAT, and other middleware. It's kind of insane to limit everything to one or two ports and protocols. That needs solving. That's where the web really wins - only because we've imprisoned ourselves. 4. Server dependence. This is not a feature for the customer, although 'cloud storage and synching' is sold as such. It means that the company making the software gets all of the data. If their servers are ever shut down, or even if you're just temporarily offline, you don't have access to your data. And if someone breaches their system, then your data is effectively public. Local native apps leave you in control of your data and can work with it offline, even after the company that made them goes out of business. True, your system can be break (so keep backups) or be breached, but it's more under your control and less of a target than a system containing everyone's data. Overall, the web is great for document distribution, but it's only real winning point when it comes to applications is that we've locked ourselves into one single port and protocol out of all that are available and that one happens to be the one that the web uses. If we could solve that, internet applications could be worlds better. But no new javascript framework or CSS compiler will solve that.
• bluetwo 9y ago
  I guess we shouldn't drive cars anymore because the auto-fatality rate is still greater than zero.
• piyushpr134 9y ago
  Internet is at risk of becoming low level plumbing of the snazzy house of proprietary app world. With the advent of app-only companies and products, internet, as we knew it, is slowly taking the backseat. App world is full in control of their masters and it is a very snobby world. Biggest irony of the sharing economy is that apps don't like to share, linked to, looked inside. This world does not have a concept of hyperlinking, a basic premise of the internet. It is surely very un-internet like. It all seems designed to lock in the users to handful of apps and make them so myopic that they don't even realize that there are options. Let me take a step back. Internet, in my view, is the ultimate manifestation of FREEDOM. Everything is/was free: * Access to internet is free after you have paid your ISP. Almost everything that has been digitized is available on the internet for free. You could change ISPs and everything still worked. * There was hardly any government control over the internet. They wished. However, it is designed in such a beautiful way that there are very few central systems. This makes the internet very tough to control (unless of course you are China). * The real estate on the internet was also very cheap. You could buy a domain name in $10, a cheap server in $5 and go online with your site. * There was no limit on number of sites you could visit. These sites could not steal your data. They could store some of their own data at your end but not steal much. Once you close the site, they cannot send you any popups or notifications. They cannot run in background and monitor your activity. Track your location, speed, acceleration etc. * Better still, you could write blog posts which millions could read and cost you zilch. There were these things called RSS feed, which made it even unnecessary to go to sites to read content on them. You could just subscribe to RSS feeds. * In fact, you could link to other people's property and it was encouraged. People who visited your site, could easily hop to any other site you linked to. You did not have to pay anything for it. * HTML was written in a way that made even sloppy code work. HTML was so dead simple that anybody could make a site in it. No lock-in. Almost all code written for one browser worked in all browsers. There were tonnes of browsers. This sloppy code could render on almost any device and browser. Again no lock-in. You could look into the html, css and javascript code of any site. It was free for all. Internet was the ultimate open source. May be internet was too open to make money. So 'they' invented the app world. App economy is a dream for big companies. Huge user base, free & rich media push notifications, ability to steal the ultimate of user social graph (call logs, sms history) and on-ground sensors to enable steal very personal data of users. Lets have a look at this world as to how it compares to the internet. * Internet fast speed lanes, internet.org, anti net neutrality deals. Enough said. * Apps do share the internet. However are themselves in control of one company which makes it, one company which distributes it. * Apps have already made it impossible for a part time hobby dev to produce and maintain 3-4 different apps. Hardly anybody I know, knows obj-c and java both very well. * Apps have made it difficult to have more than 20-30 of them on your phone. More than that and your phone would be left with no space. Once these select 20 are there, you are locked into them. They steal your data and periodically push you notifications! A we just love them. * We first managed to kill RSS. I remember there was a huge campaign one time which demeaned RSS. Google then killed reader for no apparent reason. Is the internet world a puppet show ? * Apps cannot link to other apps. You cannot link to particular page/screen of particular app in a generic way unless the other app wants it and allows it. There exists no generic way to do it. The standard way could be that you talk to the other app dev, sign a contract with them and possibly even pay them. Linking is dead. * Apps are not free. They are locked in to a platform. If you want to port your code, you would need to rewrite the whole code base. (hybrid apps don't seem like they are happening) I think we are witnessing end of internet as we knew it. Companies are suddenly trying to kill browsers and generic internet. They are trying to invent a proprietary walled garden internet.
• deleted 9y ago
  [deleted]
• mailslot 9y ago
  I agree with most of the author's opinions. I'm old enough to have seen the rise & fall of 90's development. Developers who have been ingrained in web technologies tend to think of the times before as dark ages. They really weren't. Today simply isn't the absolute best that all things have ever been. Sure some things were a bit simpler & less flashy then and hardware was more limited, but there were a lot of great ideas that have been forgotten and shoved aside in the excitement for modernization. Best practices & whatnot. But, what the author forgets, is that this is the state of things. Really inventive ideas exist, sometimes in niches, die, and then get rediscovered and reimplemented in circuitous ways. Asinine artifacts tend to arise in every paradigm shift. I'd argue that word processing, for example, has barely caught up to the days prior to the graphical user interface. Now, with the web browser & mobile, it hasn't even come close to feature parity yet. It will, eventually, mostly. And it will be exponentially more bloated and complicated than before. Such are things.
• HillaryBriss 9y ago
  >This is why the web lost on mobile: when presented with competing platforms that were actually designed instead of organically grown, developers almost universally chose to go native. almost universally? mobile dev has enough inefficiencies and complications that, for many use cases, quite a few people today wonder if native is preferable to mobile web, especially PWAs. i mean, look at the discussion here, 12 days ago: https://news.ycombinator.com/item?id=15219154 https://news.ycombinator.com/item?id=15219154 and this: https://joreteg.com/blog/betting-on-the-web#what-sucks-about-apps https://joreteg.com/blog/betting-on-the-web#what-sucks-about...
• minitech 9y ago
  > Where desktop apps have exploit categories like “double free”, “stack smash”, “use after free” etc, web apps fix those but then re-introduce their own very similar mistakes: SQL injection, XSS, XSRF, header injection, MIME confusion, and so on. All of these are pretty thoroughly solved by picking tools that don’t let you shoot yourself in the foot, and SQL injection isn’t remotely a web app thing. (The others are far less severe than RCE, anyway, as they only affect the one app. I guess the argument here is that the web platform isn’t yet optimal? Work is always continuing to improve security – take Content-Security-Policy, for example, which mitigates every type of exploit mentioned even if you do everything else wrong – and if you think it can’t work out, point out a real alternative.)
• emodendroket 9y ago
  Uh huh. Well until you have another platform installed on anywhere near as many devices I wish you luck.
• rakibtg 9y ago
  First of all, there is nothing called web app, this are called websites, that makes sense that the author is more likely to like app's for everything. Yet web has no alternatives for what it supposed to do, so lets not try to fix it, as it is not broken. and possibilities of web technologies are limitless.
• philwelch 9y ago
  We definitely don’t have a replacement for the web on the presentation layer. Likewise, we’re stuck with web services for now for the display services sitting immediately behind the frontend. But for pure backend services, there are plenty of alternatives to HTTP that are ready to use today and more sane. There just isn’t a ratified “standard” yet (outside of large tech companies, which tend to have their own).
• MarkMc 9y ago
  What if Facebook provided a way for React Native apps to be compiled to Windows and Mac desktop applications? If such apps were lightweight and could be automatically updated, would React Native development be a serious alternative to web app development?
• ericls 9y ago
  In my experience, web apps perform way better than native apps. The other problem with native apps is that they need to be installed before use.
• dispo001 9y ago
  You would think text documents work wonderfully but weirdest parts of html [to me] are... 1) the rendering of things outside the viewport. The way wrapping of divs and lines works it seems impossible to make it render the way pdf did from day 1(?) I don't even know if there is a maximum length for pdf but in html you really should try to stay under 20 000 lines. I know, it seems like I'm splitting hairs here, but before the early 90's you could easily scroll though the entire memory of the system as if it was a single document. The amount of code was kind of a lot smaller than the infinite scroll web page requesting pre-cut chunks of xml or json where you get to manually measure the size of elements then get to do crazy calculations with the scroll offset if a new element needs to be inserted above the stuff the user is looking at. And 2) not having a nice way of doing a reference section summarizing the stuff linked in a text kind of ruins the joy of having links in the text. One ends up building a kind of disposable experience if the text is long enough. Combined, it's like having a pile of pages that are all the entry point. This is lovely for short reads but far from what books use to be. I suppose the ultimate creation is one such article that promises everyone a fire breathing pony with laser eyes in the soon to follow up. When you write one, be sure to rage at the thing everyone loves and to suggest abolishing it - to be replaced by that pony you will get in the next episode! I for one am all ready to be disappointed by this holy grail of subscribe baiting.
• oldpond 9y ago
  Yes, the browser is now the universal thick client. Full circle.
• fetbaffe 9y ago
  > All buffers should be length prefixed Fortran called that a Hollerith constant, but that was 60 years ago. https://en.m.wikipedia.org/wiki/Hollerith_constant https://en.m.wikipedia.org/wiki/Hollerith_constant
• rusanu 9y ago
  The author is not even mentioning the reason Web apps become prevalent, even in B2B and Enterprise: deployment. Not having to deal with upgrading hundreds of workstations to the latest release.
• kabes 9y ago
  I've never heard of the author of this article. Any particular reason we should listen to him?
• shalabhc 9y ago
  If we're going to kill the web, can we start by forming design principles instead of retrofitting patches on the existing design? For instance, a great principle would be to minimize shared knowledge. Having a giant pre-shared base (i.e. browser) not only restricts what I can build and how, but also stifles evolution and innovation, because the whole world has to be upgraded to the same ginormous 'standard' for us to talk to each other.
• JTenerife 9y ago
  Only the giant companies have the power to recreate the web. If they do it will be first and foremost better for their businesses. I don't even want to think about the influence of the secret services of the world.
• eagsalazar2 9y ago
  How did this article end up at the top of HN with so many points? It is a misinformed troll.
• tmzt 9y ago
  I'm working on one possible solution for application developers who don't really have much experience working with the complicated pipelines involved in building modern web applications. It also makes it easier to support users without javascript enabled. I'm calling it a Web Application Scripting Language, basically it's a template language to build interactive client-side applications that can also be rendered server-side (with actual data) without a javascript interpreter on the server. I just pushed an updated documentation site which includes a mostly-functional TodoMVC demo. https://tmzt.github.io/isymtope/ https://tmzt.github.io/isymtope/ The scripting language aspect of it is similar in some ways to elm, but does not expect a developer to be familiar with topics such as type theory and monads. This version uses Redux and IncrementalDOM, but the actual functionality it's using in those libraries could easily be replaced with something smaller and more focused on the rehydrated HTML use case.
• xj9 9y ago
  i've been talking about this for ages, but i'm glad people agree with me now. the web is a really shitty application platform. let's do something about it, eh? https://sunshinegardens.org/@xj9 https://sunshinegardens.org/@xj9 https://heropunch.io/ln/work https://heropunch.io/ln/work
• lngnmn 9y ago
  Oh lol! I have never understood how this site does not use react and nodejs.
• marcjuul 9y ago
  You know what would replace the web app if it was replaced today? Some corporate locked down solution subtly or unsubtly controlled by a single conglomerate or interest group. Recently certain corporations have been whispering about replacing the web standards with something "better". At the same time as they have been pushing free our-platform-only "internet connectivity" in developing countries. I don't want to name names since multiple corporations are implicated but for the sake of simplicity let's call the imaginary placeholder company "Facebook". At the same time we literally JUST had a major split in the fabric of the internet with the EFF leaving W3C over DRM and now this is the top-rated comment on Y-combinator? Venting frustrations is one thing, but anyone seriously advocating for replacing the web standards at this moment in time is either ignorant, ethically bankrupt or a corporate shill. Yes I know: Your mental internet filter has been finely tuned through years of weathering forum flamewars to stop reading any thread after encountering the word "shill" but please let me explain. This is the first time in the history of the world that humanity has achieved a single standardized application platform supported by all major devices! If that wasn't enough we now have amazing code collaboration tools like git(hub/lab/etc) and `npm publish`, to the point where the hardest part of writing a new web app often comes down to finding the right libraries and sticking them together. This is fucking amazing! Today's web is a land of unicorns and rainbows compared to what any sufficiently pessimistic human being would have predicted when the internet began. The technology used by the world for most of its communications is largely based on globally accepted standards and open source software!(!!). Keep in mind that this is despite a global economy that has been trending toward increased corporate control by a decreasing shortlist of major players. In short: Despite the fact that the rest of the world currently appears to be mostly made of burning garbage, web developers should be dancing in the fucking streets! If there are problems with the web then please remember: It's still the early days of the web and we've only recently begun writing very complex applications for this platform. We'll keep improving what we have and every year things will be better, but it is also always going to be the case that humans will push technology as far as it will go, so if you feel like web technology always sucks then that just means that you're always working at the very edge of what's possible with the state of the art. Changing platforms won't change this fact and the bleeding edge will always be... bloody. If anyone thinks that throwing away the world's only common application platform because "development is hard" is a good idea then maybe they should try writing a UI-heavy app supporting Android, iOS, .NET and *nix with one-click install and high security, without using any web technologies, and then come back and tell me that this is a better way. Now let me predict the future: What's going to happen is that Facebook will come out with some new app framework based on React (or React Native) which will compile to current web standards but also to the new "Facebook browser" (they won't brand it as a browser but rather as a new part of the internet that has been missing until now). They will get more and more people developing for this framework since it makes development less painful (at least for the younger web developers who are fresh out of their corporate sponsored bootcamp and have only ever tried this one framework) and when they get enough developer market share they will start adding more and more "facebook-only" features which will enrich the experience for people using their "browser". Keep in mind that I am still talking about a metaphorical Facebook. Maybe it will be a Facebook/Adobe/Amazon/RIAA/MPAA conglomerate "standards" initiative or some such multibeast. Anyway: Because "Facebook" is actively developing this framework in-house at the moment they've been pushing public opinion against current web technologies in preparation for launch (honestly given who they are and their available resources they would be incompetent if they weren't). They were planning to launch this cross-industry collaboration and framework after the W3C DRM incorporation failed to pass, using the fires of industry indignation to bootstrap a corporate replacement for web standards, but now that they actually succeeded in undermining the W3C once, they will simple continue undermining web standards via the W3C while the FCC and the rest of the world is left to attempt to start a new standards organization out of the ashes, and let's face it: The web standards were created when few people cared about web standards and the feat would be very hard to re-create without heavy industry support now that there are so many powerful stakeholders. I know this post will most likely be buried but at least I'll get the bitter satisfaction of linking to it and saying "I told you so". Or maybe I'll learn not to be so fucking pessimistic. Either way it's a win.
• deleted 9y ago
  [deleted]
• MarkMc 9y ago
  I'm showing my age here, but I think Sun had the right objective with Java Web Start. Unfortunately their implementation was awful - bloated, slow, ugly, with a complicated API and poor security. I think there is still an opportunity to do it right.
• reinhardt1053 9y ago
  The creator of this post is the same guy who said bitcoin was dead in 2016 [1]. [1] https://blog.plan99.net/the-resolution-of-the-bitcoin-experiment-dabb30201f7 https://blog.plan99.net/the-resolution-of-the-bitcoin-experi...
• janci 9y ago
  > "Buffers that don’t specify their length" This is a good thing. You just need proper escaping. To parse data with length field you need higher-level automata (maybe even Turing-complete parser) than for delimited or quoted/brace-enclosed data.
• Nila1936 9y ago
  Want to increase your business? Post ads in classified. We have world's largest classified website. Post your ads, it's free. And will be. Visit our website : http://www.myonlineplaza.com/ http://www.myonlineplaza.com/
• _alexander_ 9y ago
  Ok, alternatives?
• deleted 9y ago
  [deleted]
• mosselman 9y ago
  The web 'lost' mobile because there is no way for Apple and Google to scoop up 30% of app sales when there aren't any.
• a_imho 9y ago
  On the contrary, from the users pov the vast majority of mobile apps are inferior to a webapp. Downloading apps instead of pointing a browser to an address, while giving all kinds of control (permissions and access to the device itself) to app publishers is just silly.
• thinbeige 9y ago
  People who hate have either a severe depression or try to get easy attention. Why hating web apps? Every app has their advantages. - Native apps are great and I couldn't imagine how Sketch, Snapchat, etc. could be done as a web app - Web apps are great because I wouldn't want to install apps just for those I use once in while or apps where I rather consume than interact - Console apps are great when I focus on raw text manipulation and they get even better when working on remote servers So, why they hate?
• chj 9y ago
  Web app may not be as good as you wish, but I think GUI app development either on desktop or mobile is definitely worse. Otherwise there won't be a market for hybrid apps. For those desktop app guys who haven't heard of vue, spend some time going through its guide, you will find web development is actually much more advanced than anything you are using.
• luord 9y ago
  > thesis [...] not talking about literally all web apps. I think all my problems with this article are summed up in that paragraph. It's not so much that there're problems (there're of course) but it's just not the problems the author likes and thus goes into this exaggerating rhetoric. Safe to say, I remain unconvinced about needing to kill the web and I'm sure whatever this guy suggests in the second part will have its own share of problems, probably even the same ones. Because, as it turns out, the web isn't that special in that area; every platform has problems, some identical. Also, his description of the state of the art in the 90s suggests that the guy isn't that familiar with desktop development today (kind of surprising, given what the author has worked on). Safe to say, efficient binaries that run on just a few MBs of RAM is a) not what happens today or b) hasn't changed much in the last 20 years. Depending on what application we're talking about. Also when did the web lose on mobile and when did developers "near universally" choose to write native mobile applications?
• HaoZeke 9y ago
  Security is probably not the exact same thing as it was on desktops.. However anyone who's been burned by a Javascript miner (like on the pirate Bay) or whose data is mined for ad revenue knows that the web exposes you to a series of lesser assaults which we shrug off typically. Just because breaches in privacy and security are not as flashy as waking up to a computer which won't boot doesn't mean web apps are secure.
• bayonetz 9y ago
  I just get sad knowing what I'm missing. I've worked with a bunch of desktop GUI builder IDEs (Visual Basic, .Net WinForms, WPF/XAML, and Qt) and I've seen the immense power they have in terms of developer productivity and application performance. Something like XAML is especially interesting because it brings the styling and responsiveness of HTML/CSS to the GUI builder paradigm. I started off with them and then have slowly transitioned to working entirely with web technologies (PHP, Rails, Angular, React, you name it). Not without reluctance for sure! It's a Faustian bargain to me -- trading off overall inferior technology and developer experience for the sheer reach and ease of deployment of the web. It's nuts to me to design a visual thing like a UI by writing lines of code. The GUI builders of yore really nailed this by allowing you to design something visual using a visual modality (drag n drop, realtime layout designers, etc.). I try to explain this folks who've only ever developed for web and usually their eyes glaze over. They can't seem to (or have an incentive not to?) appreciate the impedance mismatches and the fundamental trades being made with web user interfaces.
• zhenghao1 9y ago
  Mr Wise Guy, what's your proposed solution?
• cray9503 9y ago
  "So unless you work at Google or Microsoft you can’t meaningfully impact the technical direction of the web" If this is truly what you believe. You are the problem. Killing the current system does not solve anything, proposing a solution and building it does.
• romanixromanix 9y ago
  During the last 20 years I used to prefer web apps over native (C++, Java, C#) for banking and trading applications. (although most developers didn't like to fight browser incompatibilities). 2 years ago I changed my opinion. We've developed two different user interfaces for trading at the same time. One with HTML5, Typescript, Angular, WebSockets, and the other one with JavaFX. The developement of the JavaFX based application was way cheaper, faster, pleased users more (due to multi-window!) and had by an order of magnitude fewer glitches in the UI. (But the web application was prettier).
• wcr3 9y ago
  heavy on vitriol, light on substance. fun to read if you don't ask questions.
• collinmanderson 9y ago
  I'm surprised no one has mentioned same-site cookies. This would help a lot with privacy and mostly solve BREACH, CRIME, HEIST, CSRF, mime-confusion, JSON issues, etc. https://www.owasp.org/index.php/SameSite https://www.owasp.org/index.php/SameSite It wouldn't solve XSS or SQL injection, but native apps are just as vulnerable to SQL injection as html5 apps, so I'm not sure why the author brings that up. I'm curious what the author will propose as the solution.
• banku_brougham 9y ago
  I found the article convincing. Taking a step back to look at the big picture, does the current evolution of js, html and server technology seem to be headed somewhere great? Seems to me we will soon need large AI stacks just to assist in reading these jumbled stacks of code. I would have thought software would evolve toward simplicity by now.
  • dragonwriter 9y ago
    > Taking a step back to look at the big picture, does the current evolution of js, html and server technology seem to be headed sonewhere great? Yes. The current evolution of web app dev practices and popular frameworks doesn't, but that's a different thing.
• DiNovi 9y ago
  I don't know how many times I can read a "web apps are bad because the flux pattern is from 90's windows" articles