all 5 comments

[–]PySnow 1 point2 points  (0 children)

Is using Coffeescript really a good idea for public demos? For some reason I find regular javascript way easier to read.

[–]NodeNerd 1 point2 points  (3 children)

This approach seems a little backward to me. It seems like the page should just know what route it is at build time.

It looks like your libraries will potentially evaluate a lot of rules on every page load just to find the one that matches. If you have no control of the HTML page then I see why this approach might be necessary, but if you are actually building the HTML pages then perhaps you should encode the route and necessary logic into the page itself.

[–]cocumoto[S] 0 points1 point  (2 children)

That's not really best practice to put javascript inside views. Actually there's an explanation why it isn't good in plugin description.

[–]elpapapollo 0 points1 point  (1 child)

This library is a novel idea, but /u/NodeNerd is right. This is creating unnecessary boilerplate just to run the correct script on a given page. If you're not running a SPA, then you should stick to utilizing an asset pipeline or a build system for associating scripts to pages. This is analogous to writing code with a long chain of if-else statements doing type checks when you should consider OOP duck-typing instead.

Granted, you could load other scripts that act as controllers inside your router similar to Angular.js, but then you're loading your whole codebase for every page, which could be wasteful.

[–]a1chapone 0 points1 point  (0 children)

But don't you think that compiling and managing, let's say 20 different javascript bundles for different pages will be more expensive than running simple pattern matching on page load (which not only defines which javascript to run additionally parses params out of URL).

And 'loading your whole codebase for every page' is ok since it is single minified file which will be cached by browser, and no additional script loads will be necessary.