7 ms·

I feel that dynamic websites are not websites, but applications. Even after this thorough research, I'd still be very wary of turning a primarily content-based

by compbio 11y ago

I feel that dynamic websites are not websites, but applications. Even after this thorough research, I'd still be very wary of turning a primarily content-based site into a dynamic app. A plain HTML site is accessible, and will be accessible in a 1000 years. A site depending on (external) JavaScript sources will force John Titor to travel back in time to find version 1.x of jQuery. Starting with JavaScript abandons principles of progressive enhancement. Sometimes there is not even a fallback/graceful degradation, reminding me of these 2001-era: "Best viewed at 800x600 resolution in Netscape"-sites. Google holds enormous clout among SEO's. Google says they will factor in site-speed and a large fraction of the web will become faster. Google can say more sternly that using JavaScript can have ugly consequences for user experience and accessibility, but they are swimming upstream: The web seems to be moving on to fancy new technologies regardless of what their SEO says. Not much good comes from HTML5 JavaScript fans forcing your hand. Tor enabled JavaScript, because too much of the web would break without it, leading to a poor user experience. This led to a huge security gaffe, which I fully blame on webdevelopers eschewing basic principles, to get that slideshow running.

deleted 11y ago
[deleted]
axx 11y ago
IMHO: Websites that don't have "realtime" content should always stick with traditional HTML. I'm a Webdeveloper myself and i don't like the JavaScript Frontend trend. Many Devs use Frontend JS in places where it's absolutely not needed. If you're building an App that updates in realtime, shows informations while it's created, i'm fine with Frontend JS, but it's an overkill for most content pages. Sure, it depends on your implementation details, but as i said, it's just my opinion.
- billybolero 11y ago
  I mostly agree, but at the same time, the rise of native apps has raised the bar of what people expect in terms of UX. Take Hacker News and Reddit, primarily content based sites and a good fit for the classic server rendered HTML approach. Still a lot of people prefer using native apps to access that content. You can only get so far by adding some CSS to make the site responsive, but you won't be anywhere near the UX that native gives you without JS. If we want the nice UX without relying too heavily on Javascript, there's a lot that has to change on the HTML/CSS side of things. And I don't see that happening at all. And let's not forget that you a) don't get accessibility for free just by rendering on the server and b) almost all screen readers today support Javascript.
  - marrs 11y ago
    But you can still progressively enhance with JS to achieve that nice UI, and often it will be more usable because it's built on a solid RESTful foundation that is close to browser behaviour and therefore user expectation. My experience with JS only apps is that they're often less usable, more brittle, and often don't work at all in IE
    - billybolero 11y ago
      Progressive enhancement work well for simple stuff. Like progressively enhancing a form post, or a "like" button which just sends an Ajax request. But as the complexity grows, progressive enhancement doesn't really scale and you end up with two separate versions of your site/app. I agree that Javascript only apps are often less usable, because the devs making them aren't testing enough on different browsers and devices. But the trend of the "Javascript only" approach is certainly driven by more than just frontend devs that want to use shiny new things (even if that is a factor as well).
      - arielb1 11y ago
        I still prefer just-HTML sites to the typical JS-based sites (e.g. the new Google Groups) I see.
      - 15155 11y ago
        > two separate versions of your site/app. It isn't 2010 anymore. React (just to name an example, there are many others) completely avoids this issue - you get serverside and clientside rendering out of the box.
        magicalist 11y ago
        You dropped the context of that quote. React isn't exactly a poster child of progressive enhancement.
        marrs 11y ago
