2 ms·

Great comment, but what type of interactions do you have in mind are just easier to do with SPA and would not be possible or would be on the spaghetti side to i

Great comment, but what type of interactions do you have in mind are just easier to do with SPA and would not be possible or would be on the spaghetti side to implement with JavaScript sprinkles? Basically at what point down the line (with some possible examples) would you say that we are at a stage where there is too much complexity to handle the page with 'manual' dom manipulation?

raihansaputra 6y ago
I think it depends on the kind of app/interactivity that you want. Hotwire/BC/HEY shows that it's possible to build apps, but the downside is at the latency for the interactions (the DOM response time depends on server location). This also applies for Phoenix LiveView/Intercooler/HTMX/etc. With the current state of that stack, I feel it's not strictly about interactivity anymore. It's more of the feature set. Do you need the app to still be interactive/functional when offline or on spotty connections? Do you already have an extensive codebase with REST API? Of course the interactivity level can be a consideration, but the limit of HTML responses on that side gets bumped up.
- bestinterest 6y ago
  Yes latency can be a killer but I have see a few tricks with sending the request for pages on hover which seem like a really smart idea but not bulletproof compared to dealing with it client side. With offline point I believe the complexity in offline apps must be crazy if you have a SPA, you now have 3 states to manage. The backend, the frontend and now also the frontend's IndexedDB. It doesn't help when I've not seen any great example of offline first apps work that well. And I'll be selfish from a business point of view that the development effort and technical complexity may not be worth the cost for 90% of cases. But agreed on if you have an existing REST API, I think another advantage of it is that is can help separate concerns and allow for front end devs and backend devs to be separate. But I really think that it is a crazy amount of complexity if you are not a huge corp. Interactivity levels is where I'm missing the piece of the puzzle, show me a picture of a user interface that would fall apart with SSR + the new Hotwire is going to be the only way I can truly appreciate when to use SPA frameworks.
  - raihansaputra 6y ago
    Yeah. The trick to managing the offline states is to have it as cache. So updating and solely relying on the server, and only serve when offline. On the interactivity side, I feel that a lot of tools that I use daily justifies the use of SPA/PWA. Definitely can be passable with HTML SSR, but there's not much examples of it yet. Todoist: No hassle offline handling. It will sync on it's own. Twitter: They do intercept everything and handle/queue requests when the client is offline. It's not perfect though. Roam: Again. Offline syncing, mainly offline search/document creation. This is a bit unique though as I think the server basically is just a sync logic. I feel that the SPA stage is definitely a growing phase instead of a destination to be. There's a lot of problems that are not solved elegantly yet, and it's and the boundaries. But I feel that SPA and all of it's learnings will be an example of how the next step will be like. And with .wasm coming, there's a lot of possibility of different architectures/how to build apps. Some talks that refers to why/how SPA makes sense for some problems/usecases: Offline first PWA/Web App, with CRDT for syncing: https://www.youtube.com/watch?v=DEcwa68f-jY https://www.youtube.com/watch?v=DEcwa68f-jY (James Long's CRDT For Mortals talk) State management framework oriented for offline/PWA use: https://read.reduxbook.com/ https://read.reduxbook.com/

raihansaputra 6y ago

I think it depends on the kind of app/interactivity that you want. Hotwire/BC/HEY shows that it's possible to build apps, but the downside is at the latency for the interactions (the DOM response time depends on server location). This also applies for Phoenix LiveView/Intercooler/HTMX/etc. With the current state of that stack, I feel it's not strictly about interactivity anymore. It's more of the feature set. Do you need the app to still be interactive/functional when offline or on spotty connections? Do you already have an extensive codebase with REST API? Of course the interactivity level can be a consideration, but the limit of HTML responses on that side gets bumped up.

bestinterest 6y ago
Yes latency can be a killer but I have see a few tricks with sending the request for pages on hover which seem like a really smart idea but not bulletproof compared to dealing with it client side. With offline point I believe the complexity in offline apps must be crazy if you have a SPA, you now have 3 states to manage. The backend, the frontend and now also the frontend's IndexedDB. It doesn't help when I've not seen any great example of offline first apps work that well. And I'll be selfish from a business point of view that the development effort and technical complexity may not be worth the cost for 90% of cases. But agreed on if you have an existing REST API, I think another advantage of it is that is can help separate concerns and allow for front end devs and backend devs to be separate. But I really think that it is a crazy amount of complexity if you are not a huge corp. Interactivity levels is where I'm missing the piece of the puzzle, show me a picture of a user interface that would fall apart with SSR + the new Hotwire is going to be the only way I can truly appreciate when to use SPA frameworks.
- raihansaputra 6y ago
  Yeah. The trick to managing the offline states is to have it as cache. So updating and solely relying on the server, and only serve when offline. On the interactivity side, I feel that a lot of tools that I use daily justifies the use of SPA/PWA. Definitely can be passable with HTML SSR, but there's not much examples of it yet. Todoist: No hassle offline handling. It will sync on it's own. Twitter: They do intercept everything and handle/queue requests when the client is offline. It's not perfect though. Roam: Again. Offline syncing, mainly offline search/document creation. This is a bit unique though as I think the server basically is just a sync logic. I feel that the SPA stage is definitely a growing phase instead of a destination to be. There's a lot of problems that are not solved elegantly yet, and it's and the boundaries. But I feel that SPA and all of it's learnings will be an example of how the next step will be like. And with .wasm coming, there's a lot of possibility of different architectures/how to build apps. Some talks that refers to why/how SPA makes sense for some problems/usecases: Offline first PWA/Web App, with CRDT for syncing: https://www.youtube.com/watch?v=DEcwa68f-jY https://www.youtube.com/watch?v=DEcwa68f-jY (James Long's CRDT For Mortals talk) State management framework oriented for offline/PWA use: https://read.reduxbook.com/ https://read.reduxbook.com/