5 ms·

> I feel like JS is an expected part of the web just like HTML and CSS. How can you build engaging web applications if you are not even allowed to rely on stand

by zeveb 10y ago

> I feel like JS is an expected part of the web just like HTML and CSS. How can you build engaging web applications if you are not even allowed to rely on standards like JS (e.g. if the user turns off JS)? The web is not about 'engaging web applications'; the web is about webs of interlinked documents. Every time you require JavaScript to display a simple document; every time you load images with JavaScript instead of <img>; every time you replace an <a href=> link with a JavaScript event handler; every time you fail to even link to a page; every time you use JavaScript-loaded fonts to display symbols: you break the web. 'Web application' is a misnomer: it should be 'browser application.' Despite my loathing for documents (e.g. blogs, articles &c.) which require code execution in order to be read, I don't mind browser apps where they make sense. Google Maps makes sense: it doesn't bother me that it doesn't work in eww, or links, or with NoScript. Blogger doesn't make sense: there's absolutely no legitimate reason for it to show an empty page with JavaScript turned off: Blogger is breaking the web. imgurl's failure to show all images, and Cracked's failure to show any images, without JavaScript makes no sense: they are breaking the web. People who break the web should be deeply ashamed.

agmcleod 10y ago
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.
NobleLie 10y ago
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.
mynameislegion 10y ago
> the web is about webs of interlinked documents If this is true, and my browser can follow a link to a Blogger page, displaying the intended document using universal browser features, then the Web is not broken. This kind of evangelism makes no sense. The whole idea that "the Web is about documents, specifically" was shattered as soon as Javascript was added over two decades ago. It's no longer about that idea and hasn't been for a long time. Interlinked resources, yes, and documents became a subset of that idea in 1995. The desire for document-type content to display without JS stems from a strange desire to see the technology used how it was invented in 1990. The Web was hodge-podge of technology then, and it's even more so now. If you intend to pick and choose what parts of the hodge-podge to use, you will find yourself frustrated forever. And you gain no advantage by arguing "but I want the _original_ hodge-podge to work with the type of content it was design for!". JS _is_ the Web just as much as HTML because all (Edit: popular) browsers support it. As soon as that happened, compatibility with the Original Hodge-Podge was dead, permanently. For better or worse, that is the reality.
- detaro 10y ago
  It also comes from a desire to use tools that are not browsers on the web. To archive, to search, to display them nicely when sharing them, ...
  - mynameislegion 10y ago
    I agree. Before the prevalence of JS you could simply download the text. But now, much of the text interpreted. So if you wish to get all the text, you must also do the interpretation step. Which essentially means running a headless browser to pipe it to you. And it's simply not practical to tell your text sources to avoid using so much interpreted text. They're using Web standards.
- zeveb 10y ago
  > If this is true, and my browser can follow a link to a Blogger page, displaying the intended document using universal browser features, then the Web is not broken. Your second premise doesn't hold for all browsers: links cannot display Blogger pages; Firefox with NoScript cannot display Blogger pages; the Tor Browser with high security cannot display Blogger pages. The Web is, fundamentally, about resources — documents — and their state, not about behaviour. > JS _is_ the Web just as much as HTML because all browsers support it. No. They. Don't. eww doesn't. w3m doesn't. lynx doesn't. links doesn't. elinks doesn't. Firefox with NoScript doesn't. The Tor Browser with high security doesn't. That is the reality. The reality is also that allowing JavaScript exposes users to severe privacy and security threats. Disabling JavaScript is the only way to control those threats. Every site which requires JavaScript to function is like a serpent tempting a user into giving up his privacy and security. That is the reality.
viewer5 10y ago
I just wanted to say this is a really fascinating comment, and it's given me a lot to think about. It's an interesting perspective that I haven't run across before.

by zeveb 10y ago

agmcleod 10y ago

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.

NobleLie 10y ago

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.

mynameislegion 10y ago

> the web is about webs of interlinked documents If this is true, and my browser can follow a link to a Blogger page, displaying the intended document using universal browser features, then the Web is not broken. This kind of evangelism makes no sense. The whole idea that "the Web is about documents, specifically" was shattered as soon as Javascript was added over two decades ago. It's no longer about that idea and hasn't been for a long time. Interlinked resources, yes, and documents became a subset of that idea in 1995. The desire for document-type content to display without JS stems from a strange desire to see the technology used how it was invented in 1990. The Web was hodge-podge of technology then, and it's even more so now. If you intend to pick and choose what parts of the hodge-podge to use, you will find yourself frustrated forever. And you gain no advantage by arguing "but I want the _original_ hodge-podge to work with the type of content it was design for!". JS _is_ the Web just as much as HTML because all (Edit: popular) browsers support it. As soon as that happened, compatibility with the Original Hodge-Podge was dead, permanently. For better or worse, that is the reality.

detaro 10y ago
It also comes from a desire to use tools that are not browsers on the web. To archive, to search, to display them nicely when sharing them, ...
- mynameislegion 10y ago
  I agree. Before the prevalence of JS you could simply download the text. But now, much of the text interpreted. So if you wish to get all the text, you must also do the interpretation step. Which essentially means running a headless browser to pipe it to you. And it's simply not practical to tell your text sources to avoid using so much interpreted text. They're using Web standards.
zeveb 10y ago
> If this is true, and my browser can follow a link to a Blogger page, displaying the intended document using universal browser features, then the Web is not broken. Your second premise doesn't hold for all browsers: links cannot display Blogger pages; Firefox with NoScript cannot display Blogger pages; the Tor Browser with high security cannot display Blogger pages. The Web is, fundamentally, about resources — documents — and their state, not about behaviour. > JS _is_ the Web just as much as HTML because all browsers support it. No. They. Don't. eww doesn't. w3m doesn't. lynx doesn't. links doesn't. elinks doesn't. Firefox with NoScript doesn't. The Tor Browser with high security doesn't. That is the reality. The reality is also that allowing JavaScript exposes users to severe privacy and security threats. Disabling JavaScript is the only way to control those threats. Every site which requires JavaScript to function is like a serpent tempting a user into giving up his privacy and security. That is the reality.

viewer5 10y ago

I just wanted to say this is a really fascinating comment, and it's given me a lot to think about. It's an interesting perspective that I haven't run across before.