81–90 of 109 posts
Didn't know about all of those units. q, mm, cm… scientific notation?! Also didn't know one could use counters already. Browser support is great. I thought it was still under approval. Amazing stuff, thanks
CSS is a far bigger spec than anyone knows. Did you know that you can put dots and spaces in your CSS classnames? Bonus points if you can figure out how to escape characters in CSS identifiers ;)
But scientific notation? C'mon
Earlier quoted context omitted.
It's not like this is a zero sum game. Attempts at improvement don't hurt at all, and in some cases can help a ton.
But they can hurt sometimes -- not all optimizations are always safe.
I have a slightly-related question for those of you familiar with Webpack, css modules (css-loader/style-loader), and perhaps React as well: is there any reason not to use the 'default' approach where the styles for the components are simply inserted in a (with unique, generated classnames)? To be clear: I don't mean philosophical reasons. I personally love letting javascript deal with the 'cascading' part and I don'…
When you're using a loader, the CSS still exists, it's just a big string in your JS bundle. By default, I believe css-loader/style-loader will use cssnano to minify the CSS within your bundle. What will be very interesting in the coming years (as the work gets done around it) is "full css" optimization. That is, when you know you have all of the styles for the whole page available to the minifier. If the minifier kno…
But this is probably quite a ways off.
Earlier quoted context omitted.
When you're using a loader, the CSS still exists, it's just a big string in your JS bundle. By default, I believe css-loader/style-loader will use cssnano to minify the CSS within your bundle. What will be very interesting in the coming years (as the work gets done around it) is "full css" optimization. That is, when you know you have all of the styles for the whole page available to the minifier. If the minifier kno…
In the long run I think we're more likely to end up with a full js-based styling approach that, similar to JSX, might look like CSS but really directly styles individual nodes and 'manages' them. But this is probably quite a ways off.
> I'm guessing that at nine nines that is pretty much a one anyway and it would not even change a single pixel on the screen. There used to be a bug with flex-wrap: wrap; where an element would wrap to the next line while it should have fit. You could fix it by instead using width: 25%; use width: 24.999999%; so it would be 25% on the screen but it would fix the problem so it didn't wrap to the next line. So you shou…
Earlier quoted context omitted.
> So minifying your stuff will only help you a little. True, the difference between 10KB compressed and 7KB minified+compressed is negligible for your visitors, but it still takes 30% off of your traffic bill.
This might be the only valid reason. But only for website that have a huge amount of traffic.
Earlier quoted context omitted.
One massive thing minifying does is dead code elimination (slightly less applicable to CSS but it still applies using some build stacks) We can build a "prod" version of the app and the minifying process will drop all the debugging code as well as any unused or uncalled functions from the output.
What JS Minifier do you know that does dead code elimination? I would have thought that understanding what functions of a dynamic language that can be safely removed would require parsing/AST analysis beyond those found in the typical minifier.
Earlier quoted context omitted.
I thought about it, but I'm way too shy for that. Not like it would lead to anywhere either, you know. :P Two years of teaching university, MSc in computing, love of automation, combinatiorial optimization without any significant amount of deep math skill, circuit design, gate array stuff, low-level CPU optimization stuff, hardware counters, microcontrollers, SQLite, Julia language, C, shell, a bunch more programming…
Some unsolicited advice: 1. I am not interested in jobs that focus on JavaScript, but I'd never say "No JavaScript". 2. when people ask for your CV, post a link (or if you're concerned about privacy, solicit requests via PM/email). 3. Your integrity, sillyness and attire are mostly immaterial to the job hunt. It's most appropriate for folks to make this kind of assessment during an in-person interview. 4. what is all…
this sounds like drab corporate thinking and i disagree wholeheartedly.
the attributes mentioned show his personality and warmth, and indicate the possibility of an interesting person and a creative thinker. as a hiring manager, my ears perk up at such things.
life is too short to play it safe. have fun!
Earlier quoted context omitted.
Number of HTTP requests is not a concern with HTTP2 server push and multiplexing. In fact it's usually better to have 2 fairly sized files that can be downloaded in parallel rather than 1 large file.
probably not true, since most http/2 implementations that I know of use time multiplexing, which means that only one element at a time can pass, so the time is exactly the same. I mean if I split a file in 10 exact pieces or if I split two files in the exact same 10 pieces as well I still have the same data. (Edit: Well basically two files have mostly more data since they both might contain a BOM or so)
And see Nginx's `http2_max_concurrent_streams` option: https://nginx.org/en/docs/http/ngx_http_v2_module.html#http2...
This looks like a fun project indeed! Unfortunately every time I read something about minifiers I got the feeling that people are optimizing the wrong problem. If you gzip data over the line it's already compressed. So minifying your stuff will only help you a little. The problem is on the client side. You can compress what you like but if the browser starts dropping frames because it has to compile/handle a ton of J…
Gzip compression over https is a vulnerabilty[1]. Depending on the scale, shaving a few kB here and there can amount to significant savings in the long run. [1]: https://en.wikipedia.org/wiki/BREACH
Say you have a document structured like [boring data] [secret data] [boring data]. I don't know if any existing compressor lets you do this, but the gzip file format (really the 'deflate' format used inside it) allows you to encode this (schematically) as follows:
[compressed boring data] || [uncompressed secret data] || [compressed boring data]
where each || is i) a chunk boundary (the Huffman compression stage is done per-chunk, so this avoids leaks at that level), and ii) a point where the encoder forgets its history - ie, you simply ban the encoder from referencing across the || symbols.
If you wanted, you could even allow references between different "boring" chunks (since the decoder state never needs resetting), just as long as you make sure not to reference any of the secret data chunks.
Edit to add: Also, if the "boring" parts are static, you can pre-compress just those chunks and splice them together, potentially saving you from having to fully recompress an "almost static" document just because it has some dynamic content.