Parcel – A fast, zero configuration web application bundler - <AUTHOR> https://parceljs.org/ <comment><USER2> Came here to puff about "yet another bundler".

Then read all of the docs in 15 minutes and realized that I might like this.

Then I used it and I know that I'll keep using it, unless there are any showstoppers.

Great job, Devon!

</comment><comment><USER3> Browserify, Webpack, Gulp, Grunt: everything nice and shiny, but the one JS lib that stands out for me is Rollup.js[1]

Why? Because Rollup.js makes it possible to structure code into modules in a way that is backwards compatible and future proof. Yeah it takes some getting used to and it is not yet as simple as it could be, because integrating libs which are not yet available in the module format, takes some manual configuration, but once you know how to use it you won't want to got back.

I can highly recommend it, not because it is the hottest tool out there, but because I think it has a much higher long-term value than most JS libs.

Parcel seems to have a similar functionality but due to the wide range of other functions it comes with, I think there is a much higher chance that it will be rendered obsolete in the near future. Rollup.js on the other hand _focuses_ on the combination of modules to a single bundle which will continue to be required for the foreseeable future.

[1] [https://rollupjs.org](https://rollupjs.org)

<comment> vladimir-y Webpack actually does the same (it's module bundler), browserify too (but in a more limited way). Gulp ant Grunt are not the module bundlers at all, but simply a task runners - absolutely different things. Btw there is also FuseBox module bundler, seems also with a focus on performance and configuration simplicity.

<comment><USER3> You are right, they are not exactly the same type of programms. Nevertheless, most of the time they are used for the very same thing: to transform your development source to format which is best to be delivered to the browser (bundling).

Actually, I still use Gulp to call Rollup.js as it is more flexible and allows me to use features which are not the scope of Rollup.js (e.g. automatic browser reload). My point is, that the exact thing Rollup.js focuses on is very important for the long-term development of JS: Modularization. Yeah, I know thats an upcoming part of the JS standard. But with Rollup.js you can use it today, as it has various adapters for legacy formats and therefore you have a tool which allows you a smooth transition into the future ;-)

<comment> vladimir-y Sure, but just don't limit yourself by the Rollup.js only. Again Webpack is a module bundler (modularization is there), and it was a module bundler before Rollup.js went public. So you can use all the ES6/7/TypeScript stuff (including modularization) using Webpack, Rollup, Fuse-box, and other bundlers, the difference is in the configurability, performance, configuration syntax, etc. Though yes Rollup provides some specifics, which might be more suited for the standalone libraries releasing, while Webpack would be better choice for the complex app development (that is it not supposed to be released as a library, but deployed somewhere as a complete app).

</comment></comment></comment></comment><comment><USER4> As a person who is not well-versed in front-end technology, it will be great if the author(s) could provide more comparison on the website against some other tools that serve the similar purpose in aspects other than performance. For instance the by comparing the scope the problem each solves, the ideology behind each project, or even a side by side configuration file.

</comment><comment><USER5> The eternal cycle of developer tool bullshit:

1\. "Ugh, OldTool™ v3.0.0 is overcomplicated, bloated, slow and unnecessarily configurable!"

2\. "Introducing SuperTool™ v1.0.0, which just does the stuff you really need. No bloated configuration. No huge ecosystem of extensions. Simple, straightforward and fast."

3\. "SuperTool™ v1.0.0 is great! But our setup really needs it to do something a bit different, so we've hacked in this extension."

...repeat for a while...

10\. "Introducing SuperTool™ v2.0.0, which now has a more flexible API and configuration , allowing many former hacks to be done in a straightforward way."

11\. "SuperTool™ v2.0.0 is great! But our setup really needs it to do something a bit different, so we've hacked in this extension."

...repeat for a while...

20\. "Introducing SuperTool™ v3.0.0, with a whole new, flexible, pipeline based API. Everything is a plugin! There's even a plugin to send email!"

21\. "Ugh, SuperTool™ v3.0.0 is overcomplicated, bloated, slow and unnecessarily configurable!"

22\. "Introducing HyperTool™ v1.0.0, which just does the stuff you really need. No bloated configuration. No huge ecosystem of extensions. Simple, straightforward and fast."

<comment><USER6> Welcome to developing in 2016-201X, were you spend 60% of your time configuring tooling, 35% developing test and 5% developing your app.

<comment><USER7> Or stick to something that works for you and keep using the same tool over and over again.

No one is forcing you to use the latest bundler / tool / programming language. Let others experiment. You'll be happy to reap the benefits of their work when something mature comes out of it.

<comment><USER8> > No one is forcing you to use the latest bundler / tool / programming > language.

Tell me that when you get turned down in a job interview because you don't know <JS framework of the year>.

<comment><USER9> Try working on your positioning so that you are not hitched to the <JS framework of the year>. You will forever be competing with the low end of the market if you cannot market yourself.

<comment> FLUX-YOU Your advice basically tells them to get out of JS development because businesses continually hitch themselves to <JS framework of the year>.

This stuff comes up in interviews. Trying to avoid answering direct questions about a framework and answering with "Well I can learn it really quickly because I'm a good vanilla JS Dev" doesn't fly all the time. If you can't answer direct questions about a framework, they will pass on you if they get someone who can answer those questions.

It has nothing to do with marketing yourself.

<comment><USER9> What you described is a hiring problem. Marketing is knowing who your buyer is and finding creative ways to get their attention.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> I think it's super cool.

I've been configuring Webpack projects for almost 2 years now and I'd rather use Parcel tbh. My only problem is the lack of plugins such as loading .vue files.

<comment><USER11> +1 for Vue support

<comment><USER12> And the over complexity begins...

It would be nice though

</comment></comment></comment><comment><USER13> With transitive dependencies, the total install footprint for this is 689 packages weighing in at 77MB.

This isn't reducing complexity, it's just taking all the junk you'd normally have in your bloated boilerplate and putting it directly into the build tool. I'm not convinced that's a good idea.

<comment><USER14> Mmmm, so... sub 100MB for a bundler + compiler + etc?

      - Xcode, for iOS/Mac Development, is usually around 5GB (and
      no, even if you remove every single simulator, it's still over 100-200MB).

      - Android Studio is roughly the same deal as Xcode.

      - I've not used Windows so I can't say for sure, but I'd be surprised if the various tech there doesn't follow this pattern.

77MB is nothing, and if you care about this, you're caring about the wrong things.

<comment><USER13> 689 packages is enormous surface area for a leftpad-like (or worse) failure. Given that nobody is auditing those packages and many of the people who maintain them aren't adhering to best security practices[1], I don't think taking nearly 700 dependencies that you are going to treat like a black box is a safe or responsible choice.

Xcode and the Android SDK each come from a single vendor who provides an integrated development stack and presumably vets the contents. Does anybody do that with these npm packages?

It seems like every time I run the du command in my node_modules folder, I find some crap that shouldn't be there. Earlier this year, I submitted a PR that reduced the size of the babel react preset install footprint by about a third, just by removing a totally unused dependency that nobody noticed. I don't think the contents of npm packages get nearly enough scrutiny and it scares the hell out of me.

[1] [https://www.bleepingcomputer.com/news/security/52-percent- of...](https://www.bleepingcomputer.com/news/security/52-percent-of-all- javascript-npm-packages-could-have-been-hacked-via-weak-credentials/)

<comment><USER15> Build tool. Not app code. How is security relevant here?

<comment><USER13> And you don't care if a malicious party compromises the development machine on which it runs? I can think of a whole lot of really damaging things that somebody could do running arbitrary JavaScript code with user-level privileges on thousands of developer workstations.

With various CI setups and some server-side rendering configurations, there are potentially scenarios where build tooling actually do run in environments where there are higher risks, though it's not as applicable in this specific case.

</comment></comment></comment></comment></comment><comment><USER16> The two coolest things about Parcel for me, are 1) multi-core support, and 2) a simpler, ES6-esque API. Without these two distinct elements, I think Parcel is nothing more than a simple Webpack boilerplate which could easily been generated by yeoman.

I see its potential regarding Parcel's competitiveness against Webpack, but it also has worsen the JavaScript fatigue, which is considered a nightmare for many newcomers webdevs because of huge fragmentation and thus bigotry in the industry.

</comment><comment><USER17> Is my career as a Webpack whisperer at an end?

 _cries tears of joy_

;-)

<comment><USER18> Go, you're free now.

</comment></comment><comment><USER19> It would be nice if these bundlers could help publish npm packages that vend non-JS assets (html, stylesheets, fonts, images) in a way that's easily consumed by other packages.

For example, if one of the JS modules in a library package says "import classes from './styles.scss'" and an application package imports that JS module, the application should somehow end up with the CSS output from styles.scss without having to configure Sass itself, and without having to include the entire stylesheet from the library package.

