jongleberry

there's a silly benchmark in the repo: https://github.com/koajs/koa#benchmarks

but there aren't any comparisons yet.

this module doesn't need help. if you want to help, you should contribute to the plugins that it depends on: https://github.com/visionmedia/rework/wiki/Plugins-and-Utili...

1. bower doesn't do much. it downloads all your deps and its deps, but then you have to figure out how to consume the package. component handles all of that for you. if all i wanted to do is download and resolve dependencies, i would just use npm.

2. component doesn't just manage 3rd party packages - it helps manage your internal code/styles/templates as well. see https://github.com/jonathanong/bigpipe-example/tree/master/c.... keeping CSS/JS/HTML for a component of your site in completely separate folders is a thing of the past.

3. it's less adopted because it doesn't have Twitter's marketing and man power. TJ also hasn't had the time to document or market it well. it's also much more difficult to teach (well).

4. i hate requirejs due to its unnecessary callback and defining modules through function arguments. if i weren't using component, i'd use browserify. i have not seen any non-requirejs implementations of a build step, and i'd rather have a single step than two.

5. it's easier to share code between node and the browser. with requirejs, it's a little harder, but it's easiest with browserify.

6. most bower packages are bloated and require other large dependencies like jQuery, and I can't filter through that. component modules, on the other hand, tend to be very small, lightweight, focused, and overall better quality. for example, https://github.com/yields/select is becoming pretty excellent, much better and less bloated than select2.

7. bower packages tend to come with excessive amounts of options (because people request them, ex. select2) and excessive boilerplate code (because people want it to look good right way, ex Font Awesome). component packages tend to be the opposite - minimal, structural styling and very few options.

where are the servers hosted? AWS? US or EU?

You need to construct the stream with flush: require('zlib').Z_SYNC_FLUSH

here's a streams2 library for streaming to the client as an array: https://github.com/stream-utils/streaming-json-stringify

in my experience, you need to set flush to SYNC for it to work on chrome without manually flushing

an alternative is rework: https://github.com/visionmedia/rework. both absurd and rework use https://github.com/visionmedia/css-parse for parsing CSS. the difference is that rework already has a bunch of great plugins like https://github.com/ai/autoprefixer. i'm not sure why this guy doesn't leverage any of the existing ones.

the only difference is using JSON and JS input vs. a CSS string, but he could have easily written that in less than 100 lines vs an entirely separate framework.

i think i found the problem with the algorithm. sometimes it returns an empty row. the javascript version throws while the python version doesn't. i fixed it in my fork by just reducing the number of rows until it doesn't throw: https://github.com/jonathanong/linear-partition

i made a library for this:

https://github.com/jonathanong/horizontal-grid-packing

a solution would be awesome, especially in javascript. i actually found a case where their linear algorithm, https://github.com/crispymtn/linear-partition, failed.

your argument is tangential.

bitcoin's inherent deflation is not by money destruction nor increases in production, thus these arguments are not relevant, although true within its own context. since bitcoin, like gold, has a finite quantity, deflation is mostly due to demand, which you have chosen to ignore in your argument.

i'm not sure what his definition of a "real" currency is, but to me, a "real" currency is one in which all transactions occur within that currency. if you use bitcoin, but somewhere along the lines of a transaction you exchange mediums, it's no longer "real", you're just bartering.

Ember is 50kb gzipped

1) are you using the synchronous or asynchronous version of bcrypt?

2) cached or uncached templates?

3) throw 1k+ requests per second and tell us which one is faster

why not just make this a real thing? adopt a cat from your local animal shelter.

is there a possibility of foregoing EBS storage, using instance storage, and creating incremental backups to S3 using a secondary server on a replica set? is there a reason this would be a bad idea? seems like it would cost a lot less.

if you look at the code, it's based on TJ Holowaychuk's component: https://github.com/component/component. there's i believe 600 "utilities" you can pick and choose from: https://github.com/component/component/wiki/Components. since it's CommonJS, you won't have any namespace collisions or conflicts.

i don't know how this relates to Apache commons, JodaTime, or Guava however, but i just wanted to add a little context.

true. i'm being a little sarcastic, but 1-2 levels of _unnecessary_ indentation bothers me when it's easily avoidable.

it's more like it's unnecessarily messy, which bothers me. if it was necessary, then it wouldn't bother me. and it's not just the nesting that is messy, the whole `define` stuff going on is messy.

agreed. the problem with these AMD frameworks is that the asynchronous nature and deeply nested callbacks are almost completely unnecessary because you end up concatenating/minifying the assets before production anyways. You end up with unreadable files. With synchronous CommonJS frameworks, most of this nesting is eliminated.

but please, not as slow as that website. that site takes me 8 seconds to load.

and what if your whole site is dynamic? varnish doesn't do anything.

500kb transferred? 2 seconds to load all the CSS and JS files? 4.5 seconds to load everything?

Way too much overhead for a static page, IMO.

it's unnecessary. if google can't give you your desired results within the first 10 results, they've failed. you should just retry your query instead of checking the next 10 results.

also, infinite scrolling is more for "discovering" without a specific result in mind whereas "searching" implies you have a result in mind and is either hit or miss.