I often ended up applying this simple principle to software, especially design systems, e.g. in atomic design where atom, molecules, organism, etc. Can be developed as layers with different pace of change and optimized around it.
I'm curious if anybody knows where the concept came from originally. Was there already something like that in Greek philosophy, or was introduced with the study of complex systems? Or maybe it was indeed from architecture?
Using a split keyboard helped a lot in that sense, even though when writing in a hurry is still hard to not go back to some level to wrong habits. I think it helps to find occasions where typing speed is not a must (e.g. anything that is not real time chat) and accept the speed loss while getting the muscle memory build up.
What i am really struggling, and maybe somebody has some advice here, is touch typing for programming. Writing words is not a problem, but many frequent symbols are so far away from the home row that even with a small keyboard are hard to reach and find precisely (especially (,),-,_,+,=,&,$,@).
Do you stay on the home row and stretch your finger like crazy? Or maybe temporarily move the hand to the upper row? Also for vim users... Never understood how to deal with auto brackets/quotes: when you get to the point where you need to go past the closing one, either you have to type it defeating the time saving of auto-insertion, or you need to do some kind of dance like using arrows or something like ESC + A
"Proper" typing as I was taught had you stretch. The right pinky is supposed to handle stuff like ")", "[" etc. I think this probably fine in non-programming uses where those keys are pretty rarely used but I feel like it has resulted in me getting pain in my right hand during typing. I now use a Kinesis Advantage 2 and have programmed it so common symbols are on the keypad layer on much easier to hit keys. I essentially have a "symbol shift" and it's something I wish more keyboards and laptops would have. This has pretty much eliminated my pain problems.
You may need some sort of threshold to ignore scrolls that are mostly vertical. It's really hard to scroll the page on mobile as the slider prevents the default scroll unless the movement is perfectly vertical
There is also a very small shop in wedding that only sells darts (and targets I assume). I passed by in front of it many times and always wondered how big the darting community must be for that shop to stay in business
Hey, which one was the shop exactly? At this point I'd like to give a try to his fried potatoes (not sure if calling them french fries would be always appropriate :) )
Pfff that was in 2014, hell if I remember. All I can remember is that it was 15-20 minutes walking from the Estrel hotel but that's as much as I can narrow it down.
Do you still have issues on Zalando.de? I just tried with Firefox from Linux and it seems to work correctly. Do you have more details in order to reproduce the problem?
Zola seem the most popular static site generator that allows you to generate a website without any JS bundle without using some strange hack.
This is the way I firstly stumbled upon it as I was looking for a fast way to generate a fully static site with the advantages of a generator and none of the overheads...
It may be limited for certain use cases but I think it would be my first choice for editing a static site without JS
See my other comment [0], it seems only JS based ones use stuff like composition of content while most others are template-based, which is not as powerful.
No not really. There is a large anti-javascript crowd who avoid anything and everything js based, and frameworks like Gatsby and NextJS require you to interact with js and its tooling.
With those two as the examples, I'd definitely agree with that. I'd regard both as frontend frameworks and I've never heard Next described as a SSG, though, but Gatsby seems to be used as such by fans of reckless overengineering (because I definitely need GraphQL for my blog).
Eleventy would be quite a bit closer to Hugo/Zola, but even then you'd have to use npm/npx to install and run it.
Pelican can easily generate no-JS websites. If a theme doesn't include JS, there won't be any, and (wild guess) half the themes don't. It's also extremely easy to tweak most themes not to use JS.
nowadays is quite rare to write classes in pure html, using any framework like react, vue and similar we are used to pass classes in a JS environment. Obscure and minified class names can be imported from a package using a perfectly meaningful name, also the same set of classes can be exported with many different names to even better usage specificity with no cost in size.
We overcome most of those issues using a mix of postcss compose and css modules with a custom hashing solution based on the actual css rule content, this allowed us to have virtually infinite semantically named components with a css bundle size that tend to stabilize around 20/25kb gzipped for a very big e-commerce use case and I doubt any other use case would go much higher than that size.
https://github.com/utilitycss/atomic
If you want to have a look (documentation needs some love, but the samples generated by the init do give a good idea of the concept)
we use this approach since more than a year with very good results. Regarding the data transfer it is not much of a problem because those classes usually get repeated a lot across the elements and having lot of repeated string is the best case scenario for gzip compression leading to basically no size impact.
https://github.com/utilitycss/atomic
This is the framework we developed to create atomic CSS component libraries if you want to have a look (documentation needs some love, but is quite stable)
Your HTML is still undeniably larger than something with dramatically fewer class attributes though, if you minify the same way. Hence my "single page" vs "many" difference.
gzip helps for sure, but I doubt `<class="card">...` ends up larger than `<class="a b c d e"><class="sub-a sub-b q etc"><class="repeat per element">...`.
there is of course a bit of difference in some use cases, my point is that in a real world scenario you often do not have
<class="card"> vs <class="a b c d e">
but more something like
<class="card"><class="stuff-inside-card"><class="other-stuff">
vs
<class="a b c d e"><class="b c f"><class="c d e g">
so in the long run you tend to have more repeated strings across even completely unrelated elements and that usually balances out the possible increase in non gzipped bytes.
But to be honest we did not had a detailed comparison with edge cases and it would be interesting to see when it actually may be a bad idea and when it is totally fine
when you're less "component-y" with your styles, yeah, that happens pretty frequently. careful styling is mostly rare (like all careful things)... but atomic styling seems to make the savings of careful styling effectively impossible, though I absolutely believe it helps the less-careful (especially the least-careful) cases.
