devongovett

pdfmake is based on my PDFKit project http://github.com/devongovett/pdfkit, which does the actual PDF generation under the hood. pdfmake is a layout engine on top of PDFKit supporting a nice declarative json document description format.

This is great. Can't wait for the WebGL version ;-)

Also, it would be really cool to run everything except rendering in a worker thread and send rendering commands to the UI thread, like react-native does.

Yup, author of that post here. I was pretty surprised to see the vaporware of 2 years ago come alive this morning. http://badassjs.com/post/73526882798/webkit-js-its-happening...

Good point. I changed the link in the post. Might take a few minutes for the caches to clear.

Super cool. I just submitted a pull request to jsmpeg to move some of the RGB conversion stuff to the GPU using WebGL. Reduces CPU usage by 5-10%. https://github.com/phoboslab/jsmpeg/pull/1

See also: http://devongovett.github.io/png.js/ code: https://github.com/devongovett/png.js

also works in Node (png-js on npm) if you want raw pixel values there.

Article about this on badass javascript from over a year ago http://badassjs.com/post/16583192105/seriously-js-a-realtime...

And for completeness, the response from the MongoDB team. https://news.ycombinator.com/item?id=3202959

Oops. Good catch. Thanks!

If you're interested in helping out, join #reader on freenode or send pull requests! :)

I'm working on an opensource implementation of the API here if anyone is interested in helping out :) https://github.com/devongovett/reader

Yeah, that's the position of Google's NativeClient project. But it's not backwards compatible with older browsers, which is the reason for doing this how they are. asm.js will run in any browser supporting JS already, and will be faster in browsers supporting the optimizations. It's not perfect, but it works now.

Well luckily you don't have to write it. Use a compiler that can generate it for you. It's not really designed for humans.

Interesting. I did find it pretty fast or I wouldn't have written that. I was using Chrome 24 on Mac OS X 10.8 on a 2010 i5 MacBook Pro, so my computer is definitely not the latest and greatest. I guess there must be some difference between the rendering engine on the Mac and on Linux, but I don't know enough to say what.

Yes it says so here http://my.opera.com/ODIN/blog/300-million-users-and-move-to-...

No you can only edit projects you create. Public projects are view only.

Payments to users is a HUGE deal for lots of services. Really happy to see that.

Check out the demo. It definitely contains javac http://int3.github.com/doppio/

My thoughts on Badass JS here: http://badassjs.com/post/32674515997/typescript-microsofts-n...

Demo here: http://labs.official.fm/codecs/aac/ and a quick blog post here: http://labs.official.fm/articles/2012/07/09/adding-aac-js/

The CPU usage seems to increase while the audio file is being downloaded from the server as well, which might explain why it was initial 10% and then dropped to 6%. We'll look into that more. When decoding from a local file, I've seen flac as low as 3.5%.

Interesting, it runs at about 4% to 5% CPU in Chrome here. Did you have the dev tools open? That seems to disable a lot of the JS optimizations that Chrome has.

I think it's memory for now, but I'm hoping for an IndexedDB backend as a polyfill for WebSQL. As for non-blocking... that's what Web Workers are for :)

As far as I know, no one has built that yet. But just because canvas allows a greater degree of flexibility, I think it's a worthy experiment for someone to do.

Seriously? Google Docs is nothing compared to any native word processor. Just look at Apple Pages or Microsoft Word. The kinds of layouts and power you get from those tools is way beyond what anyone has ever been able to do in the browser.

Secondly, yes Google Docs uses HTML for their UI, but it's seriously abstracted I believe as Google Closure though I may be wrong. My point is that HTML and CSS can still be used, but they need abstractions for this type of app. Canvas is just another approach to the same problem.

Yup, and canvas is just a part of that. It gives control back to the web developers and allows us to create anything we want without waiting for browser implementations. IMO, HTML and CSS are fundamentally not designed for building this kind of app, which isn't really a solvable problem without inventing something new anyway. Either that or we abstract them to make working with them easier.

Right. I'm not saying it's perfect, just that it's an option worth exploring. HTML and CSS simply weren't designed for applications. They're great for documents, but it turns out that using them for this style of application ends up causing a lot of trouble later on as the applications get more complex. Abstractions can help with this, and once it is abstracted, it shouldn't really matter what the rendering backend is. Could be DOM or canvas in the browser, and as this project is showing, various native backends as well. I think that's really powerful.

Sorry, but those things are totally different. Applets and flash are plugins - proprietary additions to browsers that live in a black box. Canvas is a standard, and is part of the browser itself. HTML and CSS don't need to be replaced for most things, but this is an interesting experiment to see whether for a certain class of applications, canvas can outperform the DOM and take care of some of the cross browser issues that CSS is plagued with. I don't get why people are so attached to HTML and CSS.

That doesn't make any sense. Canvas is a standard maintained as part of HTML5 by the W3C. How are they "not really using HTML5"? Just because they don't have some tags? That makes no sense. The web is not HTML and CSS. People need to get over that.

As for semantics and stuff, this isn't designed for documents at all, which HTML is perfectly suited for. This is designed for native-style applications in the browser where semantics don't really mean anything anyway. And like I said in my article, accessibility is taken care of.

Except it's entirely standards based. Canvas is part of HTML5 and the apps are built entirely in JavaScript. And the whole framework is open source with no proprietary components. Not sure how you got to those conclusions.