mschuetz

In my case, it did involved reading binary files from ArrayBuffers where some attributes were stored as int64. I've been using DataView to read BigInt64s and then used those frequently. Was terribly slow. I've then reverted to alternatives wherever possible, e.g. immediately converting the BigInt64s to Numbers/Doubles where 53 bit integers were sufficient, or splitting down to two 32 bit integers and do some more involved bit magic on them. Much faster, but overall I wasn't happy with the whole process and complexity. I'd rather have native 64bit integer values in JS.

> That is not true. BigInt has been available for a bit already.

performance-wise, BigInts are terrible. Tried to use them, made things about a hundred times slower. What JS needs are 64 bit integer types, and some form of typing system that allows differentiating between various number types.

> Other than the fact we have BigInts now

performance-wise, BigInts are terrible. Tried to use them, made things about a hundred times slower.

I consider Google Earth something like a modern digital world wonder. These things are absolutely amazing, especially in VR.

It is kind of weird and unintuitive. This one here, posted by another commenter, is much much more understandable: https://commons.wikimedia.org/wiki/File:MatrixMultComplexity...

That's google and it's to be expected because many of the largest companies have a strict no GPL policy, naturally including AGPL. Doesn't mean tens of smaller startups won't use AGPL licensed software for their SaaS services without any sort of compensation or contribution to the orginal project. AGPL does nothing whatsoever to stop profitable companies from exploiting Open Source software without contributing back.

Mainly talks about linking AGPL projects. What about just "using" AGPL projects? Like you'd use a precompiled ffmpeg, cat, grep, etc. without ever touching the source.

AGPLv3 doesn't solve the problem of projects being used as components SaaS services, as far as I understand? So companies can still use the projects just fine without the need to contribute anything back.

For all music ever recorded, maybe. But Spotify doesn't even have half of what I'm regularly listening to - a regular annoyance - let alone half of all music ever recorded.

Standards of living were vastly different back then. It used to be the norm that 6-7 people were living in the same room, and apartments were about 22m² [1]. Toilets were outside the apartment. etc. Since then, old houses were upgraded and massive amounts of new houses were built to accommodate a rising standard of living. Just in the past 30 years, formerly cheap regions at outer parts of Vienna, with houses that were only habitable during summer, developed into enormously expensive upper-middle class areas with single-family houses.

[1] https://www.derstandard.at/story/2000067989262/wohnhistorike...

Not sure how they actually work but I can imagine that it's not that bad in OpenGL, DirectX, Vulkan, etc. You can just fill a preallocated buffer with a certain capacity with the right data on the fly and send it to the GPU in one swoop. Should be fine for a couple of thousand of elements, as long as you don't invoke OpenGL commands for each individual elements, but only for the buffer containing all elements.

For html, it's probably much tougher since the DOM is statefull and fares badly with frame-wise changes to it. That might require caching elements to avoid layout invalidation and rebuilding the dom.

What are average build times for a deno project? One reason I've sticked with JS, Electron and node up until now are zero build times, but I really miss static typing.

That example looks like a strawman to me. In practice, x would probably originate from outside the function, as a parameter or class member, and there is a good chance it could hold the value null or undefined. Seems like way too much additional work with little to no benefit to make the compiler track things like that through the whole application. Worse, the variable state could intentionally be hardcoded to try things and it would be weird if the compiler would error because the variable is never set to undefined, when I might be hardcoding it to undefined later on.

I'm trying to wean off of jQuery to reduce dependencies, but it makes me appreciate jQuery all the more. The native JS API is quite a bit more verbose and cumbersome to use, and my absolute biggest gripe with it is that it doesn't even build on modern JS features. It's not compatible with for...of, map, filter, find, etc, which seems really strange for a relatively recent vanilla JS API.

Ironically, http://youmightnotneedjquery.com/ makes a pretty good case in favour of jQuery.