- rimantas 11y ago
  I like Tantek's definition the best: "if it’s not curlable, it’s not on the web". http://tantek.com/2015/069/t1/js-dr-javascript-required-dead http://tantek.com/2015/069/t1/js-dr-javascript-required-dead
  - tomjen3 11y ago
    That just sounds like a passive-aggressive arbitrary rule change. For about 99% of the world the curability, or not, of the web doesn't matter at all. We already have a perfectly good web and includes things that are not curable, even if we exclude javascript (trivial example: you can't, meaningfully, curl a live sport event).
    - e12e 11y ago
      What do you mean, can't curl a live sport event? Do you mean you can't save it to disk (PVR), or if it's not audio/video, it's not useful to curl it and parse it for stats? If it is video, and you don't consider curl-as-pvr a valid use-case of curl'ing -- how about presenting the text-overlay as a text/html/rss-feed? Mix it at the client for those that want video, or show it as an RSS stream for text w/images? Not to mention that when we demand to have a functional js-parser and dom-tree just to get at the content, things like text-to-speech and many other things (including building a search-engine!) becomes much harder. For very little (I'd say no) gain.
riffraff 11y ago
For those that ignore it, John Titor[0] was a time traveler sent back in time to acquire some obsolete IBM machine which is needed in the future to debug some legacy code. [0] http://en.wikipedia.org/wiki/John_Titor http://en.wikipedia.org/wiki/John_Titor
- mdemare 11y ago
  You're probably not a native speaker of English, but of Latin. In Latin, `ignorare` can mean `not to know` in addition to its meaning of `not to pay attention to`, but in English, it only has the meaning of `not to pay attention to`. Vale.
  - madez 11y ago
    There are most probably no native speakers of Latin. Maybe you meant Spanish?
    - infinity 11y ago
      How about time travellers from the Imperium Romanum?
    - kaffeinecoma 11y ago
      I'm sure he meant speakers of Latin-derived languages. I see native French speakers make this mistake often in English.
      - madez 11y ago
        Thanks for this information.
  - riffraff 11y ago
    fair enough, assuming you mean "latin derived language" thanks!
    - mdemare 11y ago
BoxKeyboard 11y ago
> A plain HTML site is accessible, and will be accessible in a 1000 years. A site depending on (external) JavaScript sources will force John Titor to travel back in time to find version 1.x of jQuery. Not to sound completely apathetic, but so what? Most of us aren't building sites that we expect to be around in 10 years, much less 1000 years. The ephemeral nature of what we're building isn't lost on us - we're trading that guaranteed longevity for an improved development process (though some obviously disagree). Frequently, writing a traditional website with any sort of meaningful UI interactions was/is kind of a mess. Most of us don't write these applications (and you're right, they are applications) because we have any particular affinity for JavaScript, but because it makes the whole process much nicer. It still sucks, it's just nicer. Sure, progressive enhancement is a thing. And it's a great idea. In practice, top-down directives will probably be something akin to "Sure, do that, but do it on your own time and not at the expense of anything else." The realized benefits are very low (the % of users with JavaScript disabled is incredibly small), and saying something like "our site won't be accessible in 1000 years otherwise" is likely to get you mostly blank stares. It's a pretty big investment with very little benefit to most companies. Sure, 50 years down the road if these sites still exist they'll probably be nigh-unusable without some sort of "ES6 emulator mode", but so what? I don't think we'll go wanting for any historical artifacts from this time period. If we do, it'll be because future generations have no interest in our generation - not because we didn't produce enough relics.
- parasubvert 11y ago
  The arguable reason the web exploded in the first place were the architectural principles behind it were intentionally constrained to enable 50+ year sustainability and recombination for apps built within its architecture. This isn't so much about plain-jane HTML pages (useful as they are, since they have a simple interaction model than many understand and enjoy). It's more about using and exposing data in a visible manner (known formats and semantics) and hyperlinks rather than a single page app with opaque data. This gives you network effects. Think about the minor uproar over hash-bang URLs around 5 years ago, Twitter being the primary offender. That was single page application oriented rather than hyperlink orientation. There is a reason they've moved away from that. In the 90s, Google or Yahoo was just something students did with the links that were out there - that eventually generated hundreds of billions in value because of network effects and visbility of the information in HTML (Ie. They could apply algorithms to it like PageRank). The point of the web architecture is that it enables serendipity. Most anyone who has had massive success in business will explain the role of luck, serendipity, and network effects in their rise. Designing a web app for today's paycheck by closing it off behind a WebSocket+ JavaScript mess eliminates a proven avenue for network effects. Sometimes that might be OK, but it's unnecessarily limiting for many kinds of ventures.
