Fork me on GitHub
#off-topic
<
2020-10-27
>
sova-soars-the-sora13:10:19

This set by Boris Brejcha has been my preferred coding jam for the last year almost. https://www.youtube.com/watch?v=vqz8c4ZP3Wg

👍 24
sova-soars-the-sora13:10:37

In case you need something hype and low-key that won't be cerebral

sova-soars-the-sora14:10:56

I thought of a funny metaphor for what happened with chromium / chrome and view-source... even though Inspect Element has a working copy of the source code, the browser is like a vehicle, and they created a whole new steering wheel to control just the radio. And of course, it would be a lot of work to tie a whole new steering wheel in with all the old machinery, so they almost opted to "wontfix" that bug because "so few people use it" ... and I was at a loss for words... do chromium devs use firefox for javascript and such? x) And when I pointed out that dev-tools has inspect element working no problem, someone said, there is a suggestion to simply use that instead of "blink->view source" (what they call it). So yeah, should we just wire the original steering wheel in to the radio or go on with this second steering wheel? I mean, the choice was obvious to me, but it's amazing that things [projects] that get really big can have very redundant approaches that make basic functionality questionable. Which is another reason why I enjoy Clojure -- I feel like the design patterns that it forces you into (or gently coerces into) are quite good and quite resilient against such disadvantageous approaches -- because if you're writing the same code more than once you ought re-evaluate how you're doing it. Unless it's for clarity/readability/long-term maintain-ability.

sova-soars-the-sora14:10:41

If you're unfamiliar with the original issue: chrome/chromium issues a NEW http request when you hit view source rather than spitting out what it rendered. In the words of jesse lee peterson "i'm like what tha!"

Gleb Posobin14:10:44

@sova There is devtools to see what chrome renders, but "view source" shows the html that chrome received. Those are different, since on many websites the html is invalid, and chrome has to work around that. I don't see why it is better for chrome to carry around the original source in memory, just so that some users can use view source without the second request.

Gleb Posobin14:10:09

Recent example I stumbled upon: this blog post has the closing html tag right after head: https://applieddivinitystudies.com/wilbin-rationalists/ View source shows that, devtools doesn't.

sova-soars-the-sora20:11:56

sounds like they made it wrong to me

Gleb Posobin20:11:37

Who are they here?

Gleb Posobin15:10:44

Plus the tree in devtools is affected by js, includes elements added by react, by the extensions, etc. I don't see what chrome team is doing wrong here, they could carry the original html around, but that takes memory and would be useless for the absolute majority of the users, even among the web developers.

souenzzo17:10:58

The size of your classpath:

clj -Spath 2> /dev/null | tr ':' '\n' | wc 
    526     526   50900
Mine has 526 path's and it's about ~50kb

seancorfield17:10:48

Interesting. Ours at work is smaller, for a 105k line monorepo:

396     397   30733

👍 3
souenzzo17:10:33

I think that this project that I'm working contains every clojure lib ever made 😅 😢 😱 😱 😱 😰

3