Just a suggestion as well, theres countless 'water recipes' that let you easily do the same thing for a fraction the price. They arent doing anything complicated. Some mixes are simple two ingredients, some go up to several, but all are pretty dead simple.
Lets you fiddle and fine tune things more for your own preferences too.
I think the summary at the beginning of your first video is misleading; it's not a way to "trade space for time", at least not in an arbitrary program. The real statement is a bit odder to wrap one's head around -- "every problem solvable in t time on a multitape Turing machine is also solvable in close to √t space".
For a Turing machine that already solves a problem in n time and √n space (in other words, a lot of them!), it doesn't say anything.
When you convert a generic Turing machine into a Tree Evaluation instance, you end up with square-root space with respect to the original runtime t, but the new runtime will be far, far slower. IME, with these types of circuit reductions, the runtime typically becomes exponential in the space required, which is just about 'as long as possible'.
If we're being pedantic, it's trading time for the space guarantee.
I think that unpoly(https://unpoly.com/) would be easier for that use case. htmx generally expects succesive http requests to only return the fragment of html that will be swapped into the target, not the entire page. So you generally want something server side that can check the request and either return the full page (either for a first hit or disabled javascript) or return just a fragment (an htmx request).
Unpoly has similar goals to htmx, but by default works with full page responses, swapping only the identified content in the page.
You're correct that it's the general expectation, but it is possible to select certain elements from the response using `hx-select` [1], so it is possible, just not particularly efficient...
Unpoly is great. I used it a few years ago for reimplementing the UI of an application built with a traditional MVC framework and I was impressed with the results. Nobody could tell it was not React/vue/etc from the outside and the frontend code was quite simple and minimal.
Technically feasible? Absolutely. You can already create interactive documentation just with client side JS in your Hugo generated site. And HTMX is just a client-side JS system for building that sort of JS-required interactivity in HTML alone without directly touching JavaScript. That said, I don't think the tooling to make this simple to get started with in Hugo is there yet. Though you could certainly build it.
Because you need to hide nav on mobile, since accessibility requirements from google and other web crawlers will require it to fill the much of the page, or your site won't be indexed.
For anyone who wants to see the logo in action, I'd like to recommend checking out the SVG Playground link. It's a great tool for exploring and manipulating SVG code, and it makes it easy to see how the logo looks on different backgrounds and at different sizes.
It depends on if we get a PR anytime soon. At the moment we're just 4 engineers, and unfortunately React.Native is not on the top of our list. I'd say we'll have it in 2 months unless we get a PR earlier
Click on the leaderboard and prepare to be dismayed. 255 WPM @ 99% accuracy doesn't seem real. A cursory YouTube search shows the best typers maxing out around 210...
There is no demo or instructions on how to run it, and nothing linked that I could find.
I tried to use it locally after cloning the repo and gave up after spending some time trying to figure out how to start it as a node app. `npm start` didn't work. Just serving the contents of the `public` directory doesn't work either. This might be obvious to someone familiar with Node apps, but of course not everyone works on front-end web development.
It would really help if the developers added a couple of lines to their README explaining how to run this software.
I would say the Emacs user mindshare has shifted somewhat to Doom. There are a lot of Doom fans on r/emacs now, and the Discord is huge compared to what it was. Many new contributors are cropping up. Even some developers of well-known packages, like org-roam, have switched to Doom. Take it from him, not me! https://blog.jethro.dev/posts/migrating_to_doom_emacs/
Compared to Spacemacs, which has complex abstraction layers over Emacs, Doom seems to be much lighter. It's easy to get into Emacs browsing Doom's modules. Plus, the BDFL model is serving Doom quite well since Henrik is a god-tier BDFL. He's constantly active and keeps Doom very focused on performance with sensible defaults and consistent programming style. Docs are a focus and are growing, and they're extremely comfortable to browse in Doom Emacs itself, as well as the Doom and Emacs source code of course.
None of this is meant to attack Spacemacs, it did and does much for Emacs, and many swear by it. But I would say Doom is better these days.
Yeah, I was aware of that but the way I wrote it was ambiguous, sorry. I meant “even some people who have the chops to maintain complex custom configs are switching to Doom”.
