6 ms·

Single-page apps became a thing because of lack of development resources to build native apps or properly engineer server side solutions (as well as a business

Single-page apps became a thing because of lack of development resources to build native apps or properly engineer server side solutions (as well as a business desire to centralize and lock down the product so people have to experience ads, pay subscriptions...). It has nothing to do with creating a user friendly experience. 100% of the time a user would benefit from a native app or properly engineered server-side rendered web page over a SPA.

JumpCrisscross 7y ago
> 100% of the time a user would benefit from a native app I strongly prefer single-page web apps over native apps. Web apps are constrained by my browser. Native apps get a lot more trust.
- AnIdiotOnTheNet 7y ago
  That's a problem we should have fixed on the platform side long ago, but didn't. Now we're stuck with the garbage fire of the modern web. That doesn't make it better.
syntheticcdo 7y ago
> 100% of the time Nothing in software engineering is absolute. And even if something were to be 100% the correct solution one day, the next it could change.
ScottFree 7y ago
I agree, but there is one problem: most people would rather use an SPA than have to download an app and have to keep it up to date themselves. I wonder if there's a market for an alternative "browser" that loads "native" code (or as close as practically possible) and runs it in a sandbox.
- eitland 7y ago
  > I wonder if there's a market for an alternative "browser" that loads "native" code (or as close as practically possible) and runs it in a sandbox. Electron comes close, but many don’t like it at all. (I have somewhat mixed experiences, I love VS Code but I’m not too fond of Slack.)
  - ScottFree 7y ago
    Electron isn't native in any sense of the word. I meant something more like OS-specific binary executables that get loaded and executed in a sandbox. Mike Acton once said something about having created a browser plugin his team used that loaded and ran binary exe tools on demand, but that it was also wildly insecure. At least I think he said something like that. My memory could be wrong about that.
  - icedchai 7y ago
    We had this 20 years ago with Java (not native obviously) and ActiveX (Windows x86 only.)
- favorited 7y ago
  > most people would rather use an SPA than have to download an app and have to keep it up to date themselves Citation?
  - ScottFree 7y ago
    > Citation? No.
- mftrhu 7y ago
  > I wonder if there's a market for an alternative "browser" that loads "native" code (or as close as practically possible) and runs it in a sandbox. This is probably not what you had in mind, and I'm not sure how good it would be at sandboxing, but REBOL Reblets imho come close to this <http://www.rebol.com/reblets.html> http://www.rebol.com/reblets.html>
  - greggirwin 7y ago
    The question is what "browser" means. If viewing data connected by hyperlinks is the goal, that's pretty easy. Rebol's approach to X-Net (Executable Internet) apps is very different, with the goal of being a way to share both data and active content. You can do both, the web we know just wasn't designed for that.
- hn_throwaway_99 7y ago
  Hah, you mean Java applets? Everything old is new again.
  - ScottFree 7y ago
    I meant something more like OS-specific binary executables that get loaded and executed in a sandbox.
hombre_fatal 7y ago
I have uBlock Origin on my browser. I can even change the font-size on a web page if I need to. A native app can be doing anything it wants without my knowledge, and I can't even change the font-size. Native apps have a performance benefit at the expense of everything we take for granted on the web, like being able to open up a developer console and inspect it. For example, I noticed that the top language translation app on the Mac App Store incurs a Google Analytics request for every keystroke. And since there's no easy network tab I can open on any app, I only found it out because I was curious how it worked and mitm'd it with a proxy. And I couldn't just toss uBlock Origin at it to de-trackify it like I can any web app. Doesn't seem like a 100% epic win for users to me. In fact, the only upside I can even think of is that it probably uses less RAM than a Chrome tab opened to Google Translate. Let's slow down and acknowledge the trade-offs before we go all-in on HN memes like native app superiority.
RussianCow 7y ago
> It has nothing to do with creating a user friendly experience. This is absolutely not true. Think about any kind of dynamic dashboard or data management platform. Having full page reloads for any minor change to filters, etc, is simply an unacceptable UX. But it has to be web-based because you need to be able to access it from any device, anywhere, without installing an app. Plus, on a personal level, there are many services for which I will never install a native app—because I don't use it often, or because the native app provides no added benefit, or for one of a hundred other reasons. Those services don't get my business if they don't have a web app.
- dredmorbius 7y ago
  That is a significant, but limited-use, case. Theere's no reason a static contnt page must require JS Simply to render text, with a blank page as fallback. Better ways of addressing the dashboaard example might be worth considering. Too: bullshit dashboards with JS-based fakery; https://www.theverge.com/2016/11/8/13571216/new-york-times-election-forecast-jitter-needle https://www.theverge.com/2016/11/8/13571216/new-york-times-e...
  - RussianCow 7y ago
    Limited? That describes about half the applications I've built in my career! In all seriousness, there is a big difference between static content pages and full-blown applications; the cost to make the latter work properly without JS enabled is almost never worth it. But the same is true even for some static pages; for instance, I would never expect that NY times election forecast page to work without JavaScript, and don't see any reason that it should. (The "JS-based fakery" is pretty irrelevant to the discussion, IMO.)
    - dredmorbius 7y ago
      What fraction of all HTML pageloads? And: Sampling bias. A simple static page shouldn't require development. Hence, anyone doing web dev will have experience skewed strongly to more complex designs. How would you describe the basic underlying structure and mechanics of a typical app you've built?

JumpCrisscross 7y ago

> 100% of the time a user would benefit from a native app I strongly prefer single-page web apps over native apps. Web apps are constrained by my browser. Native apps get a lot more trust.

AnIdiotOnTheNet 7y ago
That's a problem we should have fixed on the platform side long ago, but didn't. Now we're stuck with the garbage fire of the modern web. That doesn't make it better.

syntheticcdo 7y ago

> 100% of the time Nothing in software engineering is absolute. And even if something were to be 100% the correct solution one day, the next it could change.

ScottFree 7y ago

I agree, but there is one problem: most people would rather use an SPA than have to download an app and have to keep it up to date themselves. I wonder if there's a market for an alternative "browser" that loads "native" code (or as close as practically possible) and runs it in a sandbox.

eitland 7y ago
> I wonder if there's a market for an alternative "browser" that loads "native" code (or as close as practically possible) and runs it in a sandbox. Electron comes close, but many don’t like it at all. (I have somewhat mixed experiences, I love VS Code but I’m not too fond of Slack.)
- ScottFree 7y ago
  Electron isn't native in any sense of the word. I meant something more like OS-specific binary executables that get loaded and executed in a sandbox. Mike Acton once said something about having created a browser plugin his team used that loaded and ran binary exe tools on demand, but that it was also wildly insecure. At least I think he said something like that. My memory could be wrong about that.
- icedchai 7y ago
  We had this 20 years ago with Java (not native obviously) and ActiveX (Windows x86 only.)
favorited 7y ago
> most people would rather use an SPA than have to download an app and have to keep it up to date themselves Citation?
- ScottFree 7y ago
  > Citation? No.
mftrhu 7y ago
> I wonder if there's a market for an alternative "browser" that loads "native" code (or as close as practically possible) and runs it in a sandbox. This is probably not what you had in mind, and I'm not sure how good it would be at sandboxing, but REBOL Reblets imho come close to this <http://www.rebol.com/reblets.html> http://www.rebol.com/reblets.html>
- greggirwin 7y ago
  The question is what "browser" means. If viewing data connected by hyperlinks is the goal, that's pretty easy. Rebol's approach to X-Net (Executable Internet) apps is very different, with the goal of being a way to share both data and active content. You can do both, the web we know just wasn't designed for that.
hn_throwaway_99 7y ago
Hah, you mean Java applets? Everything old is new again.
- ScottFree 7y ago
  I meant something more like OS-specific binary executables that get loaded and executed in a sandbox.

hombre_fatal 7y ago

I have uBlock Origin on my browser. I can even change the font-size on a web page if I need to. A native app can be doing anything it wants without my knowledge, and I can't even change the font-size. Native apps have a performance benefit at the expense of everything we take for granted on the web, like being able to open up a developer console and inspect it. For example, I noticed that the top language translation app on the Mac App Store incurs a Google Analytics request for every keystroke. And since there's no easy network tab I can open on any app, I only found it out because I was curious how it worked and mitm'd it with a proxy. And I couldn't just toss uBlock Origin at it to de-trackify it like I can any web app. Doesn't seem like a 100% epic win for users to me. In fact, the only upside I can even think of is that it probably uses less RAM than a Chrome tab opened to Google Translate. Let's slow down and acknowledge the trade-offs before we go all-in on HN memes like native app superiority.

RussianCow 7y ago

> It has nothing to do with creating a user friendly experience. This is absolutely not true. Think about any kind of dynamic dashboard or data management platform. Having full page reloads for any minor change to filters, etc, is simply an unacceptable UX. But it has to be web-based because you need to be able to access it from any device, anywhere, without installing an app. Plus, on a personal level, there are many services for which I will never install a native app—because I don't use it often, or because the native app provides no added benefit, or for one of a hundred other reasons. Those services don't get my business if they don't have a web app.

dredmorbius 7y ago
That is a significant, but limited-use, case. Theere's no reason a static contnt page must require JS Simply to render text, with a blank page as fallback. Better ways of addressing the dashboaard example might be worth considering. Too: bullshit dashboards with JS-based fakery; https://www.theverge.com/2016/11/8/13571216/new-york-times-election-forecast-jitter-needle https://www.theverge.com/2016/11/8/13571216/new-york-times-e...
- RussianCow 7y ago
  Limited? That describes about half the applications I've built in my career! In all seriousness, there is a big difference between static content pages and full-blown applications; the cost to make the latter work properly without JS enabled is almost never worth it. But the same is true even for some static pages; for instance, I would never expect that NY times election forecast page to work without JavaScript, and don't see any reason that it should. (The "JS-based fakery" is pretty irrelevant to the discussion, IMO.)
  - dredmorbius 7y ago
    What fraction of all HTML pageloads? And: Sampling bias. A simple static page shouldn't require development. Hence, anyone doing web dev will have experience skewed strongly to more complex designs. How would you describe the basic underlying structure and mechanics of a typical app you've built?