userbinator 11y ago
I think the trend of "turning a primarily content-based site into a dynamic app", and indeed most of what has been referred to as "Web progress", "moving the Web forward", etc. comes from the desire of content producers to obtain and maintain more control over their content. Look at how browsers have evolved to de-emphasise features which give the user control while adding those that are author-targeted. We're moving from browsers being viewers for simple HTML documents (which can be copied, shared, and linked via simple means), to a platform for running complex applications written in JavaScript which often render data retrieved in proprietary formats from proprietary APIs. The "open by default" nature of plain HTML has become the "closed by default" of the data processed by web apps, much like with many native apps. Native app platforms (e.g. mobile) are also gradually becoming more "closed by default"; I'm not sure if that's a related trend. Google can say more sternly that using JavaScript can have ugly consequences for user experience and accessibility, but they are swimming upstream: The web seems to be moving on to fancy new technologies regardless of what their SEO says. Part of the reason is because Google themselves are doing this in many of their products... some of their employees probably disagree with "JS everything", but they're in the minority.
- debaserab2 11y ago
  At the end of the day whether or not the source data is in a proprietary format or not, it's being rendered into HTML in the case of web apps. The only difference is whether that happens on the client or server side. It's trivial to parse in either case. In fact I'd argue it's usually easier to dig up a JSON end point in the case of a web app which is far more parseable than HTML. I don't think we can point to this reason to explain the rise of web app's.
- matthewmacleod 11y ago
  I think the trend of "turning a primarily content-based site into a dynamic app", and indeed most of what has been referred to as "Web progress", "moving the Web forward", etc. comes from the desire of content producers to obtain and maintain more control over their content. Look at how browsers have evolved to de-emphasise features which give the user control while adding those that are author-targeted. I don't agree with this. Browsers are more user-targeted than ever. We're moving from browsers being viewers for simple HTML documents (which can be copied, shared, and linked via simple means) Browsers still allow this. to a platform for running complex applications written in JavaScript which often render data retrieved in proprietary formats from proprietary APIs. I have rarely seen a web API that uses anything other than straightforward JSON. The "open by default" nature of plain HTML has become the "closed by default" of the data processed by web apps Almost always equally as open as any HTML you would previously received. Native app platforms (e.g. mobile) are also gradually becoming more "closed by default"; I'm not sure if that's a related trend. What do you mean by this?
hrktb 11y ago
I think thisviewpoint is too limited. 20 years ago a webpage was just text, but it has evolved in so much more. I'd be ok with a data site rendering everything from a set of json files. There is more legitimacy in having the presentation done in static html. Same would go with sites mixing different information sources (twitter, rss etc). You can do the data fetching server side, but the user might prefer having it done client side for a reason or another (transparency for instance). These kind of sites woyld still be purely informative and yet having them heavily using js makes sense. I could think of many more situations were generating html from a different format on the client side is the right way to go. Horses for courses.
- romaniv 11y ago
  90% of everything served as JSON can be served as semantic HTML and then manipulated with roughly the same amount of code required to manipulate JSON. Yes, JSON navigation is "built in". However, HTML has incredibly powerful CSS queries which allow you to manipulate hierarchical data with minimal fuss.
  - tomjen3 11y ago
    CSS doesn't even have a way to select all h1 elements that contains a div with a date class so I strongly question the assertion that it has "extremely powerful CSS queries" (if you think you are about to prove me wrong with a one-liner, please re-read the phrasing).
    - romaniv 11y ago
      You did not provide an example of production-ready JSON query library for feature comparison.
  - hrktb 11y ago
    I understand that everything in json could also be represented in another format. But if your master data is in json, does it always make sense to convert the data to static html just for the sake of it ? Would you build a server component only for that conversion ? The answer to these question will depend on your priorities and use case, and the choice can easily be between no site or a js rendered site.
