4 ms·

Oops, I expected vanilla web development to mean server-rendered HTML with forms. Thanks for making me feel old.

by mark_and_sweep 6y ago

throw_m239339 6y ago
and Perl CGI. That's all a developer needs!
- gumby 6y ago
  I have written (internal) production CGI in bash.
morrvs 6y ago
Sorry :D nothing wrong with server-rendered HTML and forms for many use cases. Unfortunately, by the limits of connectivity, if you want to build something that is interactive, data-driven, and responsive at the same time you will always be forced to render on the client-side at some point.
- falcolas 6y ago
  > if you want to build something that is interactive, data-driven, and responsive at the same time you will always be forced to render on the client-side I'm not sure I personally agree with this blanket statement. Connection times can be, for a vast majority of users, measured in tens of milliseconds, giving us a pretty good budget for processing and rendering while still appearing to be "instantaneous" (100ms) or "fluid" (1s). Even the worst case connection times (satellite & mobile) are still measurable using hundreds of milliseconds. The worst ranked countries still average in excess of 1.5 Mbps transmission rates - more than enough for compressed text. And, given how unresponsive so many "top 100" SSA pages are (such as blogs that take whole seconds to display their initial content), I can't agree that doing that processing on the server would actually be less interactive or responsive. Even the test application from this article can load from scratch in under a second, most of that time being the DNS resolution and the server processing for serving the page.
  - ktpsns 6y ago
    This is so true. If you want to feel again what's possible, make a vanilla website (without JS and with very few images) and do all form processing server side. You will be astonished how fast and actually reactive this side can feel. Part of this feeling could be that animations (thinking of the popular material design by Google) itself take 10ms to 100ms. Within this duration, the browser can easily load a new page.
  - morrvs 6y ago
    I'm not an expert but I'm certain we aren't even close to providing this level of connectivity. Throttled data, sucky hotel wi-fi, underground tunnels, bad service in rural areas of e.g. Germany etc. are real, unfortunately. You cannot hope to get enough uptime and guaranteed response time ranges for an app's interactions from any server; you will always get inferior UX to client-side rendering (which, in a way, has 100% uptime and guaranteed response times only bound by CPU/RAM/bugs in your code).
    - falcolas 6y ago
      It’s moderately ironic to talk about poor connections (largely due to cell phone situations) without discussing the lackluster processing, memory, and battery life available on those cell phones. Not to mention the fact that SPAs tend to be significantly more heavyweight in their initial download requirements than server-powered forms, taxing those poor connections before you even see a single line of text. Again, the performance bar for SPAs has been set so low by top-100 sites (like Medium and other SPA blogs) that a server powered forms would have to work very hard to be worse. As a side note, we can’t forget that even these “100% uptime” SPAs in the real world largely still rely on requests and responses from a server backend; still rely on prompt responses to their ‘XMLHttpRequest’ calls (hello, animated spinners!).
      - morrvs 6y ago
        True, we should respect all the resources of a device, at best. Also true for desktop (Slack's memory usage comes to mind). A major result of the study is greatly reduced bandwidth (and consequently, shorter parse time) compared to the original TeuxDeux, so I'm working towards respecting these resources, for what it's worth. To be clear, the study does not care about doing SPAs or not. The results are applicable to server-rendered HTML as well (write a function that enable some behavior on an element, mount by class name, done). I agree that many use cases (e.g. blogs) should mostly be server-rendered and only progressively enhanced with JS for some UX improvements. But highly interactive apps (drag & drop just being one example) will not have comparable UX without client-side rendering. I do not want a 100-1000ms delay (or an error message) after dropping an item in some list because of a server-roundtrip. This is not good UX. Also, when filling out a form, I do not want to lose data or context when clicking submit while I'm in a tunnel. I'd rather have a client-side rendered UI that keeps my context and tells me "Sorry, try again when you're connected again". Even better if it works fully offline and syncs the transactions I've done with a backend once I'm connected again.

Oops, I expected vanilla web development to mean server-rendered HTML with forms. Thanks for making me feel old.

throw_m239339 6y ago

and Perl CGI. That's all a developer needs!

gumby 6y ago
I have written (internal) production CGI in bash.

morrvs 6y ago

Sorry :D nothing wrong with server-rendered HTML and forms for many use cases. Unfortunately, by the limits of connectivity, if you want to build something that is interactive, data-driven, and responsive at the same time you will always be forced to render on the client-side at some point.

falcolas 6y ago
> if you want to build something that is interactive, data-driven, and responsive at the same time you will always be forced to render on the client-side I'm not sure I personally agree with this blanket statement. Connection times can be, for a vast majority of users, measured in tens of milliseconds, giving us a pretty good budget for processing and rendering while still appearing to be "instantaneous" (100ms) or "fluid" (1s). Even the worst case connection times (satellite & mobile) are still measurable using hundreds of milliseconds. The worst ranked countries still average in excess of 1.5 Mbps transmission rates - more than enough for compressed text. And, given how unresponsive so many "top 100" SSA pages are (such as blogs that take whole seconds to display their initial content), I can't agree that doing that processing on the server would actually be less interactive or responsive. Even the test application from this article can load from scratch in under a second, most of that time being the DNS resolution and the server processing for serving the page.
- ktpsns 6y ago
  This is so true. If you want to feel again what's possible, make a vanilla website (without JS and with very few images) and do all form processing server side. You will be astonished how fast and actually reactive this side can feel. Part of this feeling could be that animations (thinking of the popular material design by Google) itself take 10ms to 100ms. Within this duration, the browser can easily load a new page.
- morrvs 6y ago
  I'm not an expert but I'm certain we aren't even close to providing this level of connectivity. Throttled data, sucky hotel wi-fi, underground tunnels, bad service in rural areas of e.g. Germany etc. are real, unfortunately. You cannot hope to get enough uptime and guaranteed response time ranges for an app's interactions from any server; you will always get inferior UX to client-side rendering (which, in a way, has 100% uptime and guaranteed response times only bound by CPU/RAM/bugs in your code).
  - falcolas 6y ago
    It’s moderately ironic to talk about poor connections (largely due to cell phone situations) without discussing the lackluster processing, memory, and battery life available on those cell phones. Not to mention the fact that SPAs tend to be significantly more heavyweight in their initial download requirements than server-powered forms, taxing those poor connections before you even see a single line of text. Again, the performance bar for SPAs has been set so low by top-100 sites (like Medium and other SPA blogs) that a server powered forms would have to work very hard to be worse. As a side note, we can’t forget that even these “100% uptime” SPAs in the real world largely still rely on requests and responses from a server backend; still rely on prompt responses to their ‘XMLHttpRequest’ calls (hello, animated spinners!).
    - morrvs 6y ago
      True, we should respect all the resources of a device, at best. Also true for desktop (Slack's memory usage comes to mind). A major result of the study is greatly reduced bandwidth (and consequently, shorter parse time) compared to the original TeuxDeux, so I'm working towards respecting these resources, for what it's worth. To be clear, the study does not care about doing SPAs or not. The results are applicable to server-rendered HTML as well (write a function that enable some behavior on an element, mount by class name, done). I agree that many use cases (e.g. blogs) should mostly be server-rendered and only progressively enhanced with JS for some UX improvements. But highly interactive apps (drag & drop just being one example) will not have comparable UX without client-side rendering. I do not want a 100-1000ms delay (or an error message) after dropping an item in some list because of a server-roundtrip. This is not good UX. Also, when filling out a form, I do not want to lose data or context when clicking submit while I'm in a tunnel. I'd rather have a client-side rendered UI that keeps my context and tells me "Sorry, try again when you're connected again". Even better if it works fully offline and syncs the transactions I've done with a backend once I'm connected again.