4 ms·

I agree you're getting the most accessibility by making a blog that renders on the server. But rendering front ends with javascript shouldn't be considered brea

I agree you're getting the most accessibility by making a blog that renders on the server. But rendering front ends with javascript shouldn't be considered breaking the web. It's a tool that's available in the browser, and many use it to try and make a better experience for their overall users. I think it's a shame we have the "first load no content" problem, but developers are doing this with good intentions. Making UIs respond faster, reducing back & forth network requests, and trying to make more interactive content on the web. There are some warts we need to sort out and get better at, but I still see it as progress.

zeveb 10y ago
> But rendering front ends with javascript shouldn't be considered breaking the web. If it doesn't work without JavaScript, it's breaking the web. I have absolutely no problem with progressive enhancement. I have absolutely no problem with choosing to enable JavaScript when it makes sense. I have a problem with requiring a privacy-destroying technology in order to consume content.
pdkl95 10y ago
> rendering front ends with javascript shouldn't be considered breaking the web. If you want to serve an empty, broken page as a first impression, you can. I strongly recommend against it because it makes your site look half-finished, poorly designed, and generally unprofessional. > available in the browser That isn't always true. You don't know anything about the browser a priori. > make a better experience Of course. Javascript can add nice features, which is why you progressively enhance the page to add features when the underlying requirements are available. Do you skip the check for NULL when calling fopen(1)? Checking for errors is always important. On the web, this means you should gracefully handle problems like missing javascript (intentionally or otherwise) or other resources. > Making UIs respond faster Requiring two additional HTTP requests (one to load javascript, and another to load the actual page content) isn't making the page faster. After the first request your javascript will be available most of the time for partial loads in any case. > interactive content That is rarely a good idea, but it's your page so do what you want. Progressive enhancement doesn't affect this at all.
- random_rr 10y ago
  Do you develop, professionally, for the web?
- agmcleod 10y ago
  I think you and I are talking about the same thing. I was more responding to the extreme circumstances the other person posted. I agree that when you're making public facing content, it should render on the server. The faster UIs is true when you don't have to do full page reloads to load new content, but just grab serialized data from the web server instead.

zeveb 10y ago

> But rendering front ends with javascript shouldn't be considered breaking the web. If it doesn't work without JavaScript, it's breaking the web. I have absolutely no problem with progressive enhancement. I have absolutely no problem with choosing to enable JavaScript when it makes sense. I have a problem with requiring a privacy-destroying technology in order to consume content.

pdkl95 10y ago

> rendering front ends with javascript shouldn't be considered breaking the web. If you want to serve an empty, broken page as a first impression, you can. I strongly recommend against it because it makes your site look half-finished, poorly designed, and generally unprofessional. > available in the browser That isn't always true. You don't know anything about the browser a priori. > make a better experience Of course. Javascript can add nice features, which is why you progressively enhance the page to add features when the underlying requirements are available. Do you skip the check for NULL when calling fopen(1)? Checking for errors is always important. On the web, this means you should gracefully handle problems like missing javascript (intentionally or otherwise) or other resources. > Making UIs respond faster Requiring two additional HTTP requests (one to load javascript, and another to load the actual page content) isn't making the page faster. After the first request your javascript will be available most of the time for partial loads in any case. > interactive content That is rarely a good idea, but it's your page so do what you want. Progressive enhancement doesn't affect this at all.

random_rr 10y ago
Do you develop, professionally, for the web?
agmcleod 10y ago
I think you and I are talking about the same thing. I was more responding to the extreme circumstances the other person posted. I agree that when you're making public facing content, it should render on the server. The faster UIs is true when you don't have to do full page reloads to load new content, but just grab serialized data from the web server instead.