×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Next-Gen JavaScript Interpreter Speeds Up WebKit

timothy posted more than 5 years ago | from the zippity-zappity dept.

Portables (Apple) 193

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.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

193 comments

iPhone Safari (3, Insightful)

ryanguill (988659) | more than 5 years ago | (#23641869)

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...

Re:iPhone Safari (0)

bennomatic (691188) | more than 5 years ago | (#23641939)

Jeeze, I wouldn't mind if Microsoft picked up on one of these as well. Imagine if IE actually used the same standards as the browsers us open sourcies like to use.

Re:iPhone Safari (0, Insightful)

Anonymous Coward | more than 5 years ago | (#23642195)

Imagine if IE actually used the same standards as the browsers us open sourcies like to use.

Huh? This is an engine, not a standard.

Re:iPhone Safari (2, Interesting)

Samgilljoy (1147203) | more than 5 years ago | (#23642669)

Jeeze, I wouldn't mind if Microsoft picked up on one of these as well. Imagine if IE actually used the same standards as the browsers us open sourcies like to use.

Wouldn't the effect of such compliance threaten the fabric of the space-time continuum or something?

How about low-end PCs? (2, Informative)

BUL2294 (1081735) | more than 5 years ago | (#23642795)

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...

The real question is.... (4, Interesting)

AKAImBatman (238306) | more than 5 years ago | (#23641915)

...how does this compare to Tamarin [mozilla.org] ? 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. :-)

Re:The real question is.... (5, Informative)

samkass (174571) | more than 5 years ago | (#23642071)

According to this link [satine.org] , the SquirrelFish in the latest nightly build (without the extra optimizations) can already compile *and* run the source code between 1.08x and 1.94x as fast as Tamarin when Tamarin is just running pre-compiled code. It's fast.

Re:The real question is.... (5, Interesting)

Anonymous Coward | more than 5 years ago | (#23642233)

It feels like Safari is moving so incredibly quickly. Webkit 3.1 already felt around twice as fast as webkit 3.0 in terms of javascript execution; now SquirrelFish is around one and a half times as fast again... in what's basically its first stable implementation. And they're already targetting optimisation points, and it's already caught up to Tamarin (and iirc webkit 3.1 is at least on par with firefox 2/3). Absolutely amazing.

The iPhone is the one to really benefit from this, because it's where the pauses are currently noticeable.

And IE really, really suffers in comparison. Microsoft has to be wincing about all this, if only for pride's sake... I'd love to see speed improvements to IE 8 beyond the what's known already [ejohn.org] , though the DOM speed improvements will help a lot for parity.

Re:The real question is.... (4, Informative)

Jugalator (259273) | more than 5 years ago | (#23642863)

I agree, Safari for Windows is actually a bit tempting, especially if "hacking" it a bit (actually, it can probably not even be called "hacking" in geek circles at least) to use the latest WebKit builds. The only downside of that one is its (sorry..) piss poor memory performance. It's worse than pretty much anything I've tried. A few hours browsing and I had it use 300-400 MB RAM. That's like the bad old Firefox 2 days at worst, from my experiences. It's worse than IE 7 too.

Re:The real question is.... (4, Interesting)

samkass (174571) | more than 5 years ago | (#23643127)

According to the article the Windows version of SquirrelFish aren't as optimized as the Mac and Linux versions because of some API dependencies, although I haven't seen any benchmarks.

Re:The real question is.... (0)

Anonymous Coward | more than 5 years ago | (#23643781)

I WISH I only used 300-400 MB of ram at a high point.

There've been times where I've been nearing a gigabyte of usage with firefox 2, and that's with 2.0.0.14.

Re:The real question is.... (4, Insightful)

moderatorrater (1095745) | more than 5 years ago | (#23642901)

I see it as an indicator of exactly how bad the previous js interpreters have been.

Re:The real question is.... (0)

Anonymous Coward | more than 5 years ago | (#23643495)

Heh, that's what I thought at first as well (oh look, doubling speed every release, they must still be at the bottom of the curve) - but then how is it that they're essentially in the lead now? Or are you saying *all* previous js interpreters have been bad?

(All this based on the blog links above, of course... but even if tamarin is faster than squirrelfish, it's not like the current webkit is a slouch in terms of js performance. Memory, yes, but not performance ;) )

Re:The real question is.... (0)

Anonymous Coward | more than 5 years ago | (#23643469)

Firefox 2 and Firefox 3 relative speed should not be mentioned in the same paragraph, much less referenced together.

Firefox 3 has a very fast javascript interpreter in it.

Re:The real question is.... (2, Insightful)

JasonB (15304) | more than 5 years ago | (#23644057)

W.r.t. the performance of a browser's JS and HTML engines: A browser is much more than the sum of its fundamental rendering technologies. If performance were the most important driver of customer adoption, we all would have switched to using Opera years ago. But each time I try to move away from Firefox, I end up moving back because of either:

A. A site compatibility problem.
B. A FF plugin that I cannot live without.

In a perfect world, alternative Linux browsers would provide support for FF plugins, but the reliance on XUL and other very FF-specific technologies makes that all but impossible. That being said, I look forward to this making its way into Midori - the WebKit-based GNOME browser project.

-jason

Re:The real question is.... (3, Informative)

ToLu the Happy Furby (63586) | more than 5 years ago | (#23642893)

Faster than the current Mozilla builds of Tamarin, which have not been optimized and in many situations are still slower than SpiderMonkey.

On the other hand, it bears noting that Tamarin isn't going to make it into shipping code until Mozilla 2.0--presumably that will be Firefox 4, but it's still so far off that I believe that determination hasn't even been made yet. Whereas on past experience I would expect SquirrelFish to be in a shipping Safari build much sooner.

Re:The real question is.... (-1, Flamebait)

y86 (111726) | more than 5 years ago | (#23642409)

With Javascript running for longer periods of time, a runtime-optimizing JIT seems to make a lot of sense.
So does doing nothing, in light of the fact you'll soon have quad and octal core notebooks.

I've never had javascript degrade by web experience in Firefox running on proper hardware (dual core 2 year old junk).

Seems like a lot of effort to keep old junk viable.

Re:The real question is.... (0)

Anonymous Coward | more than 5 years ago | (#23642573)

firefox freezes up on me more than it should. (I use firebug, which slows down javascript execution). Oh, and the fucking UI is rendered via single threaded javascript. Yeah, firefox could benefit from a faster javascript engine.

Re:The real question is.... (2, Insightful)

Bootarn (970788) | more than 5 years ago | (#23642735)

It's all about efficiency. If the computers are getting faster and no optimizations are done, the performance of JavaScript will of course increase. If, however, optimizations are introduced we'll get a steeper increase of performance and will also be able to write more advanced JavaScripts. Which one is better? If a better algorithm for solving a given problem comes along, then it's best to make use of it.

Re:The real question is.... (1, Insightful)

ohcrapitssteve (1185821) | more than 5 years ago | (#23642737)

Embedded devices/smartphones? Mini-notebooks? I guess everyone is supposed to want an 8lb desktop replacement?

Re:The real question is.... (3, Insightful)

jo42 (227475) | more than 5 years ago | (#23642803)

Every time I read something like that I want to bitch slap some sense into the 'tarded poster.

What if you didn't have to wait for faster hardware? What if everything ran much faster on what you have now - TODAY? Why should should we have to continue to spend thousands of our hard earned currency units because developers are frickin' lazy? And what about mobile devices such as PDAs and mobile phones?

Go back to Digg or wherever you crawled out from.

Re:The real question is.... (2, Insightful)

Yvan256 (722131) | more than 5 years ago | (#23643211)

The problem is that a lot of people have grown up with the "throw more hardware at it to make it run faster" mentality since all they know is Microsoft products.

Re:The real question is.... (5, Insightful)

Jay L (74152) | more than 5 years ago | (#23643965)

Um, no. I miss the days of hand-optimizing branches as much as the next guy, but the latest trend toward bigger, bulkier software isn't stemming from Microsoft this time. It's because computers are cheaper than developers.

I recently had the opportunity to work with some code I hadn't touched in over a decade, and port it to a modern hardware platform (same OS). It was amazing, because I could now do the "overnight full build" in 15 minutes. Daemons that used to take 5-10 minutes to compile now took 1 to 2 seconds.

Faster computers change everything. (Just like the availability of cheap screens, and then cheap graphics hardware, moved us from teletypes to CRTs to GUIs.) Continuous integration? Sure, we have cycles to spare. Automated testing? Ditto. Over-modularized components for quicker builds? Don't need 'em. Complex, custom circular buffers? Just log it and parse it later. Need more cache? Have some RAM.

Could I still write code that fits in 2048 bytes and runs at 1MHz? Sure. Can I do a lot more when I don't have to worry about it? Yep. Do we gain more from standing on the shoulders of frameworks and libraries than we lose to hardware costs? Hell yeah.

Re:The real question is.... (1)

Cal Paterson (881180) | more than 5 years ago | (#23644559)

The problem is that a lot of people have grown up with the "throw more hardware at it to make it run faster" mentality since all they know is Microsoft products.
Clearly that's all you know, because this "throw more hardware at the problem" is a central tenet of the Unix philosophy, and furthermore - it's a fundamentally good idea. The fastest way to improve the speed of your program is to do exactly nothing. It's also BY FAR the most cost-effective option.

See here [faqs.org] for ESR's opinion in his book "The Art of Unix Programming".

Re:The real question is.... (1)

Peterix (1060774) | more than 5 years ago | (#23644551)

Indeed. New hardware is no excuse for writing inefficient software.
I still use a 6 year old computer for just about everything and I have no plans for upgrading it (unless something breaks that is).
However, I still like fast software. First I cut every piece of bloat from Windows, which proved futile when MS released Vista. Then I switched to Linux. Now I have everything custom compiled for my machine.

When I upgrade, I'll keep this machine for testing new software. If it won't run fast on it, I won't use it.

Re:The real question is.... (4, Insightful)

buddyglass (925859) | more than 5 years ago | (#23643023)

I've had large spreadsheets in Google docs, with multiple simultaneous editors, really bog down FireFox 2 on a 2ghz Core2. To the point of noticeably interfering with other apps I have open. This will only get worse as more companies try to implement traditionally "thick" applications (e.g. spreadsheets) inside a browser.

Re:The real question is.... (-1)

Anonymous Coward | more than 5 years ago | (#23644699)

I am a compiler and PL guy and JIT sounds nice, but what I really want to see is less people *using* Javascript and all those client side technologies. Web should be content oriented (HyperText Transfer Protocol, no more, no less). AJAX? No thanks. I can make coffee with a desktop application.

Fuckin Obnoxious Coworkers (-1, Troll)

Anonymous Coward | more than 5 years ago | (#23641933)

I am so fucking sick of listening to these cocksuckers' bullshit.

Last time I complained they got as offended and bothersome as an angry black woman. I don't need that shit so I guess I just have to put up with it.

Didn't these guys' mothers teach them any fuckin manners at all?

I highly doubt fewer wasted seconds (1, Funny)

Anonymous Coward | more than 5 years ago | (#23642049)

as I'm sure we can all find plenty of other places to waste the seconds saved :P

squirrelfish? (5, Funny)

the donner party (1000036) | more than 5 years ago | (#23642065)

What's next? rabbitelephant? curvaceous coelacanth? fishfishfishrabbitfish? We desperately need an automatic "hip open source software name generator" before someone gets hurt.

Re:squirrelfish? (4, Interesting)

Anonymous Coward | more than 5 years ago | (#23642185)

squirrelfish? What's next? rabbitelephant? curvaceous coelacanth? fishfishfishrabbitfish? We desperately need an automatic "hip open source software name generator" before someone gets hurt.

Usually what happens is a development team uses themed codenames to easily distinguish product versions. In this case, they're probably using fish names. I worked somewhere with the same theme. We had all sorts of fish names and eventually they got a bit wacky (aquaman). The problem is when in OSS or other open development models, those names become public instead of a properly chosen name. With OSS, this happens because name recognition builds up as people discuss the unfinished software. We only had this happen once, where Man-O-War was demoed for the defense department and they liked the name so much we had to keep it for PR reasons.

Re:squirrelfish? (3, Informative)

BenoitRen (998927) | more than 5 years ago | (#23642229)

SeaMonkey [seamonkey-project.org] , of course. :)

I made a Mozilla product name generator [skynet.be] a half year back.

FireSomething (1)

DrYak (748999) | more than 5 years ago | (#23643019)

Cosmic Cat Creations' FireSomething plugin [cosmicat.com] 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)

Re:squirrelfish? (1)

cerberusss (660701) | more than 5 years ago | (#23644733)

That is so cool. The animal name of my choosing was 'Slug', which resulted in getting the Mozilla product name "ThunderSlug"...

Re:squirrelfish? (1)

Arkham (10779) | more than 5 years ago | (#23644827)

You just want someone to name their product Buttmonkey.

Yeah, I looked at your source.

Re:squirrelfish? (1)

VeNoM0619 (1058216) | more than 5 years ago | (#23642281)

It seems Ubuntu has it right, so I suggest: verb-animal with the same letter.

The possibilities are endless:
Creeping Chinchilla,
Dancing Dolphin,
Falling Feline
Meandering Monkey,
Whining Walrus,
Yielding Yak,
Zipping Zebra

Thank you, if you need me, I'll be over there.

Re:squirrelfish? (2, Informative)

Cochonou (576531) | more than 5 years ago | (#23642341)

Your post made me laugh - a lot.

But incidentally, the squirrelfish is an actual fish (just like it turned out that the firefox was also an existing animal).

Re:squirrelfish? (1)

jeffstar (134407) | more than 5 years ago | (#23642607)

what is nice about all these strange combinations of words is that they are unique search terms to enter into google.

Don't have to worry about pulling up results from Ubuntu 6.10 if you search for intrepid ibex.

Re:squirrelfish? (2, Funny)

prog-guru (129751) | more than 5 years ago | (#23643701)

What's next? rabbitelephant? curvaceous coelacanth? fishfishfishrabbitfish?
duckduckgoose

Run everything in Javascript! (0)

Anonymous Coward | more than 5 years ago | (#23642115)

Yay! With Tamarin now we can all ditch Apache and go with the Firefox Plain Old Webserver [mozilla.org] extension....

Nothing can beat Opera's dev team (0)

Anonymous Coward | more than 5 years ago | (#23642183)

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.

Re:Nothing can beat Opera's dev team (2, Informative)

diegocgteleline.es (653730) | more than 5 years ago | (#23642349)

If opera dev's team can't be beaten then they must have a ultrafast version hidden somewhere, because the public versions, including 9.5 betas, are already slower [zdnet.com.au] than firefox 3 and webkit on many benchmarks

Re:Nothing can beat Opera's dev team (0, Troll)

fo0bar (261207) | more than 5 years ago | (#23642633)

If opera dev's team can't be beaten then they must have a ultrafast version hidden somewhere, because the public versions, including 9.5 betas, are already slower than firefox 3 and webkit on many benchmarks

You say that now, but thanks to the AWESOME POWER OF CLOSED SOURCE, the next version of Opera will be unbeatable!

Re:Nothing can beat Opera's dev team (0)

Yvan256 (722131) | more than 5 years ago | (#23643309)

And thanks to the AWESOME POWER OF ROM, I'll have to buy the next version of Opera DS! (if it ever comes out, which I don't think will happen).

Built-in Opera DS in the next DS rev (along with mp3 and MPEG-4/H.264 support with built-in SD slot) would be nice.

Re:Nothing can beat Opera's dev team (1)

wile_e_wonka (934864) | more than 5 years ago | (#23642651)

That article is quite recent, but I don't quite understand where they found that copy of 9.5 Beta. It says build number 4758, which is odd because the Windows builds are in the 10,000s right now. More likely that's the build number off the mac versions. The mac build of that number coresponds with the Windows build of number 9903. The development team released build 10025 the day before the test and 10014 the week before. In fact the development team made significant optimizations in build 9981, which was released on May 9th. So, I'm just wondering why the test used Beta 1 when beta 2 was available, and even then, it seems like the writers should have used the build with profile-guided optimizations.

The best I can figure is that the article was actually written sometime between April 8th and April 17th. If this is the case then it seems that all of the browsers in the test should have been the most up-to-date builds of the respective browsers that were available in that time period. If this was not the case, then the test was rigged!

Still Stateless (4, Insightful)

Lumenary7204 (706407) | more than 5 years ago | (#23642219)

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...

Re:Still Stateless (1)

PhrostyMcByte (589271) | more than 5 years ago | (#23642603)

I don't think that idea will be too popular. Making it stateful would severely impact the scalability, resource demand, and robustness of modern websites.

Re:Still Stateless (1, Insightful)

MightyYar (622222) | more than 5 years ago | (#23642671)

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
I guess I don't understand. Wouldn't having a better browser-side language make stateful applications more likely? I mean, you dismiss AJAX, but wouldn't faster Javascript make AJAX much better? There are already many "applications" that run on the web that are very similar to their desktop counterparts - better performance will make these more common, I would think.

Re:Still Stateless (4, Informative)

moderatorrater (1095745) | more than 5 years ago | (#23642991)

He's not commenting on stateless applications, but the stateless quality of http. Every time the browser communicates with the server, it has the exact same overhead, whether it's an ajax request or a full web page. The amount that's sent back may differ, but it's still sending all the information associated with instantiating a new connection, sending information about the browser, all the cookies, etc. When you build stateful applications on top of http, you incur a lot of overhead in those headers and cookies being sent back and forth. For applications trying to stay synced to the server, some people have found overhead of over 75%. This inefficiency's being made up for in packing more information into each request, stretching requests out to take up more time, and just plain fast processors and connections.

The GP is saying that if we had a stateful protocol, we could eliminate most of the overhead and make applications move a lot faster.

Re:Still Stateless (2, Insightful)

XHIIHIIHX (918333) | more than 5 years ago | (#23644985)

Well, for lazy website operators maybe. You can strip your HTTP headers down to almost nothing, and you only need one cookie to accomplish everything.

Re:Still Stateless (2, Informative)

ergo98 (9391) | more than 5 years ago | (#23642717)

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.

How do you think TCP works atop the "stateless" IP?

The whole stateless/stateful thing is extremely dated, and not even logically correct. HTTP w/cookies is stateful, and has been for a long time [yafla.com] .

Re:Still Stateless (0)

Anonymous Coward | more than 5 years ago | (#23642775)

To me, this would seem to be where most of our time is wasted...
Umm, how do you figure?

First off, you're not "reminding" the server of the current state. Whatever is being carried in the protocol is just an identifier, which allows the server to determine what session the request is coming from. In most Web applications, the vast majority of the state is retained on the client or server side. Putting real data into cookies/etc. went out of fashion in the '90s, partly due to the horrendous security/privacy implications.

Second, in a modern AJAX application, most of the time is, in fact, spent in the JavaScript. AJAX is turning our browsers into basically Internet-connected JavaScript interpreters that happen to render the GUI in HTML. That's why there are all these efforts to accelerate JavaScript engines now.

Third, the cost of a round trip to the server is real, but you're not going to mitigate it by switching to a new protocol. You need to connect to the remote server via TCP, send the HTTP request, and wait for the content. Under a few KB (which in most cases it certainly is), the size of the request/reply is basically noise.

Probably the best way to mitigate the connection overhead is to leave a persistent connection open. It's perfectly legal to do that already, today; I've actually seen a full TELNET client implemented in nothing but plain HTML/HTTP, using the chunked transfer encoding to stream responses. There are also more transparent mechanisms for hiding the connection latency, such as pooling connections for the XMLHttpRequest mechanism.

None of this, however, has anything to do with the stateless nature of the HTTP protocol. In fact, it's a major win because requests in HTTP can usually be repeated in an idempotent manner, which also means they can be cached. And as I described earlier, HTTP already has sufficient mechanisms to persist application-level state.

Re:Still Stateless (2, Insightful)

_|()|\| (159991) | more than 5 years ago | (#23642997)

To me, [the network] would seem to be where most of our time is wasted...

As always, it depends. I can think of two cases offhand in which bandwidth was cheaper than JavaScript/DOM. Using JavaScript to zebra stripe a large table basically hanged the browser for five seconds, so we added a class to every other row and used CSS. Adding and deleting rows to a large table was extremely slow, so we rendered all of the extra rows hidden by default, then unhid them as necessary. (Not a general solution, but it worked for our purposes.)

Re:Still Stateless (3, Insightful)

Jamie Lokier (104820) | more than 5 years ago | (#23643105)

The only state most apps need to send to the server are a "session" value (cookie or form) and any data you entered. Complex page state is kept on the server, in a session-associated database. If requests are sending a little more, no harm. If they're sending a lot of data every time, which isn't user-entered on that specific page, they're not very well coded.

The real excessive state transfer is the repeated sending of large quantities of (X)HTML from server to client. AJAX helps with that.

plug-and-play javascript engine (2, Interesting)

kai6novice (1093633) | more than 5 years ago | (#23642251)

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.)

Re:plug-and-play javascript engine (4, Interesting)

Daniel Dvorkin (106857) | more than 5 years ago | (#23642375)

It's the old "modular vs. monolithic" argument -- do you write your app as a bunch of small pieces that all communicate through some standard protocol, so you can swap them in and out and upgrade them at will, or do you make everything tightly coupled and interdependent? Browsers, like most apps, tend to go back and forth on this, because there are real advantages and disadvantages to each approach (and most apps end up meeting somewhere in the middle.) Every few years someone comes along with an idea that promises to Revolutionize! Programming! by making everything modular and completely independent, and everyone gets all excited about it and plays with it for a while, and then comes to the conclusion that if it works, it's still too slow. The good ideas that come out of these Revolutions! In! Programming! get absorbed into the mainstream (e.g. OOP, and to some degree microkernels) but they never seem to take over completely.

Re:plug-and-play javascript engine (0, Redundant)

kai6novice (1093633) | more than 5 years ago | (#23642593)

I had this idea, when I was using IE6. I saw IE6 doesn't handle CSS2 as well as firefox does. Therefore I always think about how nice if IE6 allow a CSS interpreter plug-in function, so I can just grab the firefox CSS2 interpreter and plug it in to IE6, so i can continue to use IE6. IE6 is just an example I use here. My point is to give customer more choice and let customer's power to influence how each module should evolve. Instead of packaging everything into a single package where customer must accept everything that come with the package without a choice. My other example would be... if I buy a desktop computer set, but I hate the basic video card that come with the desktop. Everything else inside the computer set is great. Should I suffer and settle down with the basic video card? Or should I be able to choose the best video card in the market and plug into the computer. This way will stimulate the grow of better module (better graphic card... ) because there's a demand.

Re:plug-and-play javascript engine (3, Informative)

Goaway (82658) | more than 5 years ago | (#23642949)

There is no such thing as a "CSS interpreter" separate from the browser. The rendering engine and the CSS handling code are almost entirely one and the same.

Re:plug-and-play javascript engine (1)

cnettel (836611) | more than 5 years ago | (#23643515)

As much of the actual GUI in Firefox is dependent on its Javascript implementation, what you are proposing is far from trivial (at least, you have to agree on an object model, and then you are actually close to Windows Scripting!).

Konqueror/KDE 4.? (1)

mpapet (761907) | more than 5 years ago | (#23642323)

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.

Re:Konqueror/KDE 4.? (4, Informative)

Anonymous Coward | more than 5 years ago | (#23642637)

Oh yes I can tell you: konqueror is coming with khtml by default. There's a webkitkpart ()which is not quite ready) and there's a GSoC student working on it though so it might work better at end of this summer. IF you want an open source browser in linux using Webkit, you can use Arora: http://code.google.com/p/arora/ or the epiphany branch that uses webkit.

Real question: (1)

slimjim8094 (941042) | more than 5 years ago | (#23642335)

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?

Re:Real question: (3, Informative)

Anonymous Coward | more than 5 years ago | (#23642479)

the source is already available: http://trac.webkit.org/browser/trunk/JavaScriptCore

why would the WebKit team be interested in merging code from a slower implementation?

Re:Real question: (1)

pembo13 (770295) | more than 5 years ago | (#23642831)

I am pretty sure that KHTML has been merged/dropped and there is only WebKit in Konqueror now. But I am subject to correction on this.

Re:Real question: (3, Interesting)

paulpach (798828) | more than 5 years ago | (#23643295)

I am pretty sure that KHTML has been merged/dropped and there is only WebKit in Konqueror now. But I am subject to correction on this.

no, konqueror is using KHTML and will use it in the foreseeable future. There is a google summer of code to work on the webkit kpart [google.com] so that konqueror will be able to use webkit by the end of the summer, but it will probably wont be mainstream for a while:

A while ago, konqueror developers posted a FAQ [froglogic.com] describing the future of KHTML. As of today, it still applies

A posibility is that, a new browser may be added to kde, that will be tunned for web browsing as opposed to konqueror which is a swiss army knife. Kind of what Dolphin did for file management. There is already a webkit based browser [google.com] in the works that could achieve this in the future.

Re:Real question: (1)

samkass (174571) | more than 5 years ago | (#23643081)

I think the KHTML guys just adopted WebKit at this point, but Apple has been extremely good with the OSS community in this respect.

And I think Tamarin uses a fundamentally different approach, so I don't see a merger here. But friendly competition is always good.

Javascript grows up (5, Informative)

Slur (61510) | more than 5 years ago | (#23642337)

"With JavaScript surviving as a Web-page mainstay despite many early gripes..."
This notion has long been outmoded... well, at least for the past few years.

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 [yahoo.com] 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.

Re:Javascript grows up (2, Interesting)

p0tat03 (985078) | more than 5 years ago | (#23642995)

I think early gripes were due to the fact that practically nobody was using JavaScript in a productive way. No, we don't want bouncing images, no, we don't want insane drop-down menus that don't behave right, and no, we don't want the web page to break back/forward buttons by doing some underhanded sly scripting work. Or worse! We don't want no stupid popups that ask me for my name.

I think JavaScript has proven now that it has *some* redeeming qualities and legitimate uses :)

Re:Javascript grows up (1)

Migala77 (1179151) | more than 5 years ago | (#23644639)

Wait... now you are making it sound like it went through the same lifecycle as Java...

What's next? Legitimate uses for VisualBasic??

Re:Javascript grows up (3, Informative)

djbckr (673156) | more than 5 years ago | (#23643049)

I appreciate the sophistication of JavaScript, but I hate writing in it. Call me old fashioned I suppose, but I simply don't like the holes you can dig in JS. I recently became aware of the Google Web Toolkit. It really bridges the structured programming I like with the Web 2.0 feel I like my sites to have.

Re:Javascript grows up (1, Interesting)

Anonymous Coward | more than 5 years ago | (#23643239)

Yo
Even Javascript creator Brendan Eich doesn't think much of it as a programming language :
http://weblogs.mozillazine.org/roadmap/archives/2008/04/popularity.html#more

Read what He has to say about it :

"I was recruited to Netscape with the promise of "doing Scheme" in the browser."[...]"Whether any existing language could be used, instead of inventing a new one, was also not something I decided. The diktat from upper engineering management was that the language must "look like Java". That ruled out Perl, Python, and Tcl, along with Scheme. Later, in 1996, John Ousterhout came by to pitch Tk and lament the missed opportunity for Tcl.

I'm not proud, but I'm happy that I chose Scheme-ish first-class functions and Self-ish (albeit singular) prototypes as the main ingredients. The Java influences, especially y2k Date bugs but also the primitive vs. object distinction (e.g., string vs. String), were unfortunate."
[...]
"Is JavaScript popular? It's hard to say. Some Ajax developers profess (and demonstrate) love for it. Yet many curse it, including me. I still think of it as a quickie love-child of C and Self. Dr. Johnson's words come to mind: "the part that is good is not original, and the part that is original is not good.""

The only reason Brendan Eich created that damned language was because Netscape wished to create their own language so they could stranglehold the web, instead of using something that was already standard. That much they did, indeed, looking at the state of the web today, we only somewhat recovered because of a Microsoft invention (XmlHttpRequest was created at Microsoft !) and Javascript prototyped object orientation allowed to work around its language deficiencies with powerful libraries. But they are ugly hacks, not work of art.

Frankly, only someone who doesn't know there are languages like Lisp, Smalltalk, Scheme, Haskell, Ocaml, Ruby, Python and so on would think Javascript is any good. Javascript sucks. The end. Nearly all implementations were of the slowest dynamic language implementations possible (ruby notwithstanding), all had lots warts, the language itself grew with lots of warts (after all in the beginning javascript was intended to be used as a toy to add little bits of dynamism in the browser) and it has no standard library any good.

Re:Javascript grows up (5, Interesting)

jamshid (140925) | more than 5 years ago | (#23643277)

This was a really interesting article about the kind of optimizations javascript is getting. Btw, it still amazes me that after the GUI class library wars of the 90s, and all those Java ui frameworks in the early 2000s, "javascript over http" is state of the art in human-computer interfaces. Anyone who would have accurately predicted this future would have been labeled a madman.

http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html [blogspot.com]

"Why JavaScript? Well, it was Ajax. See, what happened was... Lemme tell ya how it was supposed to be. JavaScript was going away. It doesn't matter whether you were Sun or Microsoft or anybody, right? JavaScript was going away, and it was gonna get replaced with... heh. Whatever your favorite language was.

I mean, it wasn't actually the same for everybody. It might have been C#, it might have been Java, it might have been some new language, but it was going to be a modern language. A fast language. It was gonna be a scalable language, in the sense of large-scale engineering. Building desktop apps. That's the way it was gonna be.

The way it's really gonna be, is JavaScript is gonna become one of the smokin'-est fast languages out there. And I mean smokin' fast."

[OT] Design Patterns (1)

weston (16146) | more than 5 years ago | (#23643963)

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 [nofluffjuststuff.com]
http://www.codinghorror.com/blog/archives/000899.html [codinghorror.com]
http://steve.yegge.googlepages.com/singleton-considered-stupid [googlepages.com]

jython (take two) (1)

TheCouchPotatoFamine (628797) | more than 5 years ago | (#23642371)

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?

Re:jython (take two) (2, Informative)

Daniel Dvorkin (106857) | more than 5 years ago | (#23642463)

Jython is Java + Python, not Javascript + Python. Two completely different beasties.

That being said, if the Squirrelfish VM and interpreter strategy are applicable to other languages besides JavaScript, some sort of "JSPython" strategy for putting lightweight (i.e., not requiring the JVM as Jython does) client-side Python scripts on web pages would be pretty cool. There doesn't seem to be any suggestion of that so far; presumably (and quite sensibly) the Squirrelfish folks are concentrating on getting everything right WRT JavaScript before they try expanding its scope like that.

Re:jython (take two) (1)

TheCouchPotatoFamine (628797) | more than 5 years ago | (#23642619)

right that was what the "take two" was about - i was aware of the java bridge. But with the random crowd this place gets, thanks for making that clearer. I saw a project that emitted JS from Java bytecode. I was just wondering if the same thing could be done, rendering JS from python bytecode. i think about this too often. They should, as a earlier post said, make the intepretters pluggable. that's a big difference from just allowing any ol' code to run - i would imagine the contenders could be vetted pretty thourghly.

Re:jython (take two) (1, Offtopic)

MightyYar (622222) | more than 5 years ago | (#23643307)

Well, there's pyjamas [google.com] , which does the same thing that Google Web Toolkit does, only with Python.

There's also a demo around somewhere of someone using PyPy [codespeak.net] to compile the Bubble Bobble game to Javascript from Python.

I'm surprised... (1)

argent (18001) | more than 5 years ago | (#23642739)

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...

JavaScript is everywhere these days! (0)

tobiasly (524456) | more than 5 years ago | (#23642823)

JavaScript is everywhere these days.

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...

Squirrelfish bytecode... use in Parrotcode? (2, Interesting)

Etcetera (14711) | more than 5 years ago | (#23643087)

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 [parrotcode.org] 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.

Java getting WebKit port as well (1)

Natlaw (626413) | more than 5 years ago | (#23643089)

Sun is also making a JWebPane [java.net] which will be Java port of WebKit. First as part of JavaFX, but it will be an actual Swing component.

Webkit under linux? (1)

bucky0 (229117) | more than 5 years ago | (#23643135)

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.

JIT and store? (1)

Mike_K (138858) | more than 5 years ago | (#23643297)

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

Great name (4, Funny)

szquirrel (140575) | more than 5 years ago | (#23643411)

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?

Re:Great name (4, Funny)

smoker2 (750216) | more than 5 years ago | (#23644211)

Truly the 200X decade will be remembered as the "Decade of Retarded Technology Names".
So says szquirrel on slashdot.

Re:Great name (2, Funny)

AlXtreme (223728) | more than 5 years ago | (#23644503)

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?


You obviously haven't had to explain to a CEO why the company runs on Eunuchs. Kids these days have it far too easy.

Acid3 Slashdotted? (1)

bennomatic (691188) | more than 5 years ago | (#23643635)

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...

Re:Acid3 Slashdotted? (1)

bunratty (545641) | more than 5 years ago | (#23644027)

I can access the Acid3 test [acidtests.org] without problem. I also wonder if this will cause Safari to pass the performance aspect of Acid3 [hixie.ch] . If it doesn't now, it looks like it soon will.

Re:Acid3 Slashdotted? (1)

bennomatic (691188) | more than 5 years ago | (#23644463)

I can get there now, too. Maybe it was slashdotted, maybe something else was wrong.

It get 100, but certainly not under 33ms, and there's no custom favicon. So I guess there's still some work to be done...

no mention of konqueror then (3, Interesting)

sqldr (838964) | more than 5 years ago | (#23644069)

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.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...