Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hashbang URIs Aren't as Bad as You Think

mtrpcic.net

Post reply on HN
Print view View original

41–46 of 46 posts

Re: Hashbang URIs Aren't as Bad as You Think

#41

Post by Isofarro »

jarin wrote: post #40
Isofarro wrote: post #39

Earlier quoted context omitted.

"If you want to curl a hashbang URL (or access its content in some other non-Javascript-requiring way), there's a pretty easy way to do it. Just do the same thing Google does and remove the hashbang." Which command line option on curl does that? (Maybe they haven't updated the man page? http://curl.haxx.se/docs/manpage.html ). Oh, if you reply, could you do it in the form of interpretative dance.

sed 's/#!\///g' urls.txt | xargs curl Yeah, not that hard dude.

> sed 's/#!\///g' urls.txt | xargs curl

So easy, you've actually got it wrong.

Certain special characters after the hash-bang need to be url-encoded, and then that value needs to be added to what's before the #! by including a query string parameter of _escaped_fragment_, checking first whether there is already a query string so as to append the information rather than incorrectly whacking on a '?'.

Plus, this isn't in the form of interpretive dance. So no content for you.

Re: Hashbang URIs Aren't as Bad as You Think

#42

Post by jarin »

Isofarro wrote: post #41
jarin wrote: post #40

Earlier quoted context omitted.

sed 's/#!\///g' urls.txt | xargs curl Yeah, not that hard dude.

> sed 's/#!\///g' urls.txt | xargs curl So easy, you've actually got it wrong. Certain special characters after the hash-bang need to be url-encoded, and then that value needs to be added to what's before the #! by including a query string parameter of _escaped_fragment_, checking first whether there is already a query string so as to append the information rather than incorrectly whacking on a '?'. Plus, this isn't…

Ok fine, so it will take 10 minutes to whip up and test a quick Ruby script instead of 30 seconds to think of the regular expression. I stand corrected.

Re: Hashbang URIs Aren't as Bad as You Think

#43

Post by farlington »

prodigal_erik wrote: post #29
farlington wrote: post #8

Hear hear. I can think of many cases where ajax loaded content and the attendant hashbang URLs are far preferable, like with twitter's web interface or with gmail. It just makes sense for web applications to work differently than static content, and persistent display of information often beats out clean looking URIs. Plus the whole anti-hashbang thing has a reactionary air to it.

"Web app" is a misnomer. If the content isn't browsable hypertext, it has abandoned the Web and stepped backwards into the ghetto of siloed client/server apps that were deservedly hated in the 90s. And the industry has yet to deliver a trustworthy js sandbox that can safely run any code it happens to find anywhere—the majority uses the defaults because they don't know how reckless those defaults are.

Thanks for this response, it's really thought provoking. I have a few questions:

'The ghetto of siloed client/server apps'? Would those be like ActiveX controls and Java applets? Isn't JavaScript fundamentally different?

Does the definition of 'browsable hypertext' preclude hypertext that's scripted to operate differently, e.g. 'ajax'? Are you not still 'browsing hypertext'?

The industry has yet to deliver a trustworthy js sandbox—should browsers not support JavaScript?

Re: Hashbang URIs Aren't as Bad as You Think

#45

Post by spjwebster »

jarin wrote: post #42
Isofarro wrote: post #41

Earlier quoted context omitted.

> sed 's/#!\///g' urls.txt | xargs curl So easy, you've actually got it wrong. Certain special characters after the hash-bang need to be url-encoded, and then that value needs to be added to what's before the #! by including a query string parameter of _escaped_fragment_, checking first whether there is already a query string so as to append the information rather than incorrectly whacking on a '?'. Plus, this isn't…

Ok fine, so it will take 10 minutes to whip up and test a quick Ruby script instead of 30 seconds to think of the regular expression. I stand corrected.

Now multiply that 10 minutes by number of scripts, utilities, libraries and applications in the world that handle URLs, and you'll be somewhere close to the magnitude of effort required to work around these broken URLs.

Re: Hashbang URIs Aren't as Bad as You Think

#46

Post by prodigal_erik »

farlington wrote: post #43
prodigal_erik wrote: post #29

Earlier quoted context omitted.

"Web app" is a misnomer. If the content isn't browsable hypertext, it has abandoned the Web and stepped backwards into the ghetto of siloed client/server apps that were deservedly hated in the 90s. And the industry has yet to deliver a trustworthy js sandbox that can safely run any code it happens to find anywhere—the majority uses the defaults because they don't know how reckless those defaults are.

Thanks for this response, it's really thought provoking. I have a few questions: 'The ghetto of siloed client/server apps'? Would those be like ActiveX controls and Java applets? Isn't JavaScript fundamentally different? Does the definition of 'browsable hypertext' preclude hypertext that's scripted to operate differently, e.g. 'ajax'? Are you not still 'browsing hypertext'? The industry has yet to deliver a trustwor…

By siloed I was referring to all the VB-style apps that predated widespread use of the Web. You had to use a single mediocre client app because it was the only piece of code in existence that could support the proprietary protocol for the matching server. Lock-in was rampant and building a better client or repurposing the data in any way was almost impossible.

Now we have servers that may technically still be talking XML or JSON or something over HTTP, but it might as well be an opaque proprietary protocol, because there's only one piece of code in existence (the javascript embedded in some page) that knows how to send meaningful requests to the server or decode its responses. The protocol isn't even stable enough to reverse-engineer because the author can make arbitrary changes to it and migrate everyone to an updated version of their client code at any moment. I find this vastly inferior to query strings, multipart/form-data, and scrapable semantic HTML, which a growing number of web devs completely neglect (none of whom I'd ever hire).

> should browsers not support JavaScript?

They shouldn't run it by default without asking whether the user trusts the author. Privacy violations are rampant and even malicious scripts have become a recurring problem. I don't see why a sandbox that works shouldn't be possible, but it hasn't happened yet.

Post reply on HN