3 ms·

I agree on some points, yet I believe the author exaggerates during most of his article. PushState, for example, is not a bandaid, and for those not-so-modern

by ewolf 14y ago

I agree on some points, yet I believe the author exaggerates during most of his article. PushState, for example, is not a bandaid, and for those not-so-modern browsers there are hashtags (let's be frank: 99.9% of users don't care about how beautiful or ugly their URIs are and even less about one particular character). In many cases such as WYSIWYG editors, which he mentions, Javascript is the only way (HN users might prefer Markdown, but for most average users, that's already too complicated). New HTML5 input types are awesome, but they are in this case the advanced fragile technologies that currently lack a broad support base. I particularly disagree on the last two points: These days, Javascript and CSS is minified, sprites are used on basically all popular sites and content is gzipped. Many people even use a CDN for their JS frameworks. Loading time optimization is a topic more important than ever before. The same goes for mobile versions: I see a lot of people even offering a mobile-optimized version of their portfolio. He is certainly right saying that these aspects are all very important, but I don't really see the lack thereof in practice. Any examples, perhaps?

tokenizer 14y ago
I think the author is missing out on what you mentioned, specifically that we're attempting to bridge the gap between size and complexity, and new and stable. As someone who is constantly not using the features I'm learning about due to IE7/8, I mess with things that definitely won't work on anything other than Chrome Canary. Why? Because it's a fun and brave new frontier. I really think you can't complain about the web being NOT perfect. It's full of dinosaurs and people are still running on oil. And besides, this newfangled green revolution has a ton of kinks we need to take care of before we can make the switch. Transitional. The web is in a state of flux always.
tambourine_man 14y ago
Hashtags are indeed a bandaid, URIs aesthetics being the least of its problems. But PushState is great. I think some clarification is needed from the author to support this claim.
johnbender 14y ago
> PushState, for example, is not a bandaid, and for those not-so-modern browsers there are hashtags (let's be frank: 99.9% of users don't care about how beautiful or ugly their URIs are and even less about one particular character). Keep in mind that using the history API (push|replace)State is not so much about making the URL pretty as it is about page refresh semantics. With a hashtag the page refresh loading the correct content requires at least one more trip to the server to load the content represented by the hash and relies completely on your JavaScript not breaking. With a url "fixed" by (push|replace)State the server can respond directly with the content speeding up the response time and removing a point of failure.
- deleted 14y ago
  [deleted]
- WiseWeasel 14y ago
  Can the server be set up so pushed states can work with any arbitrary path, as you can do with hashtag addresses? Can you get the same level of flexibility in handling bad URLs? I'm still struggling with getting PushState working, since I implemented hash routing as a slash-delimited query rather than a reflection of any actual directory structure on the server, (I.e. domain.com/#category/group/item loads an item, with various graceful fallbacks if it's not found, such as loading the group instead, or suggesting items that do exist). If I can avoid a 404 in most cases, I think the user will be happier. I'm not sure if I can get the same level of flexibility with PushState.
  - marcusf 14y ago
    The server has nothing to do, pe se, with pushState. That just manipulates the client. If on reload/next visit, you don't want the link to break (which seems like a reasonable requirement), just set up a route in whatever web server you're running that maps to the url schema you're generating in the client.
    - WiseWeasel 14y ago
      Any thoughts on avoiding generic 404s in case of typo or removed content, in the hope of returning something more useful? Can we use context info from the URL given to personalize the 404 response, or maybe route to a different resource instead for certain contexts? This all seems so simple with client-side hash routing. [Also, would that mean that I would need to maintain a list of every single possible route in the whole site?]
gambler 14y ago
PushState, for example, is not a bandaid In the sense of overall web architecture, it is a bandaid. You're using an imperative language to change the state of the page, and then you're using imperative language to fake moving from one page to the next. If you want the whole things to be crawlable, you also need to have extra code that generates the new "page" as if it wasn't a result of client-side manipulations. Did you ever ask yourself what would it take to go the opposite way and efficiently represent client-state changes by page navigation? Not that much, especially which proper technologies built into the browser. In many cases such as WYSIWYG editors, which he mentions, Javascript is the only way There is nothing wrong with using WYSIWYG editors written in JavaScript. However, they shouldn't interfere with standard functionality, such as spell-checking. It wouldn't hurt if such a popular control was built into browsers either, rather then re-implemented hundreds of times. I particularly disagree on the last two points: These days, Javascript and CSS is minified, sprites are used on basically all popular sites and content is gzipped. That doesn't stop people from writing inefficient JS code or simply loading too much stuff. Open this with FireBug, for example: http://www.smashingmagazine.com/ http://www.smashingmagazine.com/ . That is one of the leading websites on webdesign. What is there to expect from corporate pages and various product (i.e. movie or game) websites? Try browsing on Kindle (not Fire) to see which websites really are efficient and which ones aren't.

