Having bashed my head against Backbone's router over the past few months, I've come to the conclusion that pattern based routing is just the wrong approach for picking a view to render the page. Instead, choose a view based on some property of the JSON returned by that URL (I'm using '@type' as our API will expose linked data through JSON-LD.) Now route information only needs to be specified once, server side.
Why JavaScript web applications should embrace traditional URLs
41–45 of 45 posts
Re: Why JavaScript web applications should embrace traditional URLs
#42Earlier 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?
It's not Chrome's fault Apple doesn't put a middle button on their mice like everyone else. Though personally I prefer 3-finger tap to using buttons at all on a PC laptop trackpad.
Even if Chrome always opened external links in a new tab with a left click, you'd still want middleclick functionality to browse the web effectively; I constantly open multiple tabs from the same domain- for instance, to open a HN comments section without navigating away from the front page.
Re: Why JavaScript web applications should embrace traditional URLs
#43I 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…
Hi, creator of Lo-Dash here. Jeremy's comments are off base. I've gladly contributed to Underscore and am responsible for many of the fixes/features in the last few releases. I voluntarily revoked my commit rights to Underscore, without prompting, several months ago because it was awkward trying to move Underscore in a better direction while trying to work with Jeremy, who seemed distracted, lacking the patience to grok issues/comments, often losing his temper in issue/commit comments or trashing me on Twitter/HN. I'd still be contributing via bug reports and feedback if he hadn't recently blocked me.
It's unfortunate he's chosen to spread FUD instead of going head to head on features, compat, perf, dev needs/concerns, or any other relevant area of project comparison :/
Re: Why JavaScript web applications should embrace traditional URLs
#44Earlier quoted context omitted.
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 t…
> all new tabs to be opened in current tab
I think you're confusing links and tabs. I think you're trying to throw a lot of extra logic into the browser that doesn't belong there.
Re: Why JavaScript web applications should embrace traditional URLs
#45Earlier quoted context omitted.
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.
Web UI is well-specified. Click is follow hyperlink. Right click is browser context menu. Middle click is open in new tab, also available from the context menu.
Whether a link opens in a new tab without user intervention is up to the link, and is way overused IMO.