4 ms·

I agree that things like blogger are a great example of what not to do, but I'd go further and say that treating something as a single page web app running on t

I agree that things like blogger are a great example of what not to do, but I'd go further and say that treating something as a single page web app running on the client side throws away most of the advantages of the web: URLs which can be stored and shared and are idempotent Mostly stateless operation for anonymous use (fast to serve/load/cache) Document formats that anything (including dumb crawlers and future gadgets) can parse and reuse in unexpected ways What you call suboptimal browsing devices are what makes the web special and distinct from native apps. These are not trivial advantages, and most websites would benefit from these strengths of the web, even if they are an app. As an example of where something like a single page app can shine on a public site, I've seen chat software which used it which worked really well (using socket.io I think), but only because people didn't care about sharing individual messages and the chat was ephemeral.

davedx 13y ago
> URLs which can be stored and shared and are idempotent If you use a decent router, you get shareable idempotent URLs: https://solvers.io/projects/7GTeCKo7rGx5FsGkB https://solvers.io/projects/7GTeCKo7rGx5FsGkB > Document formats that anything (including dumb crawlers and future gadgets) can parse and reuse in unexpected ways As in the article, you can use phantomjs to serve up static HTML to crawlers. They are correct in that it does slow you down and add complexity. The main problem I think is that SPA tech is still immature and getting all the moving parts to build a public facing SPA working together is a time sink.
- grey-area 13y ago
  It's not really a single page application if you are serving separate pages is it? BTW, the page you linked to says 'Uh-oh! Couldn't find that page.' before loading and displaying the content... ouch. One of the things I love about the web is that it uses incredibly simple building blocks like simple html pages at defined stateless URLs, dumb servers and dumber clients, and builds complex systems through their interaction. I'd be very wary of solutions that drop those advantages. There are certainly technical solutions possibly to almost any problem with angular or client-side apps in general, but I'm not sure that rendering everything client-side really gives you enough advantages to warrant it for many websites. What do you see as the main advantages to this approach and do you see it spreading everywhere eventually? Every website is different and what suits (say) a chat application will not suit a document-orientated website at all. There's certainly room to explore both approaches or even mix them at times.
  - discreteevent 13y ago
    " I'd be very wary of solutions that drop those advantages." They are called native applications. I can think of some useful ones over the years, particularly for people who produce rather than consume. I notice that my Bosch drill isn't available for seo and mashing :) Seriously though, it depends on your perspective. What's wrong with saying I'd like to make a native app but use the web as a delivery/installation mechanism and that's all?
    - grey-area 13y ago
      Nothing really, there's room for all approaches to be explored. I suspect the concept of native APIs (desktop or mobile) will eventually disappear, but it'll be an interesting journey if we ever do reach that point and would take decades.
    - blueskin_ 13y ago
      There's a difference. Photoshop wouldn't work as a website, and HN wouldn't work as a program. Different forms for different use cases.
      - iopq 13y ago
        Photoshop wouldn't work as a website? http://pixlr.com/editor/ http://pixlr.com/editor/
  - sanderjd 13y ago
    You make some really good points, but I think simple json documents are much simpler and easier to re-use by other clients in interesting ways than simple html pages. I think the API + client (note, not just traditional web browser) rendering is actually a more "pure" interpretation of what the web can be - data sources and data consumers that interpret and present that data on behalf of their users. I'm also not sure that rendering everything client-side is advantageous enough to warrant its current popularity (hype...), but I do see some advantages. Firstly, I think it is a better separation of concerns - the server is in charge of data discovery, persistence, consistency, and aggregation, while the client is in charge of determining how that data can be most useful in the current context. In practice, this means it is possible to have different front-ends for the same back-end. Admittedly, that is certainly not always a necessary or desired feature. The separation also makes it easier to build the front end and back end of an application separately from one another, and possibly even in whichever order you prefer. That can be a good thing, though I don't think it's really taken advantage of very often. I also think that true web applications can be made to feel much snappier and closer to native. The line between what should and shouldn't be considered an "application" is unfortunately blurry (the Blogger example is a good one).
- deleted 13y ago
  [deleted]
- suprfsat 13y ago
  Well that's super. https://solvers.io/projects/7GTeCKo7rGx5FsGkB?_escaped_fragment_= https://solvers.io/projects/7GTeCKo7rGx5FsGkB?_escaped_fragm... takes 15 seconds to load and still doesn't contain any readable content.
