Slashdot Mirror
Next-Gen JavaScript Interpreter Speeds Up WebKit
JavaScript is everywhere these days. Now WebKit, the framework behind (among others) Safari and Safari Mobile, as well as the yet-unreleased Android, is getting a new JavaScript engine called Squirrelfish, which the developers claim provides massive speedups over the previous one. The current iteration of the engine is "just the beginning," they claim; in the near future, six planned optimizations should bring even greater speed. With JavaScript surviving as a Web-page mainstay despite many early gripes, and now integral to some low-powered mobile devices, this may mean many fewer wasted seconds in the world.
I cannot wait to get this on my iPhone. I would like to see some more in depth information about how this compares to tamarin though. If it truly is better than tamarin, I wonder if mozilla would consider swapping it for squirrelFish. As an aside, that is an awesome logo...
...how does this compare to Tamarin? With Javascript running for longer periods of time, a runtime-optimizing JIT seems to make a lot of sense. SquirrelFish's optimized bytecode engine sounds interesting, but I can't help but feel that it's going to fall short in the next-gen race for Javascript performance.
:-)
Of course, anything that improves JS performance in browsers (making some of the libraries faster and/or hardware accelerated always helps... hint, hint!) is a win for the consumer. And from that perspective this sounds very interesting.
Javascript + Nintendo DSi = DSiCade
as I'm sure we can all find plenty of other places to waste the seconds saved :P
What's next? rabbitelephant? curvaceous coelacanth? fishfishfishrabbitfish? We desperately need an automatic "hip open source software name generator" before someone gets hurt.
Yay! With Tamarin now we can all ditch Apache and go with the Firefox Plain Old Webserver extension....
Although Opera is proprietary as well as its Presto rendering engine, I think that it is very much more powerfull than WebKit's, because it isn't that bulky and you can have Opera for almost any device in the world from mobile phones to the Nintendo DS.
This still isn't going to fix the fact that (X)HTML pages are transported and managed by what is still fundamentally a stateless protocol, XMLHttpRequest and AJAX notwithstanding.
Every time you click a button that triggers a server-side transaction, the page needs to explicitly transmit info - a cookie, GET/POST variables, something - back to the server to "remind" it of its current state.
To me, this would seem to be where most of our time is wasted...
I think all the future web browser should have a standard javascript and CSS, plug-and-play function, allowing users to choose their favorite javascript interpreter and CSS interpreter. For instance, I like Safari's javascript interpreter, but firefox CSS interpreter.. then I can just get those plug-in and put it in my browser (which have a built in HTML interpreter.)
Can anyone tell me if this will hit Konqueror in the new KDE?
I've been running KDE 4.1 through debian experimental. Buggy right now, but no show-stoppers. KDE and the new Konqueror are surprisingly fast.
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
Will Apple continue to play nice with the OSS world and release this new engine back to KHTML?
And is it possible that Tamarin (Mozilla's version of this) and this will merge, creating some ridiculous new super-fast JS magic engine, interpreting code yet to be written?
I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.
Javascript is doing more than just surviving. Early implementations of Javascript were quite buggy and standards were pretty lax. Things have improved significantly since "Javascript" became ECMAScript. The name may still have "script" in it, but it's a huge misnomer. Javascript is a full-fledged language - a very powerful one with many unique properties, and very useful if you know how to apply design patterns.
I encourage anyone involved in building websites, widgets, or enterprise applications to check out the Javascript lecture series by Douglas Crockford of Yahoo! located at http://video.yahoo.com/video/play?vid=111585 to get a real feel for the power of modern Javascript.
And have a look at the modern AJAX frameworks like YUI and JQuery, which are being used to develop some pretty complex applications.
-- thinkyhead software and media
The sooner this happens the sooner a jython engine (javascript->python interpretter) becomes possible. Get google to host it like the library hosting article of a few days ago, and profit!
//salivates,
//why are you looking at me funny?
CS majors know the time/space tradeoff, but they never get taught the 3rd, crucial, tradeoff of the set: comprehension!
Why did /. try to popup a new ad window today on firefox+linux?
I'm surprised that they weren't already using either a threaded interpreter or a bytecode interpreter. It's such an obvious step when performance is on the line, and I'm sure there must be a variety of such interpreters available, it's been a standard middle-ground between a fully compiled language and a raw text interpreter since the '70s at least... the DEC Fortran compiler used threaded code, and Smalltalk used bytecode, both in the '70s.
I won't even get into the fact that they weren't doing almost-free optimizations like eliminating empty nodes in the syntax tree...
Just for the hell of it, I've got Firefox 3 RC1 running on an ancient Toshiba Libretto 110CT with 64MB RAM running W2K on a Pentium-MMX 233. Looking at JS benchmarks online, with Firefox 3 (presently) leading the way, I figured it was worth a try... FF3 is way more usable than Firefox 2.0.0.14... In fact, the full version of GMail actually runs on the Libretto! (Firefox 2 would go into JS hell with the CPU pegged at 100% for 10-20 seconds at a time...)
One can only hope that we could squeeze some more JS performance...
Windows 3.1x calc: 3.11 - 3.10 = 0.00
Gee whilickers, thanks for the heads up Timothy! That's the quite possibly the lamest and most pointless opening sentence in a Slashdot summary I've ever read...
chicken
Cosmic Cat Creations' FireSomething plugin is similarly fun. Only does not (yet) install on Firefox 3.
(Haven't checked if there's some incompatibility, or if a simple change in the maximum version does the trick)
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
With there finally being a nice Javascript implementation that cleanly and efficiently sends to bytecode, I'm wondering if the dynamically-typed-specs in the Parrotcode project could be of some assistance. The ECMAscript implementation they're already working on still has a long way to go, and this would be one way to help consolidate development efforts -- plus get some additional motivation behind both projects.
Hire a Linux system administrator, systems engineer,
Sun is also making a JWebPane which will be Java port of WebKit. First as part of JavaFX, but it will be an actual Swing component.
Are there any browsers under Linux that track the current (nightly) Webkit libraries? I've seen a couple of them online, but a lot just seem like real basic wrappers and aren't updated.
I wanna give it a try, I've more and more begun to not enjoy running firefox under my older hardware.
-Bucky
I think this has great potential. Now that all the parsing/compiling has been accomplished, I think they should setup a system where they can store the compiled bytecode and simply retrieve it if a page with the same javascript is loaded (ex. reloading GMail).
The next step after that is of course to JIT the bytecode, meaning compile it to the native architecture and eliminate all unnecessary calls. Even without further optimization or register allocation, such JIT-ed code would run MUCH MUCH faster. Unfortunately it would become architecture-specific.
m
Truly the 200X decade will be remembered as the "Decade of Retarded Technology Names".
Did someone make a rule that every new tech has to have a name that would make me sound like a fucking idiot if I tried to pitch it to my boss?
Never approach a vast undertaking with a half-vast plan.
Just downloaded the latest build for MacOS X, and thought I'd try the Acid3 test to see whether there was tangible speed improvement, and I can't load the darn URL. I guess I wasn't the only one who thought of this...
The CB App. What's your 20?
very useful if you know how to apply design patterns.
If we're talking about *Javascript* design patterns -- common useful Javascript idioms -- then I think this is a useful statement. If we're talking about common idioms that have filtered out from C++ and Java known as "design patterns" as applied to languages that don't need to many of them, then I'd say Javascript is pretty useful even if you don't know much about them. Possibly more useful.
http://www.nofluffjuststuff.com/show_session_view.jsp?presentationId=9542&showId=114
http://www.codinghorror.com/blog/archives/000899.html
http://steve.yegge.googlepages.com/singleton-considered-stupid
Tweet, tweet.
the framework behind (among others) Safari and Safari Mobile,
It's bad enough that web developers ignore my minority browser (rather than defaulting it to the same template as safari), but ignoring the history of webkit completely must be hugely insulting to the authors of khtml. Give them some credit.
I wrote my first program at the age of six, and I still can't work out how this website works.
And in light of all this it's interesting that Tamarin was actually _donated_ to Mozilla by Adobe... ("you can't do it properly by yourself so here, use this, dammit" crossed my mind few times...)
One that hath name thou can not otter
Will this Rhino (http://www.mozilla.org/rhino/) get this? We use it extensively as an embedded scripting engine on the server side - and use a lot of CPU cycles running it.
I don't know anything about Javascript interpreters in particular, but as a general rule, interpreters for any sort of "scripting" or "dynamic" languages tend to be pretty simplistic and weak. There are a lot of techniques for making language implementations run faster, but they almost always get applied to systems that emphasize compilation.
Even when people implement dynamic languages by compiling to bytecode, they tend to write very simple VMs where the operations are at a fairly high level, and are all costly to execute. The "compilers" tend to do very simple and quick translations to bytecode, without much optimization, because when compilation happens at runtime, you want to minimize compilation time. The bytecode VMs also usually do very little to optimize bytecode; there's hardly ever any type or data flow analysis of bytecode, bytecode-to-bytecode transformations, etc.
Nearly every interpreter out there could be made a lot faster without a lot of work.
Are you adequate?
Yes, it is a wonderful time for browser wars right now.
With FF3, Opera 9.50, and Webkit whatever in the works, this is truly an interesting ride. What final release will be better?
Need an automatic screenshot taker? Try here.
Will it run Linux?
Homonyms are fun!
You're driving your car, but they're riding their bikes there.
it should really help out the LivelyKernel.
javascript + svg
http://research.sun.com/projects/lively/
Ha, especially since Konqueror just wrote their own version called frostbyte. And it's faster than the webkit version.
http://www.kdedevelopers.org/node/3476
x1.4 faster than kde3 version
I just loaded the latest nightly of WebKit, which from what I gather is supposed to be using Squirrelfish, but it still seems to run the "Wundermap" at wunderground.com more slowly than Firefox 3.0RC1. I consider the Wundermap to be the ultimate browser test, as it has to process so much JS and images... I recently tried running it on a Mac Pro 8-core at the local Apple store, and it still loaded slowly! The Mac Pro absolutely flew through everything else I threw at it, including playing multiple HD movies at the same time, but when loading the Wundermap, it is almost as slow as my puny 2.0 GHz G5.
Slashdot's first reaction to VMware
On the contrary, session-dependent web apps are bankrupt design-wise. They violate the (stateless) page metaphor, breaking the standard UI and confusing the user, simply because some programmer couldn't be bothered to find a good way of maintaining state. Some of my favorite denizens of the Session Hall of Shame are...
In these days of >100KB page loads, it's silly to sweat over 4KB typed into a textarea. If you find it painful to maintain state from request to request programmingwise, you're not using enough framework. Find something nice that'll stow user data client-side without making you think about it. Or, if you're in the mood for something exotic, try a continuation-based framework like Seaside: those let you forget about the statelessness of HTTP altogether, though admittedly at the cost of tokens which feel a bit like session identifiers but aren't quite. (They still don't break the Back button or parallel surfing, and you can set the timeout to a week.)
What I really mourn is the passing of HyperCard for the web. There was a time back in the nineties where it looked like HyperCard was going to get rolled into QuickTime and thus be available in any browser that could run the plugin. Now that would have been sweet. I suppose Flash isn't a much different result, though I hear its roots in linear-chronology animation still poke through when trying to develop apps on it. If the Flash UI were a little better--using native widgets, letting standard text selection and copy and paste work--I'd likely be won over. I suppose the best choice today is session-free AJAX with a good framework to keep the details out of your face.
Thanks for reading to the bottom of my rant! I feel much better now. :-)
QtWebKit gets used in plasma.
KHTML gets used in Konqueror.
There isn't any plan to change.
KHTML devs talk with the Apple people a lot, but partly because the KJS stuff has diverged a lot less than the rest of the codebase.
Frostbyte (http://www.kdedevelopers.org/node/3476) was added for 4.1 so depending on what version is in experimental atm, you may already have it. If you have the 4.1beta, it's there. I don't there is much relation between frostbyte and squirrelfish, the codebases are different.
I guess at the time that blog entry was written, Apple hadn't released theirs yet, so you don't see any comparisons to WebKit proper. QtWebKit is what Plasma is using. Its a port, so it ends up being an older version of WebKit.
And how exactly was that Offtopic?
How come every time someone talks about Javascript, they talk about how people hate it? I have always attributed the hate to the suckage of the HTML DOM, which is kinda unfair to blame Javascript for. Anyone got some more insight into why Javascript sucks?
Now THIS post is off-topic!
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
I'm looking at embedding an ECMAScript implementation into a project. SpiderMonkey has pretty complete API documentation at http://developer.mozilla.org/en/docs/SpiderMonkey.
Is there anything similar for SquirrelFish? In particular, anything on running the same interpreter in several threads, and tips on when and how to schedule garbage collection?
2 dashes and a space, or just 2 dashes?
Where are you getting this information from? Certainly not the khtml developers. khtml, btw, is in the base kde libraries. And konqueror is very tightly integrated to kde itself. While there are webkit-using browsers out there, they aren't anywhere near on par with konqueror yet, nor will they be for some time.
a) khtml had a clean codebase
b) it was open source, so they could grab it
c) they could develop Safari in secret
Whether or not this is good for the rest of us is debatable. If you aren't a KDE user, it doesn't matter. If you are, then you can be sad at some of the community infighting. And that it will make some things harder:
Its worth noting that in the time since they forked, they diverged the codebase enough to make a merge problematic.
It would also make open source developers unpaid apple employees, if they were to switch from khtml to webkit. khtml developers do it because they want to help kde, not because they want to help apple/todays's cell phone company/etc make a profit. They care about their users and they do it because it's interesting.
-- Lars Knoll and George Staikos on KHTML and WebKit
Perhaps they changed plans since then and I didn't hear it.