Slowloris: high-performance HTML5 UIs(github.com)
github.com
Slowloris: high-performance HTML5 UIs
https://github.com/petehunt/slowloris
9 comments
Slowloris is also the name of a deny of service tool: http://ha.ckers.org/slowloris/
Yeah - I would say they should have considered the name a little more, and looked to see what was using the name Slow Loris before putting this out... Whenever I am talking about DoS attacks on webservers, SlowLoris comes up, and this will just add to the confusion.
(Thanks, Captain Hindsight!)
(Thanks, Captain Hindsight!)
i was confused as well. (but this seems like a nice tool nevertheless)
Moved the repo to https://github.com/petehunt/loris
Thanks for the heads up!
Thanks for the heads up!
[deleted]
Oops :/ When I googled it I just got wikipedia articles!
Why would you name this after a type of HTTP DoS attack?
It's actually an animal https://en.wikipedia.org/wiki/Slow_loris
The timing of this is funny, since I spent the last five days splitting Blossom[1] into two threads, a UI thread which runs on the "main" JavaScript thread, and an Application thread which runs in a dedicated web Worker (it's also possible to have multiple Application threads, for app plugins, which was part of my goal).
Anyway, at least for modern MVC development, I've gotten Blossom booting in a Worker, and I've worked through how to split it up so that it's still a "normal" MVC app, but event handling, animation, and rendering is 100% on the UI thread, and all business logic, model layer storage, network communication, and application state management is on the Application/Worker thread.
My primary goal is to make Blossom's requestAnimationFrame()-driven, canvas-based UI thread rock solid at 60fps, even for JavaScript-driven animations, and to place all potentially long work (> than 2-3 ms) in the Application/Worker thread.
This technique is applicable in all modern browsers (IE 10, Chrome, Safari, mobile Safari/iOS, Chrome on Android, and Firefox), and of course in IE 6-9 with Chrome Frame installed.
This approach will also use up to three CPU cores (the third in Blossom is invoked by the automatic application of hardware-accelerated CSS transitions in Blossom, which are executed by the browser on their own thread as well), and even more cores can become involved when plugins are added to the scheme, in their own dedicated workers.
[1] https://github.com/erichocean/blossom
Anyway, at least for modern MVC development, I've gotten Blossom booting in a Worker, and I've worked through how to split it up so that it's still a "normal" MVC app, but event handling, animation, and rendering is 100% on the UI thread, and all business logic, model layer storage, network communication, and application state management is on the Application/Worker thread.
My primary goal is to make Blossom's requestAnimationFrame()-driven, canvas-based UI thread rock solid at 60fps, even for JavaScript-driven animations, and to place all potentially long work (> than 2-3 ms) in the Application/Worker thread.
This technique is applicable in all modern browsers (IE 10, Chrome, Safari, mobile Safari/iOS, Chrome on Android, and Firefox), and of course in IE 6-9 with Chrome Frame installed.
This approach will also use up to three CPU cores (the third in Blossom is invoked by the automatic application of hardware-accelerated CSS transitions in Blossom, which are executed by the browser on their own thread as well), and even more cores can become involved when plugins are added to the scheme, in their own dedicated workers.
[1] https://github.com/erichocean/blossom
Off topic, but according to [1], web workers have not been available in Android Browser since 2.1. There's a SO Question [2] about this, which points to [3]. Seems crazy, when Chrome for Mobile does support it [4].
1: http://caniuse.com/webworkers
2: http://stackoverflow.com/questions/7523745/why-was-html5-web...
3: http://code.google.com/p/android/issues/detail?id=10004#c7
4: http://www.google.com/intl/en/chrome/browser/mobile/
1: http://caniuse.com/webworkers
2: http://stackoverflow.com/questions/7523745/why-was-html5-web...
3: http://code.google.com/p/android/issues/detail?id=10004#c7
4: http://www.google.com/intl/en/chrome/browser/mobile/
Web Workers are available in Chrome for Android (which requires Android 4.0 or greater).
They work fine, e.g. on the Nexus 7.
They work fine, e.g. on the Nexus 7.
However, the problem with Android is version fragmentation - a lot of users have phones that they can't trivially upgrade to ICS, and therefore can't use Chrome for Mobile/Android. Asking someone to root their phone and install a custom ROM, and then install a different browser is a bit crazy if you ask me.
True, but both Firefox for Android and Opera Mobile support web workers and work on Android 2.2+. Installing an ICS rom is wholly unnecessary.
ChromoZoom (http://chromozoom.org) uses web workers to offload custom track drawing to a background thread. If all the data processing were done on the main thread, the UI would stall. However, unlike this library, I don't rely on passing all the JS to an eval() on the worker thread; I have the worker and the main thread load the same code, and refer to the methods by name. This makes it easier and more organized, IMO, when dropping back to non-web-worker operation.
https://github.com/rothlab/chromozoom/blob/master/js/CustomT...
and the top 135 lines of
https://github.com/rothlab/chromozoom/blob/master/js/CustomT...
show how we do it.
https://github.com/rothlab/chromozoom/blob/master/js/CustomT...
and the top 135 lines of
https://github.com/rothlab/chromozoom/blob/master/js/CustomT...
show how we do it.
I just started lazy-worker, a project to allow you to code to the web worker API even on browsers that don't support it.
https://github.com/bgrohman/lazy-worker
With Slowloris, I'd be concerned about having to write my code in strings that get evaled. @peterhunt, what do you think about using lazy-worker as a shim in Slowloris?
https://github.com/bgrohman/lazy-worker
With Slowloris, I'd be concerned about having to write my code in strings that get evaled. @peterhunt, what do you think about using lazy-worker as a shim in Slowloris?
I wrote a similar library for abstracting client-side threading called Commune.js:
https://github.com/dmotz/commune.js
It takes a different approach and avoids using eval.
https://github.com/dmotz/commune.js
It takes a different approach and avoids using eval.
Why use this over a polyfill like http://code.google.com/p/fakeworker-js/source/browse/src/jav... ?
Interesting, I haven't seen this polyfill. I just started a similar project:
https://github.com/bgrohman/lazy-worker
https://github.com/bgrohman/lazy-worker
It would be great if there's an online demo or something.
Just put it up at http://www.petehunt.net/slowloris/example.html.