<comment><USER3> Actually, you can do that with rollup.js and riot.js. Components written with riot.js contain all their HTMl, CSS and JS (preprocessors can be used too). Rollup.js can import those components like normal js modules and at runtime riot.js injects the HTMl and CSS.

The only downside is that you either deliver one large bundle with mixed HTML/CSS/JS content to the browser or have to use some complicated configuration the split at least the CSS to a seperate file.

</comment></comment><comment><USER20> I've been using [http://brunch.io](http://brunch.io) and enjoying it. Far less configuration than Webpack.

<comment><USER21> I love brunch but I can't find a community for it, what do you do when you need support on a plugin or help understanding something?

I have a few github issues open that haven't been touched in months!

[https://github.com/brunch/brunch/issues/1752](https://github.com/brunch/brunch/issues/1752)

<comment><USER20> 100% agree that support is a major problem. I had to figure it all out for myself, through trial and error.

</comment></comment></comment><comment><USER22> I had my eye on [http://fuse-box.org/](http://fuse-box.org/) for a while, and tried a few sample projects with it. It has a lot of the same promises as Parcel appears to have. Multicore is exciting for me, which Fusebox doesn't have. So... many... choices...

</comment><comment><USER23> It would be great if the author taken any of the HNPWA project and replaced WebPack with Parcel so you can compare the setup and actual configuration needed. WebPack is currently a standard and the community is great so I'm not seeing this replacing it in any way.

</comment><comment><USER24> I have no problem with ditching webpack for another tool if it's faster and of similar or better quality. Is anyone using this in production and want to share their experiences?

</comment><comment><USER25> Should main.css be included in the index.html example?

This just confused me for some reason but it's more me focusing on the wrong thing, haha

<comment><USER26> It's injected into the main.js file which is added via index.js to the page

</comment></comment><comment><USER27> From the webpack team to Devon:

Thank you so much for this work! Not only are we happy to see a real contender in the bundling space, but also look forward to not only work together, but also learn from parcel in ways we can help make webpack more flexible and easy to use for those who want "zero configuration".

Welcome to the bundler family!

Sean webpack team

</comment><comment><USER28> Really happy that besides being fast they made a priority to keep the configuration simple.

I love webpack to death but there are just so many parts that I keep getting confused, esp with things like "!" in in require, always copy-pasting the same boilerplate code over and over to for sass, es6, etc. I know it may be more flexible but sometimes you just want things to work and can't be bothered with too many details. Laravel did this with elixir where it wrote a wrapper just to do it (which lets you just get on with your work without having to learn another tool). This too seems to be focused on that. Great job!

</comment><comment><USER29> Didn't see any info that would give me an impression of the possibility if this getting any traction which I think would be even more important than any specific benefits.

</comment><comment><USER30> This looks awesome!

After reading the docs though I couldn't find any mention of tree-shaking or other things that would shrink the final bundle size. Any word on that front?

<comment><USER31> This is what I was wondering as well.

Especially since Webpack's tree-shaking doesn't _really_ work for a lot of third party libraries:

[https://github.com/webpack/webpack/issues/1750](https://github.com/webpack/webpack/issues/1750)

I imagine Rollup might do a bit better on that front since its the bundler that popularized tree-shaking in the first place. Can anyone with experience with Rollup comment on this?

</comment></comment><comment><USER32> Looks like a well-thought-out approach to a clientside JS bundler.

Is this officially backed by one of the author's employers or any other organization? I've seen too many projects (including major parts of bundlers browserify, gulp) die early when a sole author is forced to move on. Beyond the technical advantages, if I knew a company had already invested resources it would give me a solid business reason to switch.

</comment><comment><USER33> I am not the target audience for this.

However, my first reaction was "yet another build tool, huh?"

My next thought was "...I must be getting old."

<comment><USER34> Wait for another 6 months, and we may have "yet another build tool" again

</comment></comment><comment><USER35> Is anybody running a project with webpack that has a 20s rebuild time?

Or if somebody has switched from webpack to parcel, can they give an idea of the performance improvement?

We've got a moderate sized app, and webpack rebuild (typescript, server-side react, client side js bundle, css export) is less than 3 seconds.

<comment><USER36> We have a React app with roughly 100k LOC and a lot of SASS that takes about 4 minutes now to create the bundle on my MacBook Pro 2017.

<comment><USER37> That's probably the _initial_ build, though, right? If you've already got dev- server running and it has to rebuild, it shouldn't have to rebuild the entire bundle again.

<comment><USER38> Also every time you add/remove a file or make similar breaking changes.

</comment></comment></comment></comment><comment><USER39> > Bundle all your assets

Can someone ELI5 what is bundling and what problem does it solve?

<comment><USER40> Sure. Programmers usually group logically-related functions/classes/components into smaller files.

The logic for web "applications" these days can be complicated and involve loading hundreds of such files. If loaded individually, this requires a lot of HTTP requests and results in a slow page load time.

Bundling is similar to a static linker in that it produces a single binary out of all its dependencies. This can be loaded with a single HTTP request, cached, zipped, whatever.

</comment></comment><comment><USER41> When one deploys something like this in production, how do you interact with an internal API? Surrendering control of my url routing always causes problems for me.

</comment><comment><USER42> how does this handle existing 3rd party jquery plugins? The single biggest problem and configuration nightmare I always face is bundling something like CKeditor.

</comment><comment><USER43> So far from comments I have collected following bundling tools:

\- Webpack

\- Rollup

\- Fuse-Box

\- Brunch

\- Browserify

</comment><comment><USER44> React and node bundling and compilation ?

</comment><comment><USER45> Which bundler does this use?

<comment><USER46> It is a bundler...

</comment></comment><comment><USER47> Explain to me why do we web app need bundlers?

<comment><USER48> I long for the day I can use browser native import to retrieve all my modules and deps, but at this point it doesn't resolve node_modules and that makes it unusable to me and the reason I am using a bundler.

</comment></comment><comment><USER49> why are we not just using bash scripts ???

-you can log output -perfectly capable of handling your unique build style -no setup (pretty much) -just call the command lines of other tools like (less.c, yui-compressor.jar ... etc) for compliation tasks

talk about over engineering. The thing is that the reason we dont have 1 to rule them all now is because no one has ever objectively argued why one is better than the other.

If we could just get command line equilvalents for things like ember-cli that didnt require npm then we would be good. Npm is the thing holing us back , we dont need it to do command line processing. Its a bloated middle man. Please command line tool gods , offer your tool outside of the javascript eco system. Build it in java and export to jar or c and allow us to worry about the stitching

Question , what is the thing npm/grunt/gulp gives us that cannot be done with bash, if all the tools we used were command line executables?

<comment><USER50> I think you may be confusing npm with something else? npm is a package manager, and it does run as a command line tool. Similar to how apt-get is the command-line frontend for a package ecosystem. npm also includes npx, which allows you to directly run any command line utility in the npm ecosystem without installing the package first.

Try running `npx ember-cli` directly in your terminal.

<comment><USER49> all you say is correct but im not confused. node and npm is require to run many command line tools (grunt, gulp ...etc). I think this is an unnecessary overhead if we could get these tools to just be built as standalone command line tools and then we can just use bash. Im asking for a particular feature that comes from this environment that I dont have in bash? Why do I need this environment.

I have a sense that webpack is the same, its a bloated environment. I dont need an all in one solution for a build process. Just give me the tools, ill use bash and call it a day. So Im just asking, is there something Im missing? What is the feature from these environments that I can directly preform by calling a script from bash? Why cant we just pull that script out into a command line tool and then devs can use it to their liking, pipe its output to a folder, cat that file to soemthing else, call another tool to minify the results, move all the contents to the dist folder.

Node just doesnt seem to give me any more power as a dev (build wise), why is it so important to the space.

Hats off to frontend engineers, the space has evolved to something respectable but I feel like over engineering is a pursuit of community. Its like they keep making new tools, to encapsulate more features and then post on HN and say "Look at this cool new way to do things that fixes that problem you really didnt have".

No ones webpack was bottlenecking their work, im guessing you can choose what to build and when so you dont have to do a full build every time. No one is going to choose a build system because of its blazing speed. I would rather not have people work on these problems that dont really need to be solved.

<comment><USER51> Node is a runtime, npm is a package manager. Together they let you download code (js or otherwise) and run it.

This is the same as Java (JVM), .NET (CLR), and plenty of other languages. You can compile to a native assembly if you like (similar to C++ or Go) but it's not necessary when you have fast runtimes and JIT compilation.

Everything you listed for functionality is possible today - while also letting people write and ship code to multiple platforms quickly.</comment></comment></comment></comment>


Is this all a lie?  They spy on all of us.  Why do they need an iPhone? - <AUTHOR> Since we all know that they spy on us all the time, why all the fuss over a single iPhone? <comment><AUTHOR> I wonder if it is just because FBI feels left out of the party. NSA is having all the fun. Maybe all of this is an interagency conflict.

<comment><USER2> No that's just silly.

I wonder if there is something somewhat related. It's not just A Phone, once they have the access method then virtually all other phones of that kind are open.

They are using a High profile case because it's easy to find an echo in their petition. They probably want to see many other phones, but this case goes deep in the mind of the people. From the start it seemed off to me that the suspect was cautious to destroy all the other information but leave the phone... there.

The phone might be just a normal one and have no clue at all.

</comment></comment><comment><AUTHOR> Or maybe this is a very public admission that they can't break encryption.

<comment><USER3> Or maybe they can but they do not want to reveal their ability to do so just yet. We'll never know, until then assume they can break your crypto and use that knowledge to stay safe with your information.</comment></comment>


Performance Tuning EC2 Instances - <AUTHOR> http://www.slideshare.net/brendangregg/performance-tuning-ec2-instances

<comment><USER2> The video that goes with these slides is here: [https://www.youtube.com/watch?v=7Cyd22kOqWc](https://www.youtube.com/watch?v=7Cyd22kOqWc)

</comment><comment><USER3> Can someone comment on why they use FreeBSD for content delivery (vs linux as a default choice)? Seems people use BSDs for certain high-performance tasks and I'm curious what advantages it has.

<comment><USER4> Scott Long has summarized it a few times, eg, from [http://people.freebsd.org/~scottl/Netflix- BSDCan-20130515.pd...](http://people.freebsd.org/~scottl/Netflix- BSDCan-20130515.pdf):

      • Availability of expertise, outstanding community
      • Works well, good vendor support
      • No GPL
      • Features used:
      – SUJ
      – gmirror – boot drive only
      – AIO
      – Dtrace, HWPMC
      – TCP Stack, modular CC

It's missing "Integrates tightly with nginx: Async I/O and sendfile()"

which Scott included in [http://youtu.be/FL5U4wr86L4?t=18m30s](http://youtu.be/FL5U4wr86L4?t=18m30s) .

In the video he elaborates a bit more about the GPL...

edit: formatting

<comment><USER5> Wouldn't you say that Linux integrates just as nicely with nginx's async I/O and sendfile support?

<comment><USER6> I thought *BSDs used kqueue, which allegedly had worse performance at high concurrency vs Linux's epoll?

EDIT: This seems to suggest kqueue may have better performance due to less syscall overhead: [http://www.eecs.berkeley.edu/~sangjin/2012/12/21/epoll-vs- kq...](http://www.eecs.berkeley.edu/~sangjin/2012/12/21/epoll-vs-kqueue.html)

<comment><USER5> Yeah, it's the opposite, though there are other mechanisms that could do better than epoll, but they need more refinement.

</comment></comment></comment></comment></comment><comment><USER7> "Swappiness is set to zero to disable swapping..." for many (most, older?) distros setting swappiness to zero won't disable swapping completely.

</comment><comment><USER8> vm.swappiness != 0 is useful if you use something like zswap.</comment>


How to sign up for TSA PreCheck - <AUTHOR> http://www.businessinsider.com/how-to-sign-up-for-tsa-precheck-2015-7?op=1 <comment><USER2> The very existence of any "fast lane" should automatically call into question every single security procedure that is disabled by the fast lane.

After all, there is not a single criterion for TSA PreCheck that couldn't be met by someone wishing to do harm. Proof of citizenship, etc.? (Right, because none of the thousands of people currently in prison are citizens.) Fee required? (Sure, because terrorists couldn't possibly come up with the cash.) And so on.

Since someone with ill intent would clearly be capable of achieving TSA PreCheck status and bypassing some of the checks, the passable "security" checks therefore _must not be important by definition_ and should be automatically discontinued.

The really sad thing is, I've observed that it bypasses the ultra-expensive scanners in most situations too. So they're essentially admitting not only that a lot of their checks waste time but that the things they spent obscene amounts of money on are also not necessary.

</comment><comment><USER3> Hello, we are the TSA. We are a massive, sprawling government bureaucracy that has never caught a single terrorist. We know airport security is a massive pain in the ass for no discernible reason and no tangible benefit to your security as a traveller.

If you would only pay us a small recurring fee, we will agree to hassle you less and speed you through this line-up.</comment>


The Naive Approach to Hiring People - <AUTHOR> http://weblog.raganwald.com/2008/02/naive-approach-to-hiring-people.html <comment><USER2> Our (brief) discussion about this three years ago: <http://news.ycombinator.com/item?id=113584></comment>


20kW Bulb Turns Night into Day - <AUTHOR> http://nerdist.com/watch-as-a-20000-watt-light-bulb-turns-night-into-day/ <comment><USER2> This may be a bit OT, but I feel like it's unfortunate that "watts" (i.e. power consumption) is the default unit used in lighting. It's like measuring the speed of a car in miles per gallon.

Seems like it's changing a bit after CFLs came out and they started putting luminosity outputs on the packaging, but I think people still mostly go by "incandescent watt equivalent".

<comment><USER3> Power = energy flow per unit time. So you can talk about radiation output, radiant flux as it's called in physics, in terms of watts: 683 lm of light at 555 nm wavelength equals 1 joules/second (=1 watt) in radiant flux[1]. 20 kW in light output would be about 14 megalumens.

[1] [http://www.dfisica.ubi.pt/~hgil/fotometria/HandBook/ch07.htm...](http://www.dfisica.ubi.pt/~hgil/fotometria/HandBook/ch07.html)

</comment></comment><comment><USER4> You can get 12kW/18kW with ballast for cool ~$40k [https://www.arri.com/lighting/m_series/products/arrimax_1812...](https://www.arri.com/lighting/m_series/products/arrimax_1812/) Arri had, and Mole Richardson still has a 24kW version too. Here's an 18K burning insects: [https://www.youtube.com/watch?v=74ub_bysnl0](https://www.youtube.com/watch?v=74ub_bysnl0)

Passing by one (a few meters away) feels like you could (and you probably could) grill a chicken in-front of it.

</comment><comment><USER5> Can someone explain to me what's going on with the control panel? I see three round things and rotating things below that. What are those?

Also, isn't it dangerous to have that equipment indoors in a carpeted room? Obviously he probably knows what he's doing and so I would guess it's not _that_ dangerous because of that, but still looks scary.

Finally, how do you get that amount of power in a house? does he have a special installation that provides more power that a regular house connection would?

<comment><USER6> I'll take a stab at this:

 _I see three round things and rotating things below that_

It's some variation on this variable autotransformer: [https://en.wikipedia.org/wiki/Autotransformer#Variable_autot...](https://en.wikipedia.org/wiki/Autotransformer#Variable_autotransformers)

that's a way to gradually increase voltage.

 _isn 't it dangerous_

I was also more than vaguely disturbed by how casually he was operating. That bulb perched on a stool didn't seem all that stable. But as you say, "he probably knows what he's doing".

 _how do you get that amount of power in a house?_

"two hundred amp service" is very common in the USA. I just checked the breakers in my garage. My main breaker is labelled 200 Amps. It has two "poles". Which means there are two separate 120 Volt inputs (referenced to Neutral). The inputs are 180 degrees out of phase, so across them is 240 Volts. 240 * 200 = 48,000 watts.

<comment><USER5> Ah. It definitely looks similar to that. I also noticed that he would move the skull shaped lever up and down and that would change the rotation on the transformer so I guess it's also to show the power up process.

Yes, I was also thinking about that fragile thing leaning over and causing damage.

Aha... that explains it. I knew I was missing some math!

</comment></comment></comment><comment><USER7> I wonder how much uv it is generating.</comment>


Asm.js: a strict subset of js for compilers – working draft - <AUTHOR> http://asmjs.org/spec/latest/ <comment><USER3> Sitting about 10 feet away from Luke Wagner right now. He has told me that asm.js is Mozilla's response to NaCl. You compile code with Clang (or another compiler) into the asm.js subset of JavaScript, which they know how to optimize well, and their JIT compiler will offer you performance very close to that of native C (they claim a factor of at most 2x). They use special tricks, like (a+b)|0, to force results to be in the int32 range, and avoid overflow checks. The heap views uses multiple typed arrays pointing to the same data to give asm.js code a typed heap of aligned values, avoiding the JS garbage collector (you can manage this heap as you wish).

They already have sample apps, including some using libraries like Qt (I believe OpenGL as well), compiling to asm.js. I believe it has potential, so long as they have good support for standard and common C libraries (i.e.: porting to asm.js is almost effortless).

<comment><USER4> > They use special tricks, like (a+b)|0, to force results to be in the int32 > range, and avoid overflow checks.

Why is this not seen as the worst idea ever? Why this great resistance to moving away from javascript?

<comment><USER5> > Why this great resistance to moving away from javascript?

To what? What scenario do you envision where Apple, Google, Microsoft and Mozilla are all willing to implement a single new language for the web?

<comment><USER4> > To what? What scenario do you envision where Apple, Google, Microsoft and > Mozilla are all willing to implement a single new language for the web?

Well hopefully we wouldn't make the same mistake again by going with a language and we would just implement a VM on which JS is implemented. It would be much easier to validate the correctness of a VM anyway, achieve better speed than was possible before, and not tie people down to a (painful) language. On a personal note I would actually start to view the web browser as a platform instead of a bunch of tangled strings, cans, and tape.

EDIT: I didn't answer your question. But, as a developer, I will only move to the web for my default programming language when I have bytecode or assembly to look at, not some convoluted scripting language. Hopefully, Asm.js is a minor, minor bump on the way towards the browser as a usable platform for arbitrary development.

<comment><USER6> Oh. Right. A VM. On the web. Because that worked reallllly well when Java did it.

<comment><USER7> Don't forget Flash, which did actually work relatively well, and pretty much powered the development of the web as a video and gaming platform... but which we've eventually ditched for HTML/CSS/JavaScript + native web APIs anyway.

<comment><USER6> That is fair enough. Though that wasn't really Flash's original ambition. And to be further fair, the fact that it wasn't their explicit ambition is possibly what saved it, while Java suffered a doomy fate from Microsoft's embrace and extend strategy.

Flash was fine as a format for vector images. (like SVG). Then it was fine for animations. Then simple interactive graphics. Then it gets a scripting language. And as it gets more and more sophisticated, more used as an application platform-- something flash was not originally designed to do, it becomes more and more like Java in its shortcomings. Binary blobs. Long load times. Serious security holes. Slow as molasses.

But flash always had one good thing going for it: Anti-aliasing.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> This seems very much targeted at emscripten and not to cross-compilers that start with GC'ed languages like GWT, Dart, ClojureScript, et al. If you are cross-compiling Java or C# to asm.js, you don't really want to manage memory manually. I work on GWT, and asm.js as an output target is very interesting to me (I've worked on a number of performance Web games using it, GwtQuake, AngryBirds, etc), but the starting assumption is GC, so I want to leverage non-boxed numerics, and all of the other nice stuff, but don't want to stuff everything into a TypedArray.

It's also unclear to me how this solves the problem of startup time on mobile. A giant glob of Javascript takes a non-trivial amount of time to load even on today's fastest smartphones. The spec seems to argue that Browser VMs could recognize asm.js and if I read between the lines, employ snapshoting the app and caching it for later quick startup?

In all likelihood, the majority of asm.js outputs would be actually be non- human readable output of optimizing cross-compilers, so there isn't much benefit from having a readable syntax that humans could read, so what's the real justification for using JS as an intermediate representation over say, a syntax specifically designed for minimum network overhead and maximum startup speed? Seems like it might be worthwhile for Mozilla to also work on efficient representations of asm.js that minimize this overhead. The usual response is minify + gzip, but it's not a panacea.

<comment><USER9> We have plans!

First of all, we do care very much about supporting compilers for managed languages like Java and C#, but we're starting with this first version that only supports zero GC and atomic primitive types. We have plans to grow outwards from there to support structured binary data, based on the ES6 binary data API, and controlled interaction with the GC. Luke has ideas about how to do this without losing the predictable performance for lower-level compilers like Emscripten.

We do have plans for startup time. I hope to pitch a very small, simple API for a kind of opaque compiled Function. Internally we've been calling it FunctionBlob (we'll bikeshed the name later). The idea is that `new FunctionBlob(src)` is almost identical to `new Function(src)` except the object is (a) an opaque wrapper that can be converted to a function via `fblob.toFunction()` and (b) entirely stateless and therefore compatible for transfer between Workers as well as offline storage. This would essentially make it possible to do things like background compilation of asm.js on a Worker thread, and caching of the results of compilation in offline storage. That way next time you startup you don't have to download or optimize the source. (This could work especially well with the app experience where you could perform these download/optimize steps as part of the installation process.)

As for the use of JS, this is purely pragmatic. The code works today in browsers, so people can start using it and it works -- and even quite fast; Emscripten is already shockingly performant in Firefox and Chrome -- but over time it'll see better and better optimization.

<comment><USER8> Presumably, if it was a blob, it could also be stored in local storage/indexdb/filesystem API? Is the internal format supposed to be architecture neutral, or dependent? I can see arguments for either, but if it were neutral, than the blob conversion could be done offline/statically on the server, and downloaded by the client dynamically (e.g. XHR to fetch function blobs). If it were architecture dependent, then I could see advantages as well, letting the browser vendor choose the optimal form of the blob. This would potentially yield better performance, but you wouldn't be able to host blobs on the server.

Anyway, cool idea.

<comment><USER9> I was only thinking that it would be internal. Your server point is good, but I think way, way harder, and kind of starts the whole project back at the beginning: how to design a standard, efficient, optimized bytecode format. So I think it's probably not really feasible.

Not the same, but an additional optimization you can do is incremental compilation. Because you have JavaScript's eval, you can download the code a bit at a time and optimize (and cache via FunctionBlob) each piece.

<comment><USER10> Storing it and transferring it on the server is one thing; serializing it locally in the browser itself might be a more reasonable goal? That is, it wouldn't be expected to be portable to anything but that very same browser, but it would allow you to cache the compiled result. (I would expect the serialized string to be signed by the browser itself, to prove that it was created by the browser – and for the deserialization to fail on some browser upgrades).

<comment><USER9> Right, that's the idea of FunctionBlob. It wraps a browser-internal representation of the optimized compiled code. The web code can instruct the browser to store that offline, without exposing its implementation-specific details to the web code. The web code can then, in a later session, retrieve that optimized code from storage as another FunctionBlob, which it can then convert into a Function. This is no different from just storing the asm.js source code in offline storage, except it avoids redoing the work of compiling and optimizing the source. (It'd still have to be stored in position- independent format and there might be some back-patching necessary when reloading it.)

</comment></comment></comment></comment></comment></comment><comment><USER11> <https://bugzilla.mozilla.org/show_bug.cgi?id=840282> has some measurements on how fast the implementation of asm.js (called OdinMonkey) already is. "sm" is SpiderMonkey, that is the normal JS engine. v8 is Chrome's JavaScript engine.

Current results on large Emscripten codebases are as follows, reported as factor slowdown compared to gcc -O2 (so 1.0 would mean "same speed")

                   odin (now)  odin (next)  sm      v8
      skinning     2.80        2.46         12.90   59.35
      zlib         2.02        1.61         5.15    5.95
      bullet       2.16        1.79         12.31   9.30

<comment><AUTHOR> I kinda hope that someone at Mozilla keeps a count of just how many monkeys have gone into the code base. Off the top of my head, there's SpiderMonkey, TraceMonkey, JagerMonkey, IonMonkey, ScreamingMonkey, IronMonkey, and perhaps you should count Tamarin. It would be neat to see mascot like versions of them all... :)

<comment><USER12> I've never heard of ScreamingMonkey or IronMonkey, and I'm a member of Mozilla's JavaScript team...

<comment><AUTHOR> IronMonkey was apparently for "mapping IronPython and IronRuby (and maybe IronPHP) to Tamarin". I just vaguely recalled seeing the name pop up in a Mozilla related context -- I certainly couldn't have told you what it was without looking it up. :)

<https://wiki.mozilla.org/Tamarin:IronMonkey>

</comment></comment></comment></comment><comment><USER13> The cool thing is that those of us who have small performance-critical javascript routines e.g. game engines have a whole new cheatsheet of 'optimal' javascript. I can't wait for box2d, octrees and matrix libraries to adopt it; a whole new generation of hand-optimised assembler!

<comment><AUTHOR> Last I read up on it, the version of box2d compiled with emscripten performed a lot better than any of the "hand tuned" js versions! :)

</comment></comment><comment><USER14> Madness! ;) [http://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageFo...](http://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageForTheWebSematicMarkupIsDeadCleanVsMachinecodedHTML.aspx)

<comment><USER9> Don't think I haven't explicitly referenced you in my talks already! :D

<http://vimeo.com/43380479>

</comment></comment><comment><USER15> Reminds me a bit of efforts like C--, which sought to seek a simpler pseudo- assembly used as some kind of intermediate language for compilers. But those efforts never gained much traction, whereas I think that some transpilers actually exploited a few features _beyond_ even normal, full-fleged C -- namely GCC extensions -- to make some features easier and/or faster (it's been a while, but it was probably some trampolining optimization).

Let's see how it turns out.

As for something completely different, I've always wondered how it would be to program a webapp in a rather different language than JS -- most transpiled languages aren't that fundamentally different from JS. And Emscripten seems mostly used to port some code that "runs in a box". Wonder how far one could come doing some stereotypically Web 2.0 things in e.g. Pascal.

<comment><USER16> Elm and Roy are quite different in that they abandon normal js semantics.. as far as going to a more blub language, please do report your experimental results!

<comment><USER17> ClojureScript is also quite different from JavaScript - <http://himera.herokuapp.com/synonym.html>

</comment></comment></comment><comment><USER18> I've become increasingly convinced that a standardized VM in the browser that other languages could target would be the best idea. And we could forget that the whole JS thing ever happened.

<comment><USER19> LLVM byte code in an OS secured jail/sandbox? The JIT is already there and BSD licensed so all the players can use it. You'd really have to trust your sandbox though.

The API for what you what you can do out of your sandbox would be the hard part. Every capability you add to the API is also a lurking attack vector in each implementation.

<comment><USER18> Microkernels in the browser to the rescue :-). But yeah, I had something like that in mind. I do realize that getting security right would be tricky, but I'm not sure if it would be that much trickier than say the security of any given JS engine. Since the semantics of said VM would be probably simpler, I would make the argument that getting the security right would be easier to do than the security of said JS engine.

</comment></comment></comment><comment><USER20> Any thoughts on where this could be useful? The context and purpose of it goes a little over my head.

<comment><USER9> Compilers like Emscripten and Mandreel, which already generate code similar to asm.js, can be modified (we already have it implemented for Emscripten, it's not a big change) to generate valid asm.js. Then engines that recognize it can optimize the code even further than existing optimizations. Some of the technical benefits:

* ahead-of-time compilation and optimization instead of heuristic JIT compilation

* heap access can be made extremely efficient, close to native pointer accesses on most (all? still experimenting) major platforms

* integers and doubles are represented completely unboxed -- no dynamic type guards

* absolutely no GC interaction or pauses

* no JIT guards, bailouts, deoptimizations, etc. necessary

But the bottom line here is: asm.js can be implemented massively faster than anything existing JS engines can do, and it's closing the gap to native more than ever. Not only that, it's _significantly_ easier to implement in an existing JS engine than from-scratch technologies like NaCl/PNaCl. Luke Wagner has implemented our optimizing asm.js engine entirely by himself in the matter of a few months.

As the site says, the spec is a work in progress but it's nearly done. Our prototype implementation in Firefox is almost done and will hopefully land in the coming few months. Alon Zakai is presenting some of the ideas at <http://mloc-js.com> tomorrow, including an overview of the ideas and some preliminary benchmarks. We'll post his slides afterwards.

<comment><USER21> Are there any thoughts on debugging this kind of code? How do we know that the code was correctly treated as asm.js, and if not, can we know why?

<comment><USER9> The code has to be explicitly marked as asm.js, using a pragma similar to ES5 strict mode. This way if the code fails to validate, the errors can be reported to the browser's developer tools.

As for debugging, the story is the same as Emscripten. I believe there's plenty of work to do to make it better, but it's no different than the existing state of affairs. All we're doing is formalizing existing practice so that engines can capitalize on it and optimize better.

</comment></comment></comment></comment><comment><USER22> I like the idea of this, but it bugs me that it still uses doubles and only simulates integers via optimizations in the JavaScript compiler. Why has no JavaScript extension arisen to supply real integers?

One notable side effect of this: asm.js only seems to support 32-bit integers, not 64-bit or larger integers.

<comment><USER23> JS has 'real integers', they're not being simulated. If you put the appropriate hints in your JS the JITted output will never use a float anywhere. Your complaint is more that all the operators (with the exception of the bitwise ones) operate on floats, and yes, that is kind of a problem.

64 bit integer support is being worked on for JS elsewhere; asm.js probably doesn't offer it yet since you can't use 64 bit ints in any browser yet.

<comment><USER9> That's true, but JoshTriplett has a reasonable point. In point of fact, we _are_ discussing custom value types like int32 and uint32, as well as compound value types like immutable records, for the future of ECMAScript:

[http://wiki.ecmascript.org/doku.php?id=strawman:value_object...](http://wiki.ecmascript.org/doku.php?id=strawman:value_objects)

But standardization takes time, and we wanted to get asm.js working now.

In the future if ECMAScript gains these other features we'll happily incorporate whichever ones make sense. For example, if having more straightforward syntax can help decrease code size that's a clear win. (Though gzipping source tends to mask a multitude of sins.)

</comment></comment></comment><comment><USER24> This seems more realistic than Google's grand plans of displacing JavaScript with Dart. Let's hope it gains traction!

<comment><USER25> This would probably help the Dart effort a lot by providing a sane compilation target.

</comment></comment><comment><USER26> It's still a bit surprising that types were never (and still haven't been) added to javascript, as proposed for javascript 2.0 back in 1999: [http://web.archive.org/web/20000817085058/http://www.mozilla...](http://web.archive.org/web/20000817085058/http://www.mozilla.org/js/language/js20.html)

Now we have Google's Dart & Closure compilers, Microsoft's TypeScript, and Mozilla's asm, all of which essentially add types back to javascript, not to mention about two dozen other statically typed javascript compilers: [https://github.com/jashkenas/coffee-script/wiki/List-of- lang...](https://github.com/jashkenas/coffee-script/wiki/List-of-languages- that-compile-to-JS)

If types were approved 13 years ago, javascript apps could have been made to run much faster (fast enough for games even), perhaps negating a need for 'native' mobile apps that we have today, and either hastening the demise or spurring the optimization of competitors like Flash and Java and .NET/Silverlight.

(I'm already aware of arguments against static typing, and against having a VM in the browser or treating javascript like one.)

<comment><USER9> It's a _lot_ harder to add types to a general purpose programming language. Your types have to match actual programming idioms, and if you care about them being safe (which, to be fair, recent languages like Dart and TypeScript don't), you have to consider every possible loophole that could lead to a dynamic error -- and the legacy language fights you, because all of its dynamism was designed back when nobody was thinking about respecting some not- yet-existent type system.

The type system for asm.js is a far more restricted problem, which is why we were able to come up with a solution so quickly (we only started this project in late 2012). The type hierarchy is extremely spartan, and it's just designed to map a low-level language (intended for _compilers_ to be writing in) to the low-level machine model of modern computers.

</comment></comment><comment><USER27> The fact that you can't represent function pointers (not closures, just plain old C-style function pointers) in asm.js severely limits its usability as a target language for even C-like languages.

<comment><USER28> Can you explain the use case where you need need function pointers but closure pointers won't do?

<comment><USER27> Oh! Closure pointers would absolutely suffice. But as far as I could tell, asm.js doesn't support closure pointers either. Obviously I could use a value of "unknown" type to pass them in, but section 2.1.9 says "Since asm.js does not allow general JavaScript values, the result must be immediately coerced to an integer or double."

So I'm under the impression that asm.js can't really deal with closures or functions as values. Am I reading the docs wrong? I _hope_ I am.

<comment><USER29> Looks like it's in the works.

<https://github.com/dherman/asm.js/issues/4>

</comment></comment></comment></comment><comment><USER30> Wow. The devs at Mozilla are really working it.

I mean, with empscripten, Firefox OS, Firefox browser, and now asm.js... they're about to force everyone onto their own terms.

This is clearly a big move and the beginning of a major victory for Mozilla and all users and developers.

Serving native apps, in the browser, with JS. And everyone is going to have no choice but to follow them, because all other browsers will fallback to their regular JS interpretter/JIT if they don't optimize on asm.js.

We're talking games and applications that will run an order of magnitude faster on Firefox than in other platforms out of the gate. But they'll still run everywhere, just very slowly.

</comment><comment><USER31> Any thoughts on whether there could be a JS -> Asm.JS compiler? Might be a handy way to get rid of GC pauses - and maybe even improve performance - <USER2> existing JS code.

Or even a JS -> Asm.JS compiler written in JS... so you can feature-detect and enable on demand :)

<comment><USER3> Yes, you could comple JS to asm.js, but then, unless you change the JS semantics, you'll have to implement a GC, and your GC might have pauses.

Note that an interesting possibility would be to be able to generate asm.js at run-time for a domain-specific language. You could easily implement this as a JS library.

</comment></comment><comment><USER32> Can it still be considered a 'subset' if it adds new traits like 'int' and 'intish'? If it both adds and remove things wouldn't that make it more of a variant like scheme is to lisp?

<comment><USER9> Yes, the observable semantics is 100% identical to running the same code in an existing JS engine. That's the genius behind Emscripten (i.e., the genius of Alon Zakai) -- he figured out that you can effectively simulate the semantics of machine integer operations by exploiting the various parts of the JS semantics that internally does ToInt32/ToUint32 on its arguments.

What asm.js is simply _formalize_ those tricks in order to _guarantee_ that you're only using those parts of the JS semantics, so that it's sound for an optimizing engine to directly implement them with machine arithmetic and unboxed integers. But the behavior is absolutely identical to a standard JS interpreter/JIT/etc.

</comment></comment><comment><USER33> @dherman The document says, "extraordinarily optimizable". Do you have any numbers on that?

I'd love to see benchmarks from running asm.js-compatible JavaScript on e.g. SpiderMonkey versus an asm.js-optimizing SpiderMonkey.

Are we talking about incremental differences of 5%, 25%, even 50%, or orders- of-magnitude improvement?

<comment><USER34> evilpie posted some numbers below: <http://news.ycombinator.com/item?id=5227841> and I'll reproduce the salient points here:

                   odin (now)  odin (next)  sm      v8
      skinning     2.80        2.46         12.90   59.35
      zlib         2.02        1.61         5.15    5.95
      bullet       2.16        1.79         12.31   9.30

<https://bugzilla.mozilla.org/show_bug.cgi?id=840282>

</comment></comment><comment><USER35> Have you guys thought about memory management in the ArrayBuffer "heap"? One can decommit pages from a real heap, which can be a pretty important optimization.

</comment><comment><USER36> What happened with javascript in pypy? I thought they were working on the restricted subset suitable for static analysis.

<comment><USER3> You mean this: [http://www.formal- methods.de/mediawiki/images/e/e5/Bachelor_...](http://www.formal- methods.de/mediawiki/images/e/e5/Bachelor_zalewski.pdf) ?

</comment></comment><comment><USER37> Would asm.js reduce JS memory usage?

Would non computational scripts benefits from this? Things that are widely used like jQuery.

</comment><comment><USER38> Can we please replace JavaScript or use a proper VM instead of this nonsense?

Or better yet, just use native applications.

</comment><comment><USER39> AKA RPython for Javascript

</comment><comment><USER40> Love it. When can we expect a JavaScript to asm.js compiler?

</comment><comment><USER41> first announcement of asm.js in Budapest on @mlocjs

</comment><comment><USER42> Will Javascript become Java?

</comment><comment><USER43> I've had similar ideas back when BlackBerry was popular with its Java-only SDK in order to port our huge C++ app, and also when Windows Phone was C#-only.

Eventually it's worked itself out, as C++ has become available everywhere.

Nevertheless, if they succeed, the same thing can be easily made for Java and C#, so we can make our C++ app ultra-portable.

It will be an absurd toolchain though.

People are so unable to communicate and adopt standards as if they were retarded.

Sophisticated solutions atop idiotic problems.

It's actually the slogan of the overall field.</comment>


Guy Kawasaki: Hindsights - <AUTHOR> http://blog.guykawasaki.com/2006/01/hindsights.html

<comment><USER2> Obviously, the very nature of this site would make most people disagree with #10, so I won't comment. As for #9, I was a little irked he used "joy" to describe Aristotle's eudaemonia.

However, I disagree with #2, beginning with the term he chose to use: "Obey the absolutes." I understand he's trying to say "be a moral person" (in the neoclassical sense), but even regardless if he's right--even if we should "obey the absolutes"--it is improper to start this tenet with "obey." For one, let's face it, we all know the moral sphere is not black and white as described in his comments on #2. However, "obey" implies thoughtlessness regarding one's moral behavior, because these "absolutes" are then taken for granted for societal and biological reasons (respectively popular conceptions of good and evil, and conscience, a largely biological instinct). Of course, we weren't all meant to be moral philosophers, but some consideration of one's moral system is still pertinent to everyone.

Besides that, some of these are fairly standard and self-evident guidelines, albeit targeted to (in content and phrasing) lay people (i.e., eight-to- fivers, pardon the term).

</comment><comment><USER3> I've read a few of Guy's books including Hindsights and, out of them all, Hindsights is the one worth skipping for sure. This is just Guy trying to sell more copies of that book. I'm sure some people enjoyed it but I didn't.

</comment><comment><USER4> > You are going to work the rest of your lives, so don't be in a rush to > start.

Yikes! What a downer. Doing stuff to pay bills does not have to mean "work". Dopey.

</comment><comment><USER5> > _I was a diligent Oriental in high school and college._

Orientals are objects. Asians are people.

> _Frankly, smoking, drugs, alcohol--and using an IBM PC--are signs of > stupidity. End of discussion._

Probably the majority of creative people in the history of the world have used drugs of some type. In fact, that's how we got some of our finest literature and works of art.

IBM PC? Is he still stuck in the 80s?

> _There absolutely are absolute rights and wrongs._

"The law, in its majestic equality, forbids the rich as well as the poor to sleep under bridges, to beg in the streets, and to steal bread." -- Anatole France

Guy was just a PR flack for Apple which happened to net him a lot of face time and even magazine covers. He doesn't "Think Different", he just got a marketing job and talked up his employer. Fini.</comment>


Is IE9 a modern browser? - <AUTHOR> https://people.mozilla.com/~prouget/ie9/ie9_vs_fx4.html <comment><USER2> At this point the thing that needs to change is organizational. It doesn't really matter how good IE9 is, what really matters is when and how the updates are released. If they keep "modernizing" themselves (if it is even that) every 3-4 years they are still doing it wrong.</comment>


Learning to hack, one month in - <AUTHOR> http://franceschine.com/post/23988696668/learning-to-hack-one-month-in

<comment><AUTHOR> Anybody know of a Udacity like course for learning Ruby? Would like to tackle that next.</comment>


A Simple Twitter App with Ruby on Rails - Messages With Ajax - <AUTHOR> http://www.noupe.com/ajax/create-a-simple-twitter-app.html <comment><USER2> The title is misleading - I thought this was a link to a twitter mash-up, not a "how to learn rails" tutorial that has nothing to do with twitter.

<comment><USER3> "...not a "how to learn rails" tutorial that has nothing to do with twitter."

Nothing to do with twitter, except that IT IS TWITTER :)</comment></comment>


The advantages of distributing a JavaScript lib with URL instead of NPM - <AUTHOR> https://medium.com/thron-tech/the-js-library-distribution-dilemma-npm-or-url-c63aa5842a4c <comment><USER2> NPM has become a ubiquitous standard at this point, not using it doesn't make any sense.</comment>


Terrastore - Scalable, elastic, consistent document store - <AUTHOR> http://code.google.com/p/terrastore/

<comment><AUTHOR> The description given on their Google Code page seems a bit sensationalistic to me. The author has a bit more reasonable look at the features and tradeoffs here: [http://sbtourist.blogspot.com/2009/12/terrastore-and-cap- the...](http://sbtourist.blogspot.com/2009/12/terrastore-and-cap-theorem.html)

<comment><USER2> Call it "marketing" ;) Joking aside, the article you mentioned is linked on the home page for that exact reason: put things in the correct context.

<comment><AUTHOR> No insult intended at all. It was just that as I was reading down that list my brain was screaming "CAP! CAP!". I was glad to find that link there. Looks like an awesome project.

<comment><USER2> Sure, I was just kidding. Thanks for your kind words, hope you'll find it useful.

</comment></comment></comment></comment><comment><USER3> It looks like the complement to CouchDB: it actually implements all the hard distributed stuff that CouchDB never delivered on, but doesn't implement any of the fancy stored procedure stuff that CouchDB actually pulled off.

If only I could have the chocolate _and_ the peanut butter together...

<comment><USER2> Terrastore already implements lightweight "stored procedures" in terms of server side updates: functions which atomically update a value based on some custom logic.

Future versions will provide map/reduce functions as well, probably in both Java and Javascript.

</comment></comment><comment><USER4> I wonder how much of that he got almost-for-free just by using Terracotta?

Terracotta itself is in effect a transparent ACID object database where collections can be larger than RAM and objects can be accessed efficiently on one machine or shared and updated in implicit transactions.

<comment><USER2> Clustering and storage are completely based on Terracotta, and this is great: relying on a rock solid technology gives you the freedom to focus on more advanced features, such as communication, partitioning, data manipulation and querying.

Which is the same reason Voldemort and Riak rely on third-party storage, or HBase relies on Hadoop.

<comment><USER5> In fact Terastore is based on Teracotta is one of the most important aspects. This makes us comfortable to see similar performance in numbers related to clustering, storage. Same is true for MemchacheDB, Voldemort and Riak as Sergio mentioned.

<comment><USER2> Exactly: clustering and storage are more and more "commodity" features, as I see it. The most important thing is going to be _what_ you build upon them, the real value you provide to the user: is data partitioned or replicated? What data manipulation features are provided? And so on ...

</comment></comment></comment></comment><comment><USER6> At first glance it seems like a java version of couchDB on top of a clustering system.

</comment><comment><USER7> Sounds like this is a lot more closer to MongoDB than CouchDB. Either way, I warmly welcome this to the document store world</comment>


California bill will drive a national debate over how to reshape labor laws - <AUTHOR> https://www.nytimes.com/2019/09/12/opinion/california-gig-economy-bill-ab5.html <comment><USER2> The way to reshape labour laws is to offer an alternative job defining the socially minimum acceptable job in a local area.

Business then has to compete with that to attract labour. No other labour law required. Simple competition sorts it out.

That is also has the advantage of being a geographically targeted federal automatic stabiliser that operates far more effectively than interest rate targeting via bank lending, and ends unemployment permanently and forever is just an added bonus.

<comment><USER3> No what you really need is federal binding minimum standards for Annual leave (4 weeks ) and Sick pay and minimum wage.

Repeal all the right to work laws and massively reduce the ability of employers to use non compeats (us CA as a model here I think)

<comment><USER4> How do you decide who qualifies for four weeks pay? that is a significant cost to many small businesses. Do you limit it based on how many employees they have? How many hours the employee averages per week? The last time Congress set limits they threw low wage earners under the bus; the now infamous ACA twenty nine hour rule.

minimum wage should not be at the federal level, it is a state by state and city by city issue that should be based upon cost of living in that area. federal laws should protect from working without pay and discrimination. if localities wanted to protect low wage earners they woulds step back occupational license requirements for many positions and reduce the burden of fees and regulatory compliance as well; that twenty to twenty five dollar fee some states charge just for a license may not be bad for you or me but for the low wage earner it is very bad. having to pay five hundred dollars for a license to work is no better, but these costs exist and are not income scaled

<comment><USER5> > How do you decide who qualifies for four weeks pay?

You don't. Every full-time employee have right to paid holidays, like we have in every other country in the world.

<comment><USER6> That leads to less full-time employees. People will get their hours cut.

Maybe we need to consider someone who works more than 15 hours a week full time. Or perhaps the benefits scale for employees based on number of hours worked.

<comment><USER7> The US is pretty much the only developed country without mandatory vacation time. This is a solved problem. Just look around how other countries do it.

<comment><USER6> If it's such a bright idea, why can't NY and CA do it? They're literally the size and population of many other countries. In the US, the states are free to do whatever they want with wage and employment laws, so long as it doesn't violate the constitution. If CA wants to set the minimum wage to $30/hr + 2 weeks mandatory PTO, they are 100% free to do it. It's pretty much a single party state at this point.

Other countries are able to support higher labor rates because they have protectionist tariffs, such as the VAT. But if the US wants to raise tariffs, all of a sudden we're racist idiots.

Anyway, a lot of what's perceived to be wrong with the US can easily be solved at the state level, but turns out nobody actually wants to foot the bill for these things.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> So "feudalism" = "things I think are bad?"

The gig economy has many, many downsides, but those downsides don't share much at all in common with feudalism, even by analogy.

If we let all words deteriorate to mean simply "good" or "bad" (with gradations of good or badness), we're barely communicating.

<comment><USER9> We could even take an additional step on the path of honest communication and instead of "good" and "bad", say "things I like" and "things I dislike".

<comment><USER10> That's not the same thing. I like ice cream but it's bad for me. I don't like having to pay for it but it's probably good for society that ice cream makers are rewarded for their work, at least if I want to be able to eat more in the future. The world would be a literal paradise if doing thing we like and doing good things were always one and the same thing. I don't see how you can discuss morality and ethics without "good", "bad", "right" or "wrong".

IMO the problem with modern political discussion (especially online) isn't vocabulary, it's lack of nuance and empathy. "Good" and "bad" are not really the problem, but rather when you _only_ classify things are either completely good or completely bad with no middle ground.

<comment><USER9> You are using the word "bad" equivocally. Bad as in "bad for your health" is one thing (no problem with that), bad as in "eating ice cream is morally bad" is quite another. What would the claim that eating ice is morally bad even mean?

All I'm suggesting is that we take care in our language and be up-front about subjectivity rather than mask it with objective-sounding reifications. This isn't an attack on morality nor its importance, rather it is an acknowledgment of the fact that such judgments are ultimately based on what we as individuals or as a society find acceptable or unacceptable (i.e., like or dislike). It is perfectly possible to have a strong sense of ethics without claiming that one's ethics are somehow objectively or empirically "true".

<comment> false-mirror Moral relativism does not negate good/bad/right/wrong to the point that they are equivalent to "like" and "no like". That is a radical reduction, and removes the whole process of moral reasoning people use to live a moral life.

There are plenty of examples where the "right" thing to do is not pleasant, it is not socially acceptable, etc because it is instead congruent with a greater ethical structure. Please check out some moral philosophy before throwing the whole field into a bin.

</comment></comment></comment></comment></comment><comment><USER11> Good.

People forget the past all too easily. It took a lot to get us the protections we have today. Giving them up so easily is a mistake.

For those thinking this is overreach and stifling innovation you need to look back at history and realise the same thing could be said about many commonplace workers rights that you take for granted now.

<comment><USER12> The fact that you're bing down voted is beyond me.

My wife describes engineers as 'smartdumb'.

We're super smart at figuring out technical solutions that enable things like social media, ridesharing and short term rentals.

But we're either willfully ignorant or just plain dumb about the second order effects on society.

And you know what you call it when people discuss the social good? Politics.

That very thing that coincidentally we're not supposed to talk about on this site.

<comment><USER13> Seeing people say things like "Simple competition sorts it out" as if any complex problem can be answered like that. We should really know better, given our field.

Also interesting that basically anyone saying anything mildly critical of capitalism is getting downvoted without much response

<comment><USER14> I'm open to thoughtful, constructive criticisms of capitalism. Mostly what I see is "capitalism allows for some to slip through the cracks, so let's burn it all to the ground and start over with system that has only ever failed catastrophically (or in the words of its proponents, 'has never truly been tried before')".

<comment><USER12> I see literally no-one one this site suggesting we go to full communism, if that's what you're implying.

Carefully regulated capitalism should do fine. This is obviously not easy to achieve.</comment></comment></comment></comment></comment>


Show HN: Beautifully crafted code snippets with Kickdrop - <AUTHOR> https://kickdrop.me

<comment> D-Train Oh, wow, this is pretty slick! I like being able to see a demo of the drops.

Is your plan to open the code or marketplace up so others can build other drops, and do a revenue share?

<comment><AUTHOR> We'll be accepting applications to be come a contributor very soon. This will include details on the benefits of contributing.

Thanks and keep checking back!

<comment> D-Train What are the next planned drops? Will they be free or paid?

<comment><USER2> Hey D-Train,

I'm on the Kickdrop team. We will always be releasing free drops for our users. That's something that will never change. From time to time, we will release premium (paid) drops. These will be drops that we've put a little more sweat into, and will be the best content we can provide. Thanks for asking!</comment></comment></comment></comment>


Gunk: Modern front end and syntax for Protocol Buffers - <AUTHOR> https://github.com/gunk/gunk <comment><USER2> I'm not seeing what makes this "modern". proto3 is only a few years old and nothing about it strikes me as unusually archaic. Protobuf in general isn't that much older than Go. I can see why Go-compatible syntax would be attractive to Go developers, so maybe that should be in the description rather than "modern"?

<comment><USER3> There is a semi-consensus that Proto3 was created to be compatible as Go basic types. Making Go types from Protos, or Proto types from Go is what is being entertained as modern.

<comment><USER2> Proto3 has features (discussed elsewhere in these comments, like oneOf) that aren't present in Go's type system. I'm not clear on why constraining it so it's more narrowly compatible with a particular implementing language is more modern.

It would be useful to see an example of the workflow of using this tool compared with the equivalent workflow while using protoc. That would be a selling point, while "modern" is just a sticking point.

</comment></comment></comment><comment><USER4> Not sure why I'd want to define a language independent interchange format in a language specific way and remove all of the tooling help at the same time. Why is this better? A why section/motivations would help greatly.

<comment><AUTHOR> There is an explanation in the README file, but I'll explain:

It helps to standardize workflows across a number of different source repositories (all Go based), where a number of different developers had come up with different ad-hoc ways of generating code against protobuf definitions. Since the syntax is Go-derived, it reduces cognitive load for developers when specifying protocol buffer definitions. We understand that it may not be for everyone, but it works for our team.

<comment><USER4> Why not just make a simple go tool that just covers that issue and still uses proto thus getting the tooling and expressiveness instead.

</comment></comment></comment><comment><USER5> I'd be interested to see a "why?" section in your docs. In general I think making new "skins" for the same underlying tech is not a good thing. It fragments the ecosystem without any real business purpose. Is there some problem this addresses that is not already solved equally well by proto2 or proto3, besides that it doesn't look like a particular programming language?

<comment><AUTHOR> Yes, this has the added benefit of standardizing protocol buffer based workflows across teams / repositories. I appreciate the criticism, but we (the Brankas developers) find this syntax significantly easier to use, as well as the tooling provides a better mechanism for using other protoc generators.

</comment></comment><comment><AUTHOR> We just pushed the first initial, public release of Gunk, a modern frontend and syntax for Protocol Buffers.

Check out releases here: [https://github.com/gunk/gunk/releases/tag/v0.1.0](https://github.com/gunk/gunk/releases/tag/v0.1.0)

Please note this is still extremely early / alpha stage, but we are soliciting feedback on our initial design. We hope to make this project useful to the greater developer community.

<comment><USER6> Protobuf has first class enum support and also provides a thing called "oneof". Go doesn't have anything of this. So, it is clearly not the right tool for the job. Sorry guys, you are wasting your time sticking to Go constructs only.

<comment><AUTHOR> Thanks for the input -- this actually does support enums, using a variant of Go's const:

        type MyEnum int

        const (
            MYENUMVAL MyEnum = iota
        )

It's a philosophical argument, but one should not design a protocol using "oneof". I believe that's a relic from proto2, and I'm not aware of any modern APIs published by Google, that make use of "oneof" in anything but a legacy capacity. Gunk is not for old protobufs, it's for new development. It works with and integrates cleanly with existing protobuf definitions.

<comment><USER7> I'm curious, in your view, why should protocols not use "oneOf"?

<comment><USER8> Not GP commenter, but a lot of the decisions to remove explicit optionality and requiredness from protocol buffer is that it made pb too complicated to change when you wanted to make a field required or optional, so they punted with 3 and said "do this in service logic"

I think the feeling is that this is the realm of business logic, and a protocol should be simple and fast and not concern itself with the rules part of the underlying service.

Oneof seems to fall under the same concept, where it says "one and only one field from this list" when they can just as easily do that in service or client logic (three fields, documentation and a server response custom written as to the WHY of oneof relationship)

<comment><USER9> I can't follow that argument, as it seems to apply just as much to wanting to change the type of a field, the name of a field or just making changes in general. Maybe I deal with relational databases too much, but I really miss being able to declare fields required and provide default values, because now instead I have to document, trust others will read the documentation, and provide explicit error handling for when constraints that used to be validated client side or server side by protobuf. I also miss not having a NULL value, but protobuf never had that and almost certainly due to dealing with too many relational databases ;)

If I lose oneof too, I might as well be using JSON.

<comment><USER10> Your points are valid, but ultimately an API is defined by its semantics in addition to data types. For anything beyond extremely primative RPC, you have to read the docs anyways.

Moving to proto3 means putting all your validation in one place, your serialization primitives in one place, and your docs in one place, instead of smattering them all over. It's a _lot_ less error prone and way more maintenance friendly.

<comment><USER11> Why is `// required, the server will respond with a failure if this argument isn't provided` in the .proto file enough documentation? That's usually what I go to.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> I don't understand the purpose. The existing proto syntax is both easy to learn and language agnostic.

I've watched new devs pick it up in a matter of minutes.

</comment><comment><USER13> "Modern"?</comment>


Ask HN: How to find the perfect coder?  - <AUTHOR>

I'm currently working on a project that needs a custom shopping cart.
What should you look at when your choosing to work with a coder?
Where is the best place to find one? <comment><USER2> As a non-coder, it's tough to evaluate how competent a coder may be. For that reason, here's my answer to your second question: recommendations.

I personally recruit straight from the universities. Then again, I don't go the traditional route of posting on job boards. How do I know if the candidates are qualified? Anybody can draft a nice resume!

I go straight to the professors. Who knows each student better than their own professors?

You describe what you're looking for, and they'll point you in the right direction!

-adam

</comment><comment><USER3> Look for personal blogs. Doesn't really matter if thy post once a month or once a day, as long as the quality of what they post is good and they seem knowledgeable. Take a look in their Twitter stream, it can speak for a developer lots of times (though don't use it as your only metric!).</comment>


U.S freelancers pretend to be from other countries to get jobs - <AUTHOR> http://blog.cubeofm.com/us-freelancers-are-pretending-to-be-from-phil

<comment><USER2> If they can't get jobs for more than $200 they're either terrible programmers, or they need to look for work on places other than rentacoder. Probably both.

EDIT: To be clear, I meant to say that if they can't get jobs making more than $200 _for two weeks of work_ , they're either terrible or need to look elsewhere for work. Further, I'll put my money where my mouth is: if you want to make $5 / hr and you can write good code, email me and I'll give you all the work you can handle. I'm guessing I won't have any takers.

<comment><USER3> Yeah I'm completely perplexed by this. I'm not questioning the guys article, but there's got to be more to it then we are reading. $200 for a two week project is $5 an hour if you only work on it 4 hours a day.

Even in the current economy any halfway decent programmer should be able to pull in more than minimum wage.

<comment><USER4> I'm questioning the guys article, I think it's either an anomaly or a fabrication.

<comment><USER5> I have the same reaction to many of the items maxklein posts. And he has said in the past that he engineers his postings for the effect on the audience...

That said I know more than a few people who use rent-a-coder or odesk as a way to motivate themselves when learning a new language or toolkit.

<comment><USER6> That's a _brilliant_ concept: nothing teaches you something like a real project, getting paid, even a pittance, helps all the more, and you can put it on your resume honestly.

</comment></comment></comment></comment></comment><comment><USER7> We are looking at the beginning of the "World Wage".

In virtual labor, the effect of the recession is going to be a major fluctuation seeking equilibrium between the NYC/CA USA-based $100/hr coders and the Everywhere Else-based $15/hr coders. As people get better at virtual work and clients & employers become more conscious of the value deflation of quality code work people in the US will start fetching less and less and people outside the US will start fetching more and more, until they meet in value. Watch.

<comment><USER8> This presupposes that you're selling the same hour in NYC and Bangalore. (i.e. that when you measure what is produced, it is equivalent.)

I do not live in either a $15/hr or $100/hr region, but I've managed people from both, and it has not been my experience that the hour sold is the same as the hour bought.

</comment></comment><comment><USER9> I see the logic in taking a small job just to keep busy. I did the same thing right after the dot com bust 8 years ago: I took a task from an Indian company to do a Sharepoint clone in Java at a fairly low rate with the understanding that I could set their work aside for a few days at a time when better paying work came along. I never regretted that decision, partially because the guy who hired me was a one time McKinsey manager and he was cool to work with. I live in the mountains in Arizona, BTW, so I do a lot of remote work.

</comment><comment><USER10> I suppose that if you're an unemployed programmer in the US doing something like this might at least keep you engaged and your skills up to date, even if the money isn't enough to pay the bills.

<comment><USER11> And or learn something new while getting paid to do it.

</comment></comment><comment><USER12> May be these developers are able to re-package their pre-existing code in couple of hours? Then these $200 are turned into $100/hour which looks like a reasonable business model.

<comment><USER13> That's very likely. It's also possible the jobs are easy enough that they just do it in fewer hours.

I was once offered a $3000 contract (at $20/hour) for a project that amounted to stringing together a few generic views and writing a python wrapper around some C++ code.

The job didn't work out for various reasons (I offered to build on spec, they wanted a low hourly rate). If I were telecommuting, I could have spent a day or two building it, wait 2 weeks before delivering it, and pocket $3000 for a days work.

</comment></comment><comment><USER14> I live in Argentina, and here companies are crazy about hiring IT people, no matter what your skills are, and most of them do offshore work for the US, paying barely standard fees here and cashing big there. Don't think have to say who wins and who loses with this practice. Have been thinking lately about this and believe one solution would be to equalize developer fees 'round the world, rise the bar and compete on performance. I know it sounds crazy, but have some ideas on things we could try to work this out. I'll post them here if you think it worths anything.

<comment><USER15> Why don't you start such a company then? Seems like an opportunity. You have access to a pool of people who need developers right here on this site.

<comment><USER16> I'm not the above poster, but I'm in Uruguay... and, to answer your question, I probably will :)

</comment></comment></comment><comment><USER17> I guess the real question is: Are these people really able to take enough projects at the cheaper price level to survive? How about thrive?

If they are only 'getting by' at the cheaper level, then it's a fair assumption that they will move on to bigger and better things if they ever come along. If they are able to thrive, then assumptions about the economics of taking these cheaper jobs is grossly misunderstood.

</comment><comment><USER18> These people should just move to the countries they are pretending to be from then. $200 goes a lot farther in the Philippines than it does in the U.S.

<comment><USER19> That's one of the reasons I'm moving to southwestern China this fall. Making freelance/telecommute USD will enable me to live quite nicely in Kunming.

(PS if anyone needs an experienced Rails/Java/Python/whatever-you-need-me-to- learn coder and can deal with a 9-12hr time difference, my contact info is in my profile)

<comment><USER20> When you are selling yourself in the future, absolutely do not call out a negative in your ad.

The number one rule of advertising is be positive, always.

<comment><USER21> I am a bit confused. What does calling out a negative mean and where was he doing it? Or are you referring to the OP?

<comment><USER20> He pointed out there was a 12-hour time difference, which would be inconvenient.

<comment><USER22> Not really. It's kind of expected when off-shoring.

</comment></comment></comment></comment></comment></comment><comment><USER23> I am _so_ reminded of this quote from _Snow Crash_ :

"... once the Invisible Hand has taken all those historical inequities and smeared them out into a broad global layer of what a Pakistani bricklayer would consider to be prosperity–y'know what? There's only four things we do better than anyone else

music

movies

microcode (software)

high-speed pizza delivery"</comment>