Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

hacks.mozilla.org

Post reply on HN
Print view View original

171–180 of 281 posts

Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

#171

Post by devwastaken »

hk__2 wrote: post #77
devwastaken wrote: post #62

Earlier quoted context omitted.

If that diversity doesn't lead to better results then it isn't necessary. I wouldn't consider the oligarchs of Js engines to be diversity, nor inherently innovative. In the past there has no doubt been innovation, but currently it has significantly stagnated. Wasm was not what was promised. Mozilla and the other vendors just translated the wasm bytecode to js bytecode. All it did was skip a few steps. Yet the actual…

> If that diversity doesn't lead to better results then it isn't necessary. It does, so it’s necessary. Performance is not the only one result we care about.

If they were innovating then spidermonkey would be comparable or better than v8. It isn't. It's effectively proprietary to Firefox. Id call that the opposite of diversity.

Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

#172

Post by hinkley »

oscargrouch wrote: post #106
giancarlostoro wrote: post #74

I'm waiting to hear about when they start to rewrite their JS interpreter in Rust. It will make things kind of interesting, especially if it becomes a stand-alone capable JS inrepreter.

To be fair i think this is an exercize in vanity and why not say it, stupidity. Javascript VM´s these days are fairly complex beasts with huge amount of man-hour and expertise. Also technically this would be a inferior solution as compared to what V8 did with its interpreter in Turbofan (and SpiderMonkey are doing now as presented in the article), by generating pure assembly through the turbofan backend (the same tec…

Couldn’t you say much the same thing about Firefox as a whole?

Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

#173

Post by landonxjames »

_bxg1 wrote: post #68

Something I'm curious about is why JS developers don't have the option to send along some of this information themselves; type information, JS bytecode, etc. Given that we often have it on hand already (TypeScript) or could integrate it into our build process (webpack). Obviously plain JS needs to still work without all that, but it could be a compelling point of optimization for large-scale apps. Perhaps the JS byte…

Deno[0], a project from the original author of Node, will natively run TypeScript, so I'm hoping it will have some of those sorts of optimizations.

[0]https://github.com/denoland/deno

Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

#174

Post by cmroanirgo »

pizlonator wrote: post #165
The_rationalist wrote: post #151

Earlier quoted context omitted.

Are there any solid benchmarck comparing JSC vs v8?

JSC has had a set of large metabenchmarks like JetStream2 for a while. We have been the fastest for a while but V8 is gaining, so the current advantage is significant but not earth shattering. The last time V8 had their own benchmark, they retired it right after we beat them on it and made a post saying that benchmarks are bad because people cheat on them. Around that time I stopped seeing google.com claim that I sho…

> ragequit

I've increased my vocabulary today.

In topic: I always wondered why chrome stopped that marketing spiel.

Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

#175

Post by hawkice »

copperx wrote: post #128
josteink wrote: post #103

Earlier quoted context omitted.

> It sucks that we have to do that, but I can't entirely blame them for making their own products work better on their own browser. You mean like MS for a long time did with MSIE? Are we really back in the 90s, back to “This page works best in $one_specific_browser”? This is not the future I was hoping for... On the flip side I can use Linux for almost anything, so i guess it’s not all bad.

> Are we really back in the 90s, back to “This page works best in $one_specific_browser”? Do webdevs really check for Chrome AND Firefox compatibility? The devs I know consider the job done as long as their site works with Chrome.

This... is more fraught than you might guess. Really fiddly details can make things look goofy if you don't check.

Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

#176

Post by simcop2387 »

giancarlostoro wrote: post #156
simcop2387 wrote: post #144

Earlier quoted context omitted.

Oh neat, when they first switched to sync that wasn't the case (the previous system did allow it over WebDAV and such), but because sync wasn't just a data dump with WebDAV it wasn't possible at launch to run your own server. I'll have to look into that again.

As far back as I remember the code behind sync was on GitHub and I do mean the backend. It probably still is. But I let Mozilla host it cause they encrypt it. If I lose my password I lose my synched items.

It was there I think, but wasn't immediately possible to use a different server as they hadn't enabled or built that into the browser yet. They were still working out issues and I never bothered to check up on it because it seemed like the encryption was secure enough for me.

Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

#177

Post by tomcam »

_bxg1 wrote: post #83
WorldMaker wrote: post #80

Earlier quoted context omitted.

JS tried to add (optional) type hints in the ES4 standard that was never adopted (outside of tangential things like ActionScript 3). It would be great if Typescript hints could pass right along to the JITs as useful optimization factors, but it currently sounds like TC39 would prefer not to recreate the disasters of ES4 and are staying out of type hints for the forseeable future. (Well-typed code should prevent most…

Yeah it's probably not worth it to add types to JS the language, but what if you could ship standard metadata files similar to source-maps that only included type information, which browsers could leverage to speed up compilation?

Sounds good in theory, but it seems like rich territory for mismatched types in the source and map files.

Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

#178

Post by Caspy7 »

1_player wrote: post #169
nvrspyx wrote: post #67

Earlier quoted context omitted.

In my opinion, macOS is definitely FF's weakest desktop platform. I've personally experienced terrible performance, out-of-place UI for the platform (e.g. default dropdowns), and just a generally less polished experience compared to Safari, Chrome, and Chromium derivatives. I still use it as my default browser on macOS though because it does excel in other areas.

Same for me, I tried the latest Nightly a couple days ago to test the CoreAnimation work, and after 1 hour of use my Slack tab because so unbearably sluggish each keypress would take 1 second to render. No extensions, no GIFs, no heavy tabs open, perhaps one or two open tabs. No slowdowns at all after 8 hours on Slack w/ Safari or Brave. Firefox is definitely the worst browser on macOS, compared to the Windows versio…

I know about the CoreAnimation work. Hadn't heard about this accumulated sluggishness that you describe. Have you tried safe mode? A "Refresh"?

Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

#179

Post by Caspy7 »

chucksmash wrote: post #141
copperx wrote: post #127

Earlier quoted context omitted.

I thought Thunderbird was not under development anymore?

They released a new version on the 27th of August[1]. It looks like it that was the first release since August 2018[2]. [1]: https://www.thunderbird.net/en-US/thunderbird/68.0/releaseno... [2]: https://www.thunderbird.net/en-US/thunderbird/60.0/releaseno...

I believe Thunderbird is now ESR. So it gets a major version then security updates for a year until the next one.
Post reply on HN