With some libs and tutorials, setting up a modern OpenGL pipeline has become reasonably easy, and extensions give you access to some state of the art features, sometimes even before DirectX (64bit atomics just made it into DirectX in december, but I've already used them in OpenGL 2018). I don't feel like switching to Vulkan, mainly because of all the reviews of others who said that it's incredibly cumbersome to use and after looking at certain aspects of Vulkan, I can see why. I don't really want to take the effort of diving into another badly designed graphics API at that point.

I do, however, very much look forward to WebGPU, which seems heavily based on modern Vulkan, Metal and DirectX, but it's comperatively easy to set up and work with. Major downside is the lack of cutting-edge features because WebGPU is targeting the lowest common denominator (=smartphones, and also the lowest feature set that all backends (DirectX, Vulkan, Metal) offer), but I've got the impression that it's going to be what OpenGL and Vulkan were supposed to be but didn't really manage to become: A platform-independent modern graphics API.

It's being done all the time, and it's exactly what legislation is for. Workers rights, consumer protection, EPA, outlawing child labor and slaves, etc.

You mean:

    {
      "colors": [
        { "color": "black"  , "hex": "#000", "rgb": [   0,   0,   0 ] },
        { "color": "red"    , "hex": "#f00", "rgb": [ 255,   0,   0 ] },
        { "color": "yellow" , "hex": "#ff0", "rgb": [ 255, 255,   0 ] },
        { "color": "green"  , "hex": "#0f0", "rgb": [   0, 255,   0 ] },
        { "color": "cyan"   , "hex": "#0ff", "rgb": [   0, 255, 255 ] },
        { "color": "blue"   , "hex": "#00f", "rgb": [   0,   0, 255 ] },
        { "color": "magenta", "hex": "#f0f", "rgb": [ 255,   0, 255 ] },
        { "color": "white"  , "hex": "#fff", "rgb": [ 255, 255, 255 ] },
      ]
    }

Adding a property to an object that does not belong to the object is pretty much the worst workaround to comments, in addition to it being much harder to read due to lack of comment specific syntax highlighting.

"On the other hand, I find such code painful to look at."

It also pains me to see the opening bracket in its own line. (Being from a field where I don't get to use C# or SQL, I don't understand what the author is referring to)

I don't want to setup a package.json for projects that don't need it.

Amazon became almost useless for many types of articles. For any type of item, there are 10-20 resellers selling the exact same cheap item, just with different color and branding. It's essentially become an expensive dollar store.

I've abandoned Amazon because of that, until they finally add a "no third party sellers" option. And also a "don't show items we don't actually send to your country" option.

I absolutely love ESM modules, pretty much the best thing since sliced bread. Node.js is really botching it, though, with the requirement to use the mjs extension. It makes it very awkward and cumbersome to use the same code in the browser and node.

VS Code is essentially a browser app based on Typescript(Javascript) and html. You can even open the chrome dev tools in VS Code (Help -> Toggle Dev Tools) and inspect the html and javascript of VS code. You can also go so far as to change the CSS and html of vs code in the dev tools. Try using the element picker (top left icon in the dev tools) to select an element in vs code, and you'll see that each line of code is a div and each token is a span that is syntax highlighted by CSS classes.

It's tiny, and usually negligible in context with all the other data that needs to be transferred, even with millions of users. Millions of users might be the situation where I'd start thinking of integrating slower builds as an alternative, provided they can seamlessly live side-by-side with the fast build tools.

No, I vastly prefer 10x faster build times and merely 2% file sizes over anything that's on order of magnitude slower. It's not even a competition.

> I could not imagine I would be able to differentiate a billion colors from its previous factor.

Darker single color gradients exhibit very strongly noticeable color stairs. Tried to generate one for a background, locked horrible. It only looked good once I randomized the gradients a bit, i.e., even with 8 bit colors, you might need dithering.

Similar effects can be noticed in relatively dark photos of scenes with gradients, e.g., a sky.

Reviewing and testing multiple PRs is an enormous amount of work for anything but the most simple one liner changes.

Not sure how LZ4 compares but what convinced me to use brotli over some other compression libraries was how trivialy easy it was to integrate in C++ as well as in javascript. No effort at all. I wish more lib providers would make their things so approachable.

This is a good page that shows why JQuery isn't going away anytime soon: http://youmightnotneedjquery.com/

This is not something that should require a plugin. Each plugin is an additional source I need to trust.