by ewolf 14y ago

tokenizer 14y ago

I think the author is missing out on what you mentioned, specifically that we're attempting to bridge the gap between size and complexity, and new and stable. As someone who is constantly not using the features I'm learning about due to IE7/8, I mess with things that definitely won't work on anything other than Chrome Canary. Why? Because it's a fun and brave new frontier. I really think you can't complain about the web being NOT perfect. It's full of dinosaurs and people are still running on oil. And besides, this newfangled green revolution has a ton of kinks we need to take care of before we can make the switch. Transitional. The web is in a state of flux always.

tambourine_man 14y ago

Hashtags are indeed a bandaid, URIs aesthetics being the least of its problems. But PushState is great. I think some clarification is needed from the author to support this claim.

johnbender 14y ago

> PushState, for example, is not a bandaid, and for those not-so-modern browsers there are hashtags (let's be frank: 99.9% of users don't care about how beautiful or ugly their URIs are and even less about one particular character). Keep in mind that using the history API (push|replace)State is not so much about making the URL pretty as it is about page refresh semantics. With a hashtag the page refresh loading the correct content requires at least one more trip to the server to load the content represented by the hash and relies completely on your JavaScript not breaking. With a url "fixed" by (push|replace)State the server can respond directly with the content speeding up the response time and removing a point of failure.

deleted 14y ago
[deleted]
WiseWeasel 14y ago
Can the server be set up so pushed states can work with any arbitrary path, as you can do with hashtag addresses? Can you get the same level of flexibility in handling bad URLs? I'm still struggling with getting PushState working, since I implemented hash routing as a slash-delimited query rather than a reflection of any actual directory structure on the server, (I.e. domain.com/#category/group/item loads an item, with various graceful fallbacks if it's not found, such as loading the group instead, or suggesting items that do exist). If I can avoid a 404 in most cases, I think the user will be happier. I'm not sure if I can get the same level of flexibility with PushState.
- marcusf 14y ago
  The server has nothing to do, pe se, with pushState. That just manipulates the client. If on reload/next visit, you don't want the link to break (which seems like a reasonable requirement), just set up a route in whatever web server you're running that maps to the url schema you're generating in the client.
  - WiseWeasel 14y ago
    Any thoughts on avoiding generic 404s in case of typo or removed content, in the hope of returning something more useful? Can we use context info from the URL given to personalize the 404 response, or maybe route to a different resource instead for certain contexts? This all seems so simple with client-side hash routing. [Also, would that mean that I would need to maintain a list of every single possible route in the whole site?]

gambler 14y ago

PushState, for example, is not a bandaid In the sense of overall web architecture, it is a bandaid. You're using an imperative language to change the state of the page, and then you're using imperative language to fake moving from one page to the next. If you want the whole things to be crawlable, you also need to have extra code that generates the new "page" as if it wasn't a result of client-side manipulations. Did you ever ask yourself what would it take to go the opposite way and efficiently represent client-state changes by page navigation? Not that much, especially which proper technologies built into the browser. In many cases such as WYSIWYG editors, which he mentions, Javascript is the only way There is nothing wrong with using WYSIWYG editors written in JavaScript. However, they shouldn't interfere with standard functionality, such as spell-checking. It wouldn't hurt if such a popular control was built into browsers either, rather then re-implemented hundreds of times. I particularly disagree on the last two points: These days, Javascript and CSS is minified, sprites are used on basically all popular sites and content is gzipped. That doesn't stop people from writing inefficient JS code or simply loading too much stuff. Open this with FireBug, for example: http://www.smashingmagazine.com/ http://www.smashingmagazine.com/ . That is one of the leading websites on webdesign. What is there to expect from corporate pages and various product (i.e. movie or game) websites? Try browsing on Kindle (not Fire) to see which websites really are efficient and which ones aren't.