Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)SE
Posts
0
Comments
307
Joined
2 yr. ago

  • If either of them had wanted to, they could have kept it close.

    I don't know if you regularly work with large code bases, but that's not true. It's very easy to diverge significantly even if you don't want to. That's why there's so much focus on short living branches, the long living branches cause a lot of pain.

    Now, if you have a hostile upstream, which intentionally tries to make that difficult - that's a whole another story.

    We already have multiple browsers forking Chromium with the features they want and not the ones they don’t. Edge is this. Brave is this

    So, which core web platform features (things like HTML, CSS, JS, DOM, network stack, WebGL, WASM, File API, WebVR, WebXR...) Brave/Edge add or remove? Brave/Edge go with the first option outlined above, they're more like shells (or skins if you will) around the largely untouched Blink.

  • You just fork the existing Chromium, keep your fork up-to-date with the parts you like, while removing the parts you don’t (like WEI).

    You mean like WebKit and Blink kept up to date with each other?

    You have basically two options:

    1. you keep your fork extremely close to the original, so you can keep it up to date. But that means making very little changes and as a consequence still leaving google in control.
    2. making more changes, but then your fork will diverge pretty soon, and you lose the benefit of the cooperation. In the end you end up in a similar position as e.g. Mozilla is in now.
      • If google doesn't like what you're doing, they can speed up the divergence by introducing refactorings in the interfaces of the code you modified which will make keeping your fork up to date with the upstream very difficult.
  • I think the mods of the duplicate communities should join forces, agree on uniting the communities and close all but one (the other pointing to the united one).

    I don't think there's really a good reason to keep communities split. (there are of course contingencies where it makes sense, like rogue mods etc.)

  • Maybe there were 78 committers. But other people contributed to the release in some other way (QA?), but that may be more difficult to count than just looking at the commit stats ...

  • This article reminds me how Russia could prevent the war by not invading. They can also stop war any time by simply going home. We should be clear on the fact that Russia is solely responsible for every single second of this war.

  • folks hadn’t really thought of trying to stream parts of the app itself after the rest of it was already running the way they do with javascript stuff.

    It kinds of seems like you have some confusion in the terminology. AJAX doesn't mean streaming the app parts dynamically, it's just client-server request controlled by JavaScript, originally used mostly to pull/post data, not code (the X means XML). Lazy loading application parts is a newer concept mainstreamed by SPAs / bundlers and can be done with AJAX/XHR or other means (injecting script tags or await import).

    You had to wait for the entire .jar to download before it would start, when what it really needed was the ability to download a little stub .jar, start running, and then stream classes on the fly as you accessed them.

    As mentioned above, a native support to do that was baked into Java since 1.0. It's possible some applets even used that. Those that didn't - their problem. But this practice wasn't really common in JS apps of that time either (apps weren't typically SPAs, but still).

  • The only real problem with it was that “AJAX” style tech hadn’t been invented yet, so it had to download the whole thing before it could run instead of streaming parts of the app on the fly

    AJAX is a JavaScript specific technology, Java applets had access to full network stack so it could do whatever it wanted in this regard. Java supports natively custom classloaders which could dynamically load classes from the network, but it's not widely used and I don't know if applets leveraged that.

    and (I think) tended to interact with server-side code with RPC calls instead of the REST style APIs that folks prefer these days.

    Java applets had access to the full network stack, so you could use REST style calls or RPC styled network calls if you wanted. Java applets also had native RPC capability (with network being transparent), perhaps that's what you mean. But all this is an implementation detail invisible to the user and not a reason why applets sucked.

    In other words, it failed mostly because it was ahead of its time, and Electron apps/PWAs are merely a poor reinvention of it.

    I disagree. They sucked, because they were kinda something between desktop app and web app, largely combining disadvantages of both.

  • You're right, he doesn't need to comment on Russia or China.

    It's more troubling what he says about US and Ukraine, saying that the war still going on is their fault, Ukraine shouldn't receive military support, implying it should surrender.

  • It's a long article, but can be really summed up into this citation:

    ... Knowing all this, it’s more absurd to believe the United States doesn’t have the ability or inclination to influence political events in Pakistan than to believe it does.

  • From the systems we've seen the European / Nordic model seems like the best compromise that has been tried so far.

    I like pizza very much, thanks for asking. In general, I liked US, the natural beauty and diversity of the West is stunning. I also liked the vibe of the people. Public transportation sucks for the most part. Fortunately I didn't have to move, the communist regime "moved".