A problem I have with JS web apps, is that "cool URIs don't change" [1]. While querystrings are a server-side convention, the ability to convert a server-side site into JS without having to rewrite all the old URLs is much more important to me than inventing new URL schemes just for JS apps...
Why JavaScript web applications should embrace traditional URLs
21–30 of 45 posts
Re: Why JavaScript web applications should embrace traditional URLs
#22Re: Why JavaScript web applications should embrace traditional URLs
#23Earlier quoted context omitted.
I'm on a Mac, I don't have a middle mouse button.
Cmd-click. On a Macbook trackpad or magic mouse you can also set three-finger tap to middle click (with third-party tweaks like BetterTouchTool).
> On a Macbook trackpad or magic mouse you can also set three-finger tap to middle click (with third-party tweaks like BetterTouchTool).
Ick. I hate doing two-finger taps as it is. I don't believe one should need anything other than a pointing device with one button to browse the web effectively. Needing to hack in ways to simulate extra buttons is bad design. Why not use a keyboard then?
Re: Why JavaScript web applications should embrace traditional URLs
#24Earlier quoted context omitted.
Cmd-click. On a Macbook trackpad or magic mouse you can also set three-finger tap to middle click (with third-party tweaks like BetterTouchTool).
> On a Macbook trackpad or magic mouse you can also set three-finger tap to middle click (with third-party tweaks like BetterTouchTool). Ick. I hate doing two-finger taps as it is. I don't believe one should need anything other than a pointing device with one button to browse the web effectively. Needing to hack in ways to simulate extra buttons is bad design. Why not use a keyboard then?
No, people not using target="_blank" is bad design. It's not Chrome's fault people can't code external links right.
Re: Why JavaScript web applications should embrace traditional URLs
#25Earlier quoted context omitted.
The thing is that it has to work cross-browser. If an IE user copies an URL with both a fragment query string and a real query string and then shares it with a Firefox user, the URL should resolve to the same thing (and the same thing the other way around). Not impossible by any means, but, as Jeremy points out, it involves subtle details :)
Right-o. PushState-supporting users copying URLs and sending them to IE8 and IE9 folks is one thing, as is the opposite direction. In addition, some folks currently like to mount their Backbone.js applications at a root URL that contains a query string, for example: todolist.com/app?org=nsa#location
> some folks currently like to mount their Backbone.js applications at a root URL that contains a query string
That seems like the root of the problem. It seems like querystrings could otherwise be solved, but this case would certainly introduce a problem for pushState-incompatible browsers.
Is there a reason this kind of app root URL isn't considered bad practice that doesn't need to be supported? Everything about it seems wrong - now you're trying to put part of the path after the querystring.
Re: Why JavaScript web applications should embrace traditional URLs
#26This is the third or fourth post I've seen lately on "use the architeture of the web, don't fight it with client-side JS apps." I consider it a welcome swing of the pendulum.
Re: Why JavaScript web applications should embrace traditional URLs
#27Earlier quoted context omitted.
I don't understand at all what you mean. To open pages in a new tab you middle click the link. Pages that automatically open in new tab are annoying. If Chrome has something that stops this, I'm extremely happy. The user should control whether a page opens in a new tab or not, and indeed the user can do that -- left click or middle click.
I'm on a Mac, I don't have a middle mouse button.
I think you can drag the link up to the tab bar, and it will open in a new tab.
Re: Why JavaScript web applications should embrace traditional URLs
#28Earlier quoted context omitted.
> On a Macbook trackpad or magic mouse you can also set three-finger tap to middle click (with third-party tweaks like BetterTouchTool). Ick. I hate doing two-finger taps as it is. I don't believe one should need anything other than a pointing device with one button to browse the web effectively. Needing to hack in ways to simulate extra buttons is bad design. Why not use a keyboard then?
No, people not using target="_blank" is bad design. It's not Chrome's fault people can't code external links right.
> It's not Chrome's fault people can't code external links right.
People shouldn't have to specify which links are external and which aren't, it should be inferred from the URL being accessed. In the rarer cases where the server is saying to open an external link in the current tab or an internal link in a new tab, that should be specified in the HTML. For the people that want specific global behavior. i.e. all new tabs to be opened in current tab, that should be a configuration option in the browser.
Re: Why JavaScript web applications should embrace traditional URLs
#29I'm getting rank sick of the growing number of websites killing the functionality of the back button. That, combined with Chromes senseless refusal to implement opening clicked urls that are on another domain in a new tab, means I'm often forced to click-and-hold the back button to get somewhere. Incredibly annoying.
There are a bunch of plugins to do that. It seems to me like a behaviour that's better left to a plugin.
That's a terrible use case for a plugin. UI behavior should be well-defined and declaratively specified. Installing a plugin just to tell the browser what to do with a mouse click is total overkill.
Re: Why JavaScript web applications should embrace traditional URLs
#30I like some of Jeremy Ashkenas work (in fact I use some of it daily), but he has jumped the shark with this one. Another bad sign is that he also removed lo-dash (a better underscore.js clone, that fixes several issues, is faster, passes all the same tests AND also strives to support Backbone.js) from the backbone docs.
To try and nip this particular thread in the bud -- I think that forks in general, and Lodash in particular, are great. As CoffeeScript has Coco, Redux, Kaffeine, and LiveScript; as Backbone has Spine; Underscore has Lodash. They're fertile ground for exploring different approaches. My problem isn't with the Lodash project, just with the unfortunate fact that the maintainer has had some incredibly toxic behavior with…
Thanks. Didn't knew the backstory -- just read the related issues/commit messages were there's no mention of any of this.
Had I known, I wouldn't say that. Perhaps an open statement from you regarding the issue would help (this HN thread will be lost to the depths of the intertubes after a few days, and it doesn't give more details of what transpired).