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

61–70 of 281 posts

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

#61

Post by sa1 »

jedberg wrote: post #44
faitswulff wrote: post #3

Earlier quoted context omitted.

I was perfectly fine with Chrome's usability until I started getting a `Hold Command + Q` to quit` prompt on my Mac. Before then, I hadn't even considered the possibility that an application could block me from quickly and easily quitting out of it. Now I have to hold the key combo or double tap it to quit Chrome, and it is the only application I have to do that for. It's so annoying.

Ironically, I love that feature and wish I could have it on my other apps, especially on Firefox. I've fat fingered Cmd-W and Cmd-Q too many times, and while it's easy to restore, it takes a couple minutes, a lot of bandwidth, and spins the CPU to 100% for a while. Which really sucks when you're on battery.

Easy to do with Hammerspoon: https://apple.stackexchange.com/a/349766

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

#62

Post by devwastaken »

the_duke wrote: post #35
devwastaken wrote: post #24

I can't help but think that regardless what different browser vendors do there's no competition with v8. Like any language there is a standard library, or environment around it. V8 is to JavaScript what CPython is to python. At least in python you can use other versions and it's a very similiar environment. But if you want to use mozillas spidermonkey without Firefox, it's hoops and bounds worse experience. I'd argue…

Diversity and multiple implementations are essential for the web IMO. V8/Blink/Chromium are not independent community projects, but firmly in the hands of Google. Chromium being the only viable implementation would put too much control in the hands of a single company (regardless of which company that is, Firefox being the only implementation would be just as bad). It's redundant effort, but it also enforces consensu…

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 requirements for performance, simd, was ignored in its proposal. It has been a significant under delivery overall.

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

#63

Post by feanaro »

devwastaken wrote: post #24

I can't help but think that regardless what different browser vendors do there's no competition with v8. Like any language there is a standard library, or environment around it. V8 is to JavaScript what CPython is to python. At least in python you can use other versions and it's a very similiar environment. But if you want to use mozillas spidermonkey without Firefox, it's hoops and bounds worse experience. I'd argue…

This meme of "why are we building more than exactly one thing for a certain purpose" needs to die. Alternatives need to exist and they are beneficial for innovation and cross-pollination of ideas, resilience, finding alternative approaches to problems and last, but certainly not least, not ceasing control of everything to a single company. For inspiration for this idea, see: natural selection and evolution.

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

#64

Post by TimTheTinker »

gok wrote: post #13

Javascript engines gave up on interpreters too quickly. JITs have been a huge source of security holes, and the language is so huge now that verifying the correctness of JS optimizations is extremely hard. JS was never meant to be a high performance language. Plus all the heroic work on exotic optimization has just resulted in induced demand. Web pages have just grown to contain so much Javascript that they're even s…

I mostly disagree, but I appreciate your opinion - it adds a valuable viewpoint that needs to be considered.

Opinions on this matter may arise from the dichotomy Martin Fowler describes between an "enabling attitude" and a "directing attitude" in software development: https://martinfowler.com/bliki/SoftwareDevelopmentAttitude.h...

You're right that web apps have become extremely JS- and framework-heavy. Just like adding lanes to a freeway increases traffic, adding JS performance has increased demand for it. But faster JS execution does translate to more headroom for developers (regardless of whether they abuse it), which enables new scenarios that wouldn't be possible otherwise.

An enabling attitude will give top developers the freedom to rise higher than ever before; whereas a directing attitude helps to improve those who would perform poorly otherwise (by preventing stupid decisions) -- but places artificial blockades in the way of the best performers.

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

#65

Post by gok »

Quekid5 wrote: post #21
gok wrote: post #13

Javascript engines gave up on interpreters too quickly. JITs have been a huge source of security holes, and the language is so huge now that verifying the correctness of JS optimizations is extremely hard. JS was never meant to be a high performance language. Plus all the heroic work on exotic optimization has just resulted in induced demand. Web pages have just grown to contain so much Javascript that they're even s…

> JITs have been a huge source of security holes, and the language is so huge now that verifying the correctness of JS optimizations is extremely hard. Do you have numbers to back that up? There certainly have been 1 or more security holes in JITs, but AFAICT most of the browser vulnerabilities have more to with bad (new) APIs. The level where a JIT operates really has nothing to do with the surface syntax of JS, so…

> Do you have numbers to back that up?

Hm hard to come up with a number that shows JS optimizations are hard, but you can peruse a collection of Javascript engine CVEs: https://github.com/tunz/js-vuln-db

Notice how many are JIT or optimization issues, or are in esoteric features like async generators or the spread operator.

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

#66

Post by mehrdadn »

patrickmcnamara wrote: post #53
the_duke wrote: post #12

The Mozilla tech blogs are always a good read. Informative and easy to digest. I can only think of one other company blogging with similar consistency/quality: Cloudflare. Firefox performance has seen tremendous gains since their Project Quantum efforts. It mostly feels on par with Chrome for me pretty much everywhere. There is one glaring omission though: a single company where I have problems with FF on multiple ap…

YouTube is faster on Firefox on my laptop for some reason. I get zero dropped frames on Firefox too, compared to Chrome/Chromium. Still waiting on Firefox to support hardware-accelerated decoding of videos though.

> Still waiting on Firefox to support hardware-accelerated decoding of videos though.

Wait, Firefox doesn't do this already? Didn't know.

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

#67

Post by nvrspyx »

shadowfacts wrote: post #57
mr_puzzled wrote: post #43

Earlier quoted context omitted.

> Gmail was still dog-slow the last time I tried, Youtube can send my fan into a frenzy and Docs is also regularly problematic. It seems to work fine on my system running Ubuntu 18.04 with ublock origin installed. Which OS are you using?

Anecdotally with Firefox on macOS, Gmail is by far the worst offender. Switching inboxes/labels takes several seconds in FF and is near instant in Chrome. Scrolling performance in FF is also much worse.

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.

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

#68

Post by _bxg1 »

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 bytecode just isn't standardized across browsers?

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

#69

Post by pitaj »

mehrdadn wrote: post #66
patrickmcnamara wrote: post #53

Earlier quoted context omitted.

YouTube is faster on Firefox on my laptop for some reason. I get zero dropped frames on Firefox too, compared to Chrome/Chromium. Still waiting on Firefox to support hardware-accelerated decoding of videos though.

> Still waiting on Firefox to support hardware-accelerated decoding of videos though. Wait, Firefox doesn't do this already? Didn't know.

I'm fairly certain it does it already.

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

#70

Post by MrRadar »

mehrdadn wrote: post #66
patrickmcnamara wrote: post #53

Earlier quoted context omitted.

YouTube is faster on Firefox on my laptop for some reason. I get zero dropped frames on Firefox too, compared to Chrome/Chromium. Still waiting on Firefox to support hardware-accelerated decoding of videos though.

> Still waiting on Firefox to support hardware-accelerated decoding of videos though. Wait, Firefox doesn't do this already? Didn't know.

It does on Windows and Mac. On Linux it does not but hopefully WebRender should pave the way to enabling it (see https://bugzilla.mozilla.org/show_bug.cgi?id=1210726).
Post reply on HN