dchuk 13y ago
I think the term "Single Page App" is a bit deceiving in usage sometimes. My idea of a SPA is one where the client downloads the bulk of the application code on first page load, and then only talks to the server with data-based API calls (JSON usually). The predownloaded client then just renders that data, rather than downloading an entire new template to render on the whole screen. This interface style does not require any visual page refreshes to load new content, but it also still can support routing and deep-linking.

davedx 13y ago

> URLs which can be stored and shared and are idempotent If you use a decent router, you get shareable idempotent URLs: https://solvers.io/projects/7GTeCKo7rGx5FsGkB https://solvers.io/projects/7GTeCKo7rGx5FsGkB > Document formats that anything (including dumb crawlers and future gadgets) can parse and reuse in unexpected ways As in the article, you can use phantomjs to serve up static HTML to crawlers. They are correct in that it does slow you down and add complexity. The main problem I think is that SPA tech is still immature and getting all the moving parts to build a public facing SPA working together is a time sink.

grey-area 13y ago
It's not really a single page application if you are serving separate pages is it? BTW, the page you linked to says 'Uh-oh! Couldn't find that page.' before loading and displaying the content... ouch. One of the things I love about the web is that it uses incredibly simple building blocks like simple html pages at defined stateless URLs, dumb servers and dumber clients, and builds complex systems through their interaction. I'd be very wary of solutions that drop those advantages. There are certainly technical solutions possibly to almost any problem with angular or client-side apps in general, but I'm not sure that rendering everything client-side really gives you enough advantages to warrant it for many websites. What do you see as the main advantages to this approach and do you see it spreading everywhere eventually? Every website is different and what suits (say) a chat application will not suit a document-orientated website at all. There's certainly room to explore both approaches or even mix them at times.
- discreteevent 13y ago
  " I'd be very wary of solutions that drop those advantages." They are called native applications. I can think of some useful ones over the years, particularly for people who produce rather than consume. I notice that my Bosch drill isn't available for seo and mashing :) Seriously though, it depends on your perspective. What's wrong with saying I'd like to make a native app but use the web as a delivery/installation mechanism and that's all?
  - grey-area 13y ago
    Nothing really, there's room for all approaches to be explored. I suspect the concept of native APIs (desktop or mobile) will eventually disappear, but it'll be an interesting journey if we ever do reach that point and would take decades.
  - blueskin_ 13y ago
    There's a difference. Photoshop wouldn't work as a website, and HN wouldn't work as a program. Different forms for different use cases.
    - iopq 13y ago
      Photoshop wouldn't work as a website? http://pixlr.com/editor/ http://pixlr.com/editor/
- sanderjd 13y ago
  You make some really good points, but I think simple json documents are much simpler and easier to re-use by other clients in interesting ways than simple html pages. I think the API + client (note, not just traditional web browser) rendering is actually a more "pure" interpretation of what the web can be - data sources and data consumers that interpret and present that data on behalf of their users. I'm also not sure that rendering everything client-side is advantageous enough to warrant its current popularity (hype...), but I do see some advantages. Firstly, I think it is a better separation of concerns - the server is in charge of data discovery, persistence, consistency, and aggregation, while the client is in charge of determining how that data can be most useful in the current context. In practice, this means it is possible to have different front-ends for the same back-end. Admittedly, that is certainly not always a necessary or desired feature. The separation also makes it easier to build the front end and back end of an application separately from one another, and possibly even in whichever order you prefer. That can be a good thing, though I don't think it's really taken advantage of very often. I also think that true web applications can be made to feel much snappier and closer to native. The line between what should and shouldn't be considered an "application" is unfortunately blurry (the Blogger example is a good one).
deleted 13y ago
[deleted]
suprfsat 13y ago
Well that's super. https://solvers.io/projects/7GTeCKo7rGx5FsGkB?_escaped_fragment_= https://solvers.io/projects/7GTeCKo7rGx5FsGkB?_escaped_fragm... takes 15 seconds to load and still doesn't contain any readable content.

dchuk 13y ago

I think the term "Single Page App" is a bit deceiving in usage sometimes. My idea of a SPA is one where the client downloads the bulk of the application code on first page load, and then only talks to the server with data-based API calls (JSON usually). The predownloaded client then just renders that data, rather than downloading an entire new template to render on the whole screen. This interface style does not require any visual page refreshes to load new content, but it also still can support routing and deep-linking.