Doing it like this has the potential to be the most performant, but it does so in the same way as writing your programs directly in assembly is potentially performant.
I also don't think that the source code is particularly readable for me, and contains lots of magic numbers and very imperative code. I would personally find it a lot more readable if it was written in some sort of declarative way using a library, even if I have to look at a GitHub repo instead of view source.
> contains lots of magic numbers and very imperative code
Well, we really don't know if the code was written in this form by hand, don't we.
It could have been compiled into this, to use your words, "assembly with magic numbers and imperative" from much more elegant form. We may see this form only because this is what browsers understand.
I am not saying it was compiled, just speculating that seeing pure WebGL does not mean it was pure WebGL to begin with.
Personally I'm not a fan of the magic numbers either but as I study more and more of it, it's everywhere
Also, nature and graphics works as an imperative parallel machine. So the code mirrors that.
This is not written deliberately this way. Code comes out like that when you strip all the libraries, fluff, and other less-related stuff.
I also write a scientific application, and yes, This is the way.
Without abstractions you wouldn’t be able to read a text stored on a remote computer with accompanying style information displayed the same on both of our devices and with embedded 3D graphics doing the same thing on vastly differing devices be it a top of the line GPU or a simple low-end phone. Is it not abstraction?
The equivalent would be a mathematical services company, who created "free" abstraction packages that required you to rewrite all your math, away from the scientific community standards, to fit their abstractions, and who also made money on consulting and selling books. And the big benefit of it all, is really that they only abstracted away writing summaries of your papers, which is actually the easiest part that is quite irrelevant to your research.
Who is to tell whether the OSI model is ideal? It is more than likely not it, but we can’t measure these things up front, there is an insane cost associated with changing it, etc. Yet again, what is the alternative? We can’t manage complexity any other way, and essential complexity can’t be reduced.
The current idea of the OSI model was also retrofitted from what it originally was.
It also has the potential to evolve in the most efficient way.
But if you want to be friendly to the tinkerers, you could always host both the *.js and *.min.js versions, and have the webpage just pull the latter - anyone who wants the unminified source can remove the “min” part from the URI, while the majority of end users will still benefit from pulling the minified js.
$ ls -la
-rw-r--r-- 1 jack 197609 330905 May 4 22:56 watch.js
-rw-r--r-- 1 jack 197609 152172 May 4 22:55 watch.min.js
$ gzip watch.js
$ gzip watch.min.js
$ ls -la
-rw-r--r-- 1 jack 197609 43690 May 4 22:56 watch.js.gz
-rw-r--r-- 1 jack 197609 32507 May 4 22:55 watch.min.js.gz $ ls -l *.js
-rw-r--r-- 1 mrd staff 330904 5 May 01:04 watch.js
-rw-r--r-- 1 mrd staff 152172 5 May 01:10 watch.min.js
$ brotli watch.js
$ brotli watch.min.js
$ ls -l *.br
-rw-r--r-- 1 mrd staff 34461 5 May 01:04 watch.js.br
-rw-r--r-- 1 mrd staff 27122 5 May 01:10 watch.min.js.br
Whoops, typo: I meant to say that I'd be somewhat more content to ship an un-minified + Brotli-compressed file than a minified + gzip'd one. That is, I'd be more happy to serve the 34.4KB watch.js.br than the 32.5KB watch.min.js.gz.
Yeah minification is only really for obfuscation. The small and unpredictable difference is absolutely not worth the ridiculous complex "solution" of source maps. Just the fact that your debugger really doesn't work right, is a deal breaker in and itself, not to mention all the time spent configuring and fighting with webpack.
I don't think any form of "compilation" i.e. bundling, transpiling, minification etc is needed at all. Javascript can already dynamically load (additional) code files when needed, I don't understand why you need to bundle it in the first place.
I don't buy that the http request overheads are so big that it motivates all this complexity, and in the average case a user don't use every single page of the application anyway, so by bundling everything you are always serving "too much", compared to just dynamically loading additional code.
I don't think the difference is significant enough in this case.
That said, I do think there should be an alternative to minification+gzipping, like e.g. a compiled version of JS that is more optimized than a browser's own JIT compiler can do. Mind you, that might up being a larger package than the JS source code.
* hopefully will be
Minification strips comments too though, which may be undesirable in many cases.
In practice this seems to be a lost cause, and links to alternatively hosted source code is more common. Sadly this makes is simple to introduce subtle, harmful differences between the source and what is hosted.
Seems better just to have premassaged source available in a repo somewhere, or called out on the page itself for a downloaded archive.
Hard disagree. "Use What's Right For You™".
Of course there is value in understanding the platform beneath your framework or generic library, but that's just an extension of "understand what you're using and why".
Yeah in this case it doesn't need to; there's no extraneous or unused code or documentation blocks, and gzip (and comparable) compression is good enough, minification doesn't actually reduce the downloaded code size by that much.