271–280 of 281 posts
Earlier quoted context omitted.
I suspect this is because chrome supports WebSQL while Firefox does not.
I suspect you have suspected incorrectly: https://developers.google.com/web/tools/lighthouse/audits/we...
Earlier quoted context omitted.
Nope. JSC is even better in that regard - it’s API and ABI stable so you can just link to the[1] system install and use it [2]. [1] on Linux there are multiple (although technically it could be made to have a single lib for qt,gtk,wx... [2] ok, actually using the C API is very very clunky :-/
There are often multiple installs of spidermonkey too (IIRC recently there was an effort in FreeBSD Ports to consolidate everything onto the latest couple versions) The most (in)famous consumer of that is polkit :) but also GJS
Eg you’d ideally have
* libjavascriptcore - the actual engine, runtim, and c-api, etc
* libjavascriptcore-qt (only the bindings, it would link the root jsc lib)
* libjavascriptcore-gtk (same)
* etc
The problem is that because they talk directly to internal interfaces they need to update in lockstep.
On Mac the only frameworks that do that are the core webkit frameworks. Nothing else on the system can talk to the internals (Mac and iOS have fairly comprehensive support for distinct internal/project/public APIs). But the system webkit, webcore, jsc, etc all have to update and build in lockstep.
In an ideal world all the alternate language bindings would be built on top of the stable C API, but alas (as I said before) the C API is fairly clunky and also out of date wrt to modern JS features. Also there are fun performance things a given binding can achieve if it doesn’t need to go through some layer of abi stability limitations.
Earlier quoted context omitted.
Because monocultures are bad.
Is linux bad? Is git bad? Your argument needs a little more development.
assuming you know about Windows and OS X and are just talking about servers, there's still the BSDs and Solaris and AIX. a good deal of software is written to just assume a reasonably POSIX-compliant environment, precisely because linux is not the only server OS.
unix-like operating systems are something of a monoculture and that IS very bad, because OS design is basically stuck in 1973
>Is git bad?
yes and anyone who says otherwise is numb to the pain
Earlier quoted context omitted.
> Javascript VM´s these days are fairly complex beasts with huge amount of man-hour and expertise. You know what else is a MASSIVE time and money sink? C/C++. Combining 2 big and nasty complex stuff you get something even bigger. ---- I don't say to blind rewrite. Is know to be: > an exercize in vanity and why not say it, stupidity. But this must take in account TIME. Right now , is not the time for a rewrite, but is…
The topic of rewrite, i think it depends a lot of the context. Some things might make perfect sense for a rewrite, but i still think that a very optimized with huge amount of man-hour piece of sophisticated and complex C++ codebase like Spidermonkey VM are not one of those things. Theres no gain in clear performance, unless theres a better algorithm being implemented, no clear gain in productivity, as C++ and Rust ar…
Is like null. You can write null-safe code in any language... as long your developers become "compilers" and by discipline make sure EVERY LINE is null safe. But when your lang do it for you, is a problem that get solved.
C++ demand a lot of attention to details that are unnecessary in rust. This is where the gain come.
Earlier quoted context omitted.
There are often multiple installs of spidermonkey too (IIRC recently there was an effort in FreeBSD Ports to consolidate everything onto the latest couple versions) The most (in)famous consumer of that is polkit :) but also GJS
The problem for JSC I suspect is how you manage gtk/qt/wx bridges without need either all three or alternatively creating dependency hell due to the bindings directly interacting with internal (eg totally unstable) interfaces and structs. Eg you’d ideally have * libjavascriptcore - the actual engine, runtim, and c-api, etc * libjavascriptcore-qt (only the bindings, it would link the root jsc lib) * libjavascriptcore-…
Earlier quoted context omitted.
There are often multiple installs of spidermonkey too (IIRC recently there was an effort in FreeBSD Ports to consolidate everything onto the latest couple versions) The most (in)famous consumer of that is polkit :) but also GJS
The problem for JSC I suspect is how you manage gtk/qt/wx bridges without need either all three or alternatively creating dependency hell due to the bindings directly interacting with internal (eg totally unstable) interfaces and structs. Eg you’d ideally have * libjavascriptcore - the actual engine, runtim, and c-api, etc * libjavascriptcore-qt (only the bindings, it would link the root jsc lib) * libjavascriptcore-…
Earlier quoted context omitted.
The problem for JSC I suspect is how you manage gtk/qt/wx bridges without need either all three or alternatively creating dependency hell due to the bindings directly interacting with internal (eg totally unstable) interfaces and structs. Eg you’d ideally have * libjavascriptcore - the actual engine, runtim, and c-api, etc * libjavascriptcore-qt (only the bindings, it would link the root jsc lib) * libjavascriptcore-…
Why would a JSC on its own depend on the UI toolkit? Spidermonkey doesn't.
I recall there being a desire to make it easier for bindings to be done entirely through the API, but as said elsewhere the API is somewhat clunky. Of course any level of abstraction adds costs - for example by being tied to the innards of JSC the various bridges are able to directly bludgeon the tag bits in JSString (the jsc raw string type) so there’s zero copying.
It also theoretically means you can do automatic object bridging (see the objc bindings).
So it’s not “JSC has to have UI bindings” as much as “JSC can be built with bridging APIs for major embedding frameworks”.
There is a trade off to be made, and long term I’m sure everyone in the JSC team at Apple would rather they could pull the bridges out of core build, but API design is very hard when you are having to think about long term support, coupled with continued support for the existing APIs.
Earlier quoted context omitted.
V8 did this a while ago.
As far as I know V8 has a generated interpreter and an optimizing JIT (Turbofan). In Firefox we now have a generated interpreter + a Baseline JIT on top of a mostly shared code base. I think that's a pretty nice design/advantage.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
Check about:gpu - sounds like hardware acceleration isn't working.
It seems intentionally disabled. The about:gpu page reports the following: >Accelerated video decode is unavailable on Linux: [137247]( https://bugs.chromium.org/p/chromium/issues/detail?id=137247 ) >Disabled Features: accelerated_video_decode