1. 19
  1.  

  2. 12

    TLDR: The answer is “it depends” but I don’t see this as a war. In so many cases you need web and native.

    The two themes of the article:

    1 Native is better than web at being native

    2 If people will want your product on their home screen, build an app. Otherwise build a website.

    How is this even a war to win or lose? Native IS better on mobile devices at being native but you probably can’t choose between web and native. Your users are often going to be on both their phones and their desktops which means web apps too. Often the real choice is: which first?

    I use the native Trello, GMail, Freshbooks (ugh), Cal, Keep apps on my phone and I use the web versions of each on my desktop. Not one has a particularly web-like UI on web and all are extremely valuable to me. How are any of those not “complex, app-like structures?” They also each work very well together because they are web. I can link to a Google Doc in a Trello ticket and vice versa with no new app specific behaviors to learn.

    Is modern FE app development constructed with hacks upon hacks? Sure. But some work very, very well. Should we rethink how some of our products for the web designed and developed and perhaps not rush into Blogs written in Angular? Of course! But I won’t concede defeat of the greatest computing platform ever to the current computing oligarchy of Apple and Google and I don’t think anyone else needs to either.

    1. 4

      I like this answer.

      There’s no war, only people pinning their identities on dumb things like platforms. History shows us that there have always been platform fragmentation. I don’t see this trend reversing itself, no matter how much time, money, committees, and blind faith we dump into any platform.

      It’d be nice if there was just one platform, but there usually isn’t. That’s fine; the interesting parts of computation are rarely in the platform-specific details. I don’t know why everyone gets so hung up on them when they change drastically every 5 years.

      1. 3

        Thanks. Agreed, and it’s been bizarre not seeing this perspective more prominently.

        1. 1

          There are some very popular new apps that have no desktop client whatsoever, like SnapChat and WhatsApp.

          1. 1

            Instagram was the most popular example. Some apps are certainly best mobile only but for many others its really mobile first.

            1. 2

              I tried the Instagram website on mobile just then and it is a bit rubbish. It asks if you want to open the app first. When you are viewing a photo there is no swiping left or right to other photos.

        2. 12

          One issue is Native looks and feels Web. Looking straight at the text editor Atom. It uses a lot of web hacks (Almost all of the web is just one giant hack IMHO) and feels slow and laggy. It is also more resource hungry than it should.

          1. 17

            As a counter-example, Visual Studio Code is built on the same framework as Atom (Electron, formerly Atom Shell) yet performs quite well even on large files.

            My personal theory is that GitHub just lacks expertise in building editors/IDEs, and that a company with that expertise won’t be inhibited by using web technologies.

            1. 3

              See also GitHub Gui (Oh no he didn’t!). I’m actually a fan of it on Windows and Mac, but by golly it does have some hairbrained behaviour :) A classic example is not being able to edit text at all, so if I want to edit one line I have to go back to the IDE first. That then triggers an “auto refresh” in GitHub gui when I switch back to it which may change my current commit slightly so you have to then check your commit again before confirming it. On a similar note you can’t revert a single line easily, you have to commit all the lines you actually did want first, and then revert the file.

          2. 8

            I don’t know how to define it very well, but there are a lot of applications that I never want to use as a “web app.” My experience is that web apps are terrible at handling complicated tasks or complicated user interfaces.

            One rough guidelines is that anything I use to edit or create “stuff” I would rather be a native app. Things like text editing, photo editing, document creation/editing, coding, 3D modeling/CAD, just don’t work well as web apps because the problem domains are too complicated and there’s a mismatch between the UI elements required and the UI elements available on web pages.

            1. 2

              I’m sure there are some people that use a web based text editor/IDE and a tablet with keyboard. Of course you then have to ask at what point a tablet turns into a laptop.

              1. 5

                I’m sure people do it, but I’m skeptical those people wouldn’t be significantly more productive using a regular editor like Emacs or Vim, or even something like TextPad.

                1. 2

                  I’m 110% sure there are also web versions of Emacs and Vim too :) I’ve no idea what the experience would be like though.

                  1. 2

                    I’ve never seen a web based editor with a fraction of the capabilities of Emacs or Vim. Even trying simple development work like running make and jumping to compilation errors is enough to demonstrate most web based editors aren’t very good.

                    1. 2

                      I was thinking of someone using a javascript port of Emacs or Vim and then just using it for web development. I have used some online C/C++ “IDE"s, the compilation then happens server side. For 20 lines test programs they are pretty good, many of them even have saving and sharing and I think one even had collaborative editing. Obviously this is a big step from "compiling Linux kernel” or even just “compiling and running tuxkart”, but for small projects especially web development it is theoretically possible to switch. Personally I can’t wait to be able to go web only for every application, but as you point out it just isn’t doable for many tasks/projects.

            2. 3

              I was wondering recently how well received would be a portal made strictly sticking to the initial intention of the web.

              • normal links
              • minimal use of javascript, preferably none
              • full page reloads / simple forms for adding content
              • optimized for reading

              Roughly an old CRUD app + some more modern HTML5 tags, CSS & a tiny bit of javascript for stuff like form validation.

              Would it stand a chance against the SPA apps for email, aggregation sites (reddit, hn, lobste.rs)? Yeah, some of them are even at that level currently.

              Would it stand a chance against apps like google docs? Probably no.

              The question is how much we want the web to move that way. It’s becoming a runtime/virtual machine for applications - not a document viewer. The abstractions are leaking and all implementations take a hit because of that (backwards compatibility vs new requirements).

              1. 1

                The web is really good at the document viewer case. It’s terrible for apps.

                Right now, we write web apps by sheer force of will + millions of dollars of infrastructure funding while never asking ourselves “why is it so hard?”.

                I’d much rather see an entirely new standard emerge that uses HTTP for distribution/updates and the browser as a VM. These new apps would load into the browser much like existing web apps, perhaps with URLs, but they wouldn’t use HTML/CSS/JS.

                1. 2

                  I’d much rather see an entirely new standard emerge that uses HTTP for distribution/updates and the browser as a VM. These new apps would load into the browser much like existing web apps, perhaps with URLs, but they wouldn’t use HTML/CSS/JS.

                  We are not very far from what you describe. With libraries like React or Mithril, you don’t use HTML anymore. The library manipulates the DOM directly. Some users of React don’t use CSS anymore. They manage styling directly in JavaScript. And even JavaScript can be replaced. Some people use it only as a compilation target (look at Elm for example). And you can even get rid of the DOM and draw to a canvas (like Flipboard).