gwu78 11y ago
While I cannot speak for anyone else, I rarely ever use JavaScript and my "user experience" not at all "degraded". The browser I use, along with netcat, tcpclient, etc., does not even support JavaScript. The only exceptions are when sites force use of JavaScript. Curiously, often these are sites where money is involved, e.g., banks, merchants, etc. I guess JavaScript makes things safer in those cases? Then one of the popular high complexity (and high security of course) browsers becomes necessary. Perhaps it is because the type of content I consume is just reading material, listening material or viewing material. Each of which I can usually download and view with a dedicated application, if I so choose. I used to think JavaScript might become unavoidable for the user and I spent time thinking about how to accomodate it. I often pondered how search engines would cope with it as well. But over the years I have changed my mind; I do not spend any time worrying about JavaScript as a barrier to content. JavaScript can be a nuisance for non-interactive www usage but, at least in my experience, with some effort this impediment can be overcome. Whether the "user" is a nerd using nc or Googlebot. Do you think 1000 years from now there will still be one group of people working to make the www more "interactive" and another group of people working to make the www more "machine readable", the later undoing the work of the former?

by compbio 11y ago

deleted 11y ago

[deleted]

axx 11y ago

IMHO: Websites that don't have "realtime" content should always stick with traditional HTML. I'm a Webdeveloper myself and i don't like the JavaScript Frontend trend. Many Devs use Frontend JS in places where it's absolutely not needed. If you're building an App that updates in realtime, shows informations while it's created, i'm fine with Frontend JS, but it's an overkill for most content pages. Sure, it depends on your implementation details, but as i said, it's just my opinion.

billybolero 11y ago
I mostly agree, but at the same time, the rise of native apps has raised the bar of what people expect in terms of UX. Take Hacker News and Reddit, primarily content based sites and a good fit for the classic server rendered HTML approach. Still a lot of people prefer using native apps to access that content. You can only get so far by adding some CSS to make the site responsive, but you won't be anywhere near the UX that native gives you without JS. If we want the nice UX without relying too heavily on Javascript, there's a lot that has to change on the HTML/CSS side of things. And I don't see that happening at all. And let's not forget that you a) don't get accessibility for free just by rendering on the server and b) almost all screen readers today support Javascript.
- marrs 11y ago
  But you can still progressively enhance with JS to achieve that nice UI, and often it will be more usable because it's built on a solid RESTful foundation that is close to browser behaviour and therefore user expectation. My experience with JS only apps is that they're often less usable, more brittle, and often don't work at all in IE
  - billybolero 11y ago
    Progressive enhancement work well for simple stuff. Like progressively enhancing a form post, or a "like" button which just sends an Ajax request. But as the complexity grows, progressive enhancement doesn't really scale and you end up with two separate versions of your site/app. I agree that Javascript only apps are often less usable, because the devs making them aren't testing enough on different browsers and devices. But the trend of the "Javascript only" approach is certainly driven by more than just frontend devs that want to use shiny new things (even if that is a factor as well).
    - arielb1 11y ago
      I still prefer just-HTML sites to the typical JS-based sites (e.g. the new Google Groups) I see.
    - 15155 11y ago
      > two separate versions of your site/app. It isn't 2010 anymore. React (just to name an example, there are many others) completely avoids this issue - you get serverside and clientside rendering out of the box.
      - magicalist 11y ago
        You dropped the context of that quote. React isn't exactly a poster child of progressive enhancement.
        marrs 11y ago
rimantas 11y ago
I like Tantek's definition the best: "if it’s not curlable, it’s not on the web". http://tantek.com/2015/069/t1/js-dr-javascript-required-dead http://tantek.com/2015/069/t1/js-dr-javascript-required-dead
- tomjen3 11y ago
  That just sounds like a passive-aggressive arbitrary rule change. For about 99% of the world the curability, or not, of the web doesn't matter at all. We already have a perfectly good web and includes things that are not curable, even if we exclude javascript (trivial example: you can't, meaningfully, curl a live sport event).
  - e12e 11y ago
    What do you mean, can't curl a live sport event? Do you mean you can't save it to disk (PVR), or if it's not audio/video, it's not useful to curl it and parse it for stats? If it is video, and you don't consider curl-as-pvr a valid use-case of curl'ing -- how about presenting the text-overlay as a text/html/rss-feed? Mix it at the client for those that want video, or show it as an RSS stream for text w/images? Not to mention that when we demand to have a functional js-parser and dom-tree just to get at the content, things like text-to-speech and many other things (including building a search-engine!) becomes much harder. For very little (I'd say no) gain.

riffraff 11y ago

For those that ignore it, John Titor[0] was a time traveler sent back in time to acquire some obsolete IBM machine which is needed in the future to debug some legacy code. [0] http://en.wikipedia.org/wiki/John_Titor http://en.wikipedia.org/wiki/John_Titor

mdemare 11y ago
You're probably not a native speaker of English, but of Latin. In Latin, `ignorare` can mean `not to know` in addition to its meaning of `not to pay attention to`, but in English, it only has the meaning of `not to pay attention to`. Vale.
- madez 11y ago
  There are most probably no native speakers of Latin. Maybe you meant Spanish?
  - infinity 11y ago
    How about time travellers from the Imperium Romanum?
  - kaffeinecoma 11y ago
    I'm sure he meant speakers of Latin-derived languages. I see native French speakers make this mistake often in English.
    - madez 11y ago
      Thanks for this information.
- riffraff 11y ago
  fair enough, assuming you mean "latin derived language" thanks!
  - mdemare 11y ago

BoxKeyboard 11y ago

> A plain HTML site is accessible, and will be accessible in a 1000 years. A site depending on (external) JavaScript sources will force John Titor to travel back in time to find version 1.x of jQuery. Not to sound completely apathetic, but so what? Most of us aren't building sites that we expect to be around in 10 years, much less 1000 years. The ephemeral nature of what we're building isn't lost on us - we're trading that guaranteed longevity for an improved development process (though some obviously disagree). Frequently, writing a traditional website with any sort of meaningful UI interactions was/is kind of a mess. Most of us don't write these applications (and you're right, they are applications) because we have any particular affinity for JavaScript, but because it makes the whole process much nicer. It still sucks, it's just nicer. Sure, progressive enhancement is a thing. And it's a great idea. In practice, top-down directives will probably be something akin to "Sure, do that, but do it on your own time and not at the expense of anything else." The realized benefits are very low (the % of users with JavaScript disabled is incredibly small), and saying something like "our site won't be accessible in 1000 years otherwise" is likely to get you mostly blank stares. It's a pretty big investment with very little benefit to most companies. Sure, 50 years down the road if these sites still exist they'll probably be nigh-unusable without some sort of "ES6 emulator mode", but so what? I don't think we'll go wanting for any historical artifacts from this time period. If we do, it'll be because future generations have no interest in our generation - not because we didn't produce enough relics.

parasubvert 11y ago
The arguable reason the web exploded in the first place were the architectural principles behind it were intentionally constrained to enable 50+ year sustainability and recombination for apps built within its architecture. This isn't so much about plain-jane HTML pages (useful as they are, since they have a simple interaction model than many understand and enjoy). It's more about using and exposing data in a visible manner (known formats and semantics) and hyperlinks rather than a single page app with opaque data. This gives you network effects. Think about the minor uproar over hash-bang URLs around 5 years ago, Twitter being the primary offender. That was single page application oriented rather than hyperlink orientation. There is a reason they've moved away from that. In the 90s, Google or Yahoo was just something students did with the links that were out there - that eventually generated hundreds of billions in value because of network effects and visbility of the information in HTML (Ie. They could apply algorithms to it like PageRank). The point of the web architecture is that it enables serendipity. Most anyone who has had massive success in business will explain the role of luck, serendipity, and network effects in their rise. Designing a web app for today's paycheck by closing it off behind a WebSocket+ JavaScript mess eliminates a proven avenue for network effects. Sometimes that might be OK, but it's unnecessarily limiting for many kinds of ventures.

userbinator 11y ago

I think the trend of "turning a primarily content-based site into a dynamic app", and indeed most of what has been referred to as "Web progress", "moving the Web forward", etc. comes from the desire of content producers to obtain and maintain more control over their content. Look at how browsers have evolved to de-emphasise features which give the user control while adding those that are author-targeted. We're moving from browsers being viewers for simple HTML documents (which can be copied, shared, and linked via simple means), to a platform for running complex applications written in JavaScript which often render data retrieved in proprietary formats from proprietary APIs. The "open by default" nature of plain HTML has become the "closed by default" of the data processed by web apps, much like with many native apps. Native app platforms (e.g. mobile) are also gradually becoming more "closed by default"; I'm not sure if that's a related trend. Google can say more sternly that using JavaScript can have ugly consequences for user experience and accessibility, but they are swimming upstream: The web seems to be moving on to fancy new technologies regardless of what their SEO says. Part of the reason is because Google themselves are doing this in many of their products... some of their employees probably disagree with "JS everything", but they're in the minority.

debaserab2 11y ago
At the end of the day whether or not the source data is in a proprietary format or not, it's being rendered into HTML in the case of web apps. The only difference is whether that happens on the client or server side. It's trivial to parse in either case. In fact I'd argue it's usually easier to dig up a JSON end point in the case of a web app which is far more parseable than HTML. I don't think we can point to this reason to explain the rise of web app's.
matthewmacleod 11y ago
I think the trend of "turning a primarily content-based site into a dynamic app", and indeed most of what has been referred to as "Web progress", "moving the Web forward", etc. comes from the desire of content producers to obtain and maintain more control over their content. Look at how browsers have evolved to de-emphasise features which give the user control while adding those that are author-targeted. I don't agree with this. Browsers are more user-targeted than ever. We're moving from browsers being viewers for simple HTML documents (which can be copied, shared, and linked via simple means) Browsers still allow this. to a platform for running complex applications written in JavaScript which often render data retrieved in proprietary formats from proprietary APIs. I have rarely seen a web API that uses anything other than straightforward JSON. The "open by default" nature of plain HTML has become the "closed by default" of the data processed by web apps Almost always equally as open as any HTML you would previously received. Native app platforms (e.g. mobile) are also gradually becoming more "closed by default"; I'm not sure if that's a related trend. What do you mean by this?

hrktb 11y ago

I think thisviewpoint is too limited. 20 years ago a webpage was just text, but it has evolved in so much more. I'd be ok with a data site rendering everything from a set of json files. There is more legitimacy in having the presentation done in static html. Same would go with sites mixing different information sources (twitter, rss etc). You can do the data fetching server side, but the user might prefer having it done client side for a reason or another (transparency for instance). These kind of sites woyld still be purely informative and yet having them heavily using js makes sense. I could think of many more situations were generating html from a different format on the client side is the right way to go. Horses for courses.

romaniv 11y ago
90% of everything served as JSON can be served as semantic HTML and then manipulated with roughly the same amount of code required to manipulate JSON. Yes, JSON navigation is "built in". However, HTML has incredibly powerful CSS queries which allow you to manipulate hierarchical data with minimal fuss.
- tomjen3 11y ago
  CSS doesn't even have a way to select all h1 elements that contains a div with a date class so I strongly question the assertion that it has "extremely powerful CSS queries" (if you think you are about to prove me wrong with a one-liner, please re-read the phrasing).
  - romaniv 11y ago
    You did not provide an example of production-ready JSON query library for feature comparison.
- hrktb 11y ago
  I understand that everything in json could also be represented in another format. But if your master data is in json, does it always make sense to convert the data to static html just for the sake of it ? Would you build a server component only for that conversion ? The answer to these question will depend on your priorities and use case, and the choice can easily be between no site or a js rendered site.

gwu78 11y ago

While I cannot speak for anyone else, I rarely ever use JavaScript and my "user experience" not at all "degraded". The browser I use, along with netcat, tcpclient, etc., does not even support JavaScript. The only exceptions are when sites force use of JavaScript. Curiously, often these are sites where money is involved, e.g., banks, merchants, etc. I guess JavaScript makes things safer in those cases? Then one of the popular high complexity (and high security of course) browsers becomes necessary. Perhaps it is because the type of content I consume is just reading material, listening material or viewing material. Each of which I can usually download and view with a dedicated application, if I so choose. I used to think JavaScript might become unavoidable for the user and I spent time thinking about how to accomodate it. I often pondered how search engines would cope with it as well. But over the years I have changed my mind; I do not spend any time worrying about JavaScript as a barrier to content. JavaScript can be a nuisance for non-interactive www usage but, at least in my experience, with some effort this impediment can be overcome. Whether the "user" is a nerd using nc or Googlebot. Do you think 1000 years from now there will still be one group of people working to make the www more "interactive" and another group of people working to make the www more "machine readable", the later undoing the work of the former?