Wow, this is beautiful. Makes me want to develop something in Go ;)
3,882 karma · joined March 12, 2011
website: thomasboyt.com
It's also worth noting that you could already do this in _config.yml, this just lets you split that up.
I can see it not being a good idea to start your own startup super early for the reasons the author lists. I don't think there's anything wrong with joining a growing startup early on, though.
That's nice, but will it translate into sales? Probably not, given the horror stories of Android piracy that seem to come out every few weeks (particularly in the gaming market).
Of course, many startups profit in hype instead of dollars, so maybe that's irrelevant.
Require.js has an optimizer that does exactly what the author suggests: http://requirejs.org/docs/optimization.html
The point is to build your application using AMD, using individual assets in development, and then run the optimizer - which concats and adds a loader - for production.
Alternatively, you can even go a step simpler and always use concatenated files, along with a minimal loader like Almond.js[1]. If you do this, you'll probably want to use something that adds source maps for your concatenated file (for easier debugging), but that's easy - you can use grunt-concat-sourcemap[2] or a similar plugin for whatever build system you like.
https://gist.github.com/domenic/4748675
https://gist.github.com/wycats/51c96e3adcdb3a68cbc3#importin...
(both of those are slightly out of date, syntax-wise, but are still conceptually current, IIRC)
Personally, with JavaScript being the first language I seriously learned, it's intuitive for me to reason about. JavaScript is built around closures, and you're simply importing a closure that returns (exports) its public interface.
In fact, the main issue I have with ES6 modules is that they differentiate a "module object" from its default exports, which can be tricky to reason about (basically, what I wanted from ES6 modules was just syntactic sugar over CommonJS, whereas what we have is more powerful but more complex).
This seems short-sighted, with ES6 modules now being used in production (through transpilers) and slowly making its way into SpiderMonkey and, more importantly, V8.
For anyone else wondering, it looks like the app is powered by Backbone, D3, and Handlebars on the front-end.
I think a far superior option to these kinds of active, "HEY LOOK AT ME" alerts would be something that could fit in passively but draw just as much viewership, and not just on phones.
Imagine if, when an Amber Alert was out in your area, the alert showed up in your Twitter and Facebook feeds, your phone's lock screen, and maybe even above your email inbox. Sure, some people would probably mentally (or actually) filter these out just like they filter out ads, but it's preferable to everyone getting annoyed by the alerts and turning them off entirely.
I'm surprised that I haven't seen a library for any JavaScript framework that elegantly handles loading JSON returned within a server-side template. It seems like the best of both worlds - use your server-side template, but then also get the data as JSON so that you don't have to do a second request to populate your Angular $scope with data.
The easy way to implement this would be a library that automatically added <script> tags containing the JSON that you could then reference from your Angular template. It could even wrap the JSON in an Angular module of some sort to keep your global namespace from being polluted.
My issue with this is that it doesn't solve the problem of binding to asynchronously-loaded resources. You have to manually implement your own ng-cloak logic, or use ng-bind, to not have {{mustaches}} waiting for data to be loaded.
Compare to Ember, where {{mustache'd}} data-bound bits aren't rendered until their bound variable is defined.
(the, other fix, of course, is to do something like `<span ng-hide="foo != undefined">{{foo}}</span>`, but that doesn't scale particularly well)
Regardless, of course, people add metadata to JSON already - there's zero reason you can't "_type": "int". It's a completely arbitrary reason.
It's ridiculous that I can't document notes on dependencies in my NPM package.json, or add a little reminder to my Sublime Text configuration as to why I set some value, because we're using JSON parsers that can't handle the concept of ignoring a line with a couple slashes prefixing it.
IMO - either we add comments to JSON, or we stop using it for hand-edited configuration.
I installed it, and it works exactly the same, as far as I can tell.
With Angular, on the other hand, you can just pop the full object from retrieved from the server into your $scope, change it like you would any other object, and then sync it back with a function that will create a diffset between the original object and the current state.
I would NEVER buy a screencast, tutorial, or anything on web development without knowing EXACTLY when it was last updated. For example, the paid Ember screencasts claim to go over the Ember router - how do I know whether it was the old beta router, the RC1 router, or the RC6 "Promise-ified" router?