3 ms·

I agree with your distinction between browser application and the web. Its very frustrating to be bombarded with tons of javascript that introduce nothing of v

I agree with your distinction between browser application and the web. Its very frustrating to be bombarded with tons of javascript that introduce nothing of value; usually advertisements and petty fanciness. But that being said, ive been developing a heavy javascript SPA ( Single Page Application ) and have been writing javascript that is going to be very useful to (certain types of) users. Im more than happy to download a large bundle of javascript (and css) if im getting an application (and preferably not on my phone) And in defense of SPA's which dont even have web in them, good ones are a portal to a location on the web (a model type and id) loaded usually via json with html re-rendered on the client. And even better ones have history implemented. So they can feel very like the web...given js is enabled(!) But of course I understand the "why reimplement what browsers already offer?" SPA's feel almost indistinguishable from a desktop app if done right... What are your opinions on SPAs?

zeveb 10y ago
> What are your opinions on SPAs? I think that some of them make sense, but many many many would be better implemented as RESTful apps instead. Once the REST layer is written and works without JavaScript, implementing an enhanced version which requires JavaScript and minimises redownloading of new data is relatively easy. Imagine a chat app. The pure-HTML version could serve a chat message at /chats/{partner}/{message-id}, with a prev link to the previous chat; it could serve a chat sequence at /chats/{partner}/{message-id}?history={length}; it could redirect /chats/{partner} to the most recent message in a sequence. A form could easily enable POSTing a new message to the chat. Once all that's done, it's dead-easy to write some JavaScript which ties it together in a single-page app. Instead of requesting each message as text/json, the JavaScript client could accept application/json (or another format, if you like). It could subscribe to a WebSocket or server events. It could do anything — but the basic HTML-based app would still work, and be usable from a command line, from a simple phone, from anywhere.

zeveb 10y ago

> What are your opinions on SPAs? I think that some of them make sense, but many many many would be better implemented as RESTful apps instead. Once the REST layer is written and works without JavaScript, implementing an enhanced version which requires JavaScript and minimises redownloading of new data is relatively easy. Imagine a chat app. The pure-HTML version could serve a chat message at /chats/{partner}/{message-id}, with a prev link to the previous chat; it could serve a chat sequence at /chats/{partner}/{message-id}?history={length}; it could redirect /chats/{partner} to the most recent message in a sequence. A form could easily enable POSTing a new message to the chat. Once all that's done, it's dead-easy to write some JavaScript which ties it together in a single-page app. Instead of requesting each message as text/json, the JavaScript client could accept application/json (or another format, if you like). It could subscribe to a WebSocket or server events. It could do anything — but the basic HTML-based app would still work, and be usable from a command line, from a simple phone, from anywhere.