On macOS and Linux, I haven't noticed any performance issues with Emacs. On Windows, however, the performance is significantly worse. To make matters worse, I even have to patch w32.c just to get it to build:
@@ -10298,7 +10298,7 @@ w32_read_registry (HKEY rootkey, Lisp_Object lkey, Lisp_Object lname)
/* mingw.org's MinGW doesn't declare _dstbias. MinGW64 defines it as a
macro. /
#ifndef _dstbias
-__MINGW_IMPORT int _dstbias;
+__MINGW_IMPORT long _dstbias;
#endif
/ Fix a bug in MS implementation of 'tzset'. This function should be
https://nats.io is easier to use than Kafka and already solves several of the points in this post I believe, like removing partitions, supporting key-based streams, and having flexible topic hierarchies.
I greatly prefer redis streams. Not all the same features, but if you just need basic streams, redis has the dead simple implementation I always wanted.
Not to mention you then also have a KV store. Most problems can be solved with redis + Postgres
Don't, under any circumstances, let it come into contact with an untrusted network. Anyone who can connect to your Redis service gets arbitrary remote code execution.
Honestly no, which was my favorite part. So easy to spin up, "just works" the way you expect. It's night and day from a lot of the other solutions in the ecosystem.
1. Core NATS, an ephemeral message broker. It's a lightweight pub/sub system where routing of messages is based on wildcard paths. All in memory, lightning fast, extremely lightweight. You can use it for RPC, queues, broadcasting, file transfer, anything.
2. JetStream, which is a Kafka/Pulsar-like log built on top of Core NATS. Streams are indexed, meaning there's no strong need for partitioning or consumer groups, since readers can efficiently filter the stream by interest (you can still partition for write performance). Supports both durable and ephemeral consumers, in-memory streams, ack/nack, priority groups, deduplication, exactly-once delivery, hierarchical clusters, offline clusters ("leaf clusters"), mirroring, etc.
I often find it difficult to explain the magic of NATS. It's a communication model that doesn't really exist anywhere else, as far as I've seen. The closest might be ZeroMQ.
JetStream could be explained as "Kafka for people who don't want to administer Kafka". It's very low-maintenance, very easy to use, feels super lightweight, and still offers much of the performance and reliability of Kafka, as well as a much richer feature set that maps better to what people may want from a streaming log.
I came here to say just that. Nats solves a lot of those challenges, like different ways to query and preserve messages, hierarchical data, decent authn/authz options for multi-tenancy, much lighter and easier to set up, etc. It has more of a messaging and k/v store feel than the log Kafka is, so while there's some overlap, I don't think they fit the exact same use cases. Nats is fast, but I haven't seen any benchmarks for specifically the bulk write-once append log situation Kafka is usually used for.
Still, if a hypothetical new Kafka would incorporate some of Nats' features, that would be a good thing.
Using a type is to contrived, because your commit will often include e.g documentation and a feature. Splitting them for the sake of following this pattern makes no sense.
I've been working with Clojure on and off for over a decade, and I've found it exceptionally efficient at solving a wide range of problems—making it one of the best general-purpose languages available. However, I sometimes envy the capabilities of OTP, which provides a straightforward way to build fault-tolerant servers without the overhead of managing containers or databases.
Additionally, while the growing number of compile targets in the Clojure ecosystem is impressive, it can also create confusion for newcomers. Whether it's compiling to native code with Jank, generating quick script snippets with Babashka, or using subsets of ClojureScript like sci or cherry, the diversity is both a strength and a challenge. I believe a concerted effort to unify configurations across these targets would help streamline the ecosystem and make it easier for developers to choose the right tool for their needs.
CSS has become significantly more user-friendly than in the past, with most browsers now behaving consistently. It's worth learning as there is no build step involved, and it avoids cluttering your markup with excessive code.
You could opt to use style attributes directly within your HTML. Historically, we avoided this to maintain a separation of concerns, but it's puzzling why some prefer reintroducing similar methods. Is it just to save a few keystrokes?
Using style attributes even seems more straightforward since it doesn't require translating code in your head.
These days tailwind is often paired with a component abstraction system that takes place of css classes as an abstraction system. Component abstraction achieves an even more powerful separation of semantics from styling, compare:
<h1 class=hero>Cool page</h1>
vs:
<Hero>Cool page</Hero>
In both cases you need to go find the “hero” abstraction, but in component world we are also abstracting over the HTML tag name in addition to whatever styling stuff.
When it comes to defining the “stylistic detail” in either case, it has been separated from the “content” which is our page source file. I am happy to pay a build step to get better separation of concerns - content from presentation.
no, a single html attribute containing "relative before:absolute before:top-0 before:h-px before:w-[200vw] before:bg-gray-950/5 dark:before:bg-white/10 before:-left-[100vw] after:absolute after:bottom-0 after:h-px after:w-[200vw] after:bg-gray-950/5 dark:after:bg-white/10 after:-left-[100vw]" is not "easier to read" (example taken at random from the Tailwind homepage)
Individually applied styles kinda defeats the purpose of cascading style sheets though.
As someone who's quite conversant with regular CSS, I really did like the ease of applying whatever style I wanted right in the code without needing to "worry" about whether this div is a "panel" or a "hero" or whatever, but it really does tend to make a huge mess of my HTML in very short order.
You might like Styled Components then, if you're using React anyway. Not sure if there's similar systems for other frameworks. I don't consider it pointless make-work to develop a consistent stylesheet to use throughout your app though.
I believe the Babel plugin eliminates most of the performance cost.
The naming is double-edged. Often you want to re-use your styled element, so the fact that it has a name from the get-go makes that really easy. But you're right, sometimes it's annoying to pull bits out that you didn't really want to.
Ultimately I went back to CSS Modules. I just don't understand why I'd want to the appeal of Tailwind.. I'd have to learn a new DSL that ultimately gives me less control.
The problem is that with bootstrap I have card, table, etc. With tailwind I have an unreadable alpabet soup when I am not a designer but a developer and am not familiar with tailwind.
And then you build on that, and you have card-alert, card-message card-message-small, card-body-alert, card-body-message, card-form, card-login-form together with extra sass variables for them.
And then you ask "why not just have variable for each component, not each component's style?" and this is where tailwind steps in.
I greatly agree with you, but should mention that there is DaisyUI which is a Tailwind plugin that adds these for you. It seems inspired by Bootstrap and others: https://daisyui.com/
This is the big one for me.
In any big enough or unfamiliar frontend project, my go-to way to explore the codebase is to launch the front-end, and use the inspector to check the elements, and then search-back in the codebase the relevant classes to see what page/component display that, and how does it fetches the data.
If there is only an alphabet soup, I no longer have a simple set of classes I can grep the codebase with to quickly find the relevant components.
This is just not true. You can absolutely grep the soup (I do it daily). Most UI components share a lot of common baselines but include a specific modification for use in place (often a color or extra spacing). That means most of the time, the entire class string is unique to that element, even if the classes themselves are not. At most, you might have a couple of duplications, but then you should probably be looking at a template level component if the functionality is related.
`mx-4 py-2 rounded-xl shadow bg-green-500` is just as easy to global-search for as `notice--success`
Most websites are maybe 20 components and localized pages. Not exactly that hard to name and keep constant. Can not think of names, just ask one of the AIs.
> - Easier to read as it's inline with the rest of your HTML
Only if you do a few styles. The moment you have mobile + desktop + dark/light you start to leave lines half a mile long.
> - Not having to manage a separate file and remove unused components
Counterpoint: Components/templates are still the same hell to manage.
> - Being able to use media queries, which I couldn't do in a style tag
CSS ... literally the bread and butter.
> - No risk of changing a class that is used elsewhere. CSS has global scoping which has its benefits but is risky.
Counterpoint: You will end up with styles that are applied to parts, then copied, forgotten to change, and then have a mix of styles that conflict with each other.
And you do not use global scoped CSS, but localized per page. All you need is local CSS + a single parent id/class and voila. Local scoped will not mess with global. Do not do stupid stuff like button { style style style }. No, make global scoped iButton, so you never run into the issue off having parental styles doing funny things to child styles.
Let me introduce our lord and savvier called Nested CSS + Named CSS tags ... Reusable, standardized, ...
Tailscale is frankly a solution for front end JS frameworks, and less for any server rendered html. Use local CSS for html pages that are really local. No need to make global CSS for price cards that you only use on one page. But if something is used over multiple pages, buttons, ... that is global. Simple, no?
Ironically, i am in the process of actually removing Tailscale everywhere because the recent 3 > 4 upgrade screwed so much up. What stayed good? My actual CSS nexted/tag components that i never.
That is one of the issues with frameworks in general, etc, things between versions can really mean a lot more work vs just having everything "basic".
I feel a lot of issue that people have with CSS are more related to not having a proper understanding about CSS, and ignoring some basics. Like do not style base tags. Use nested + custom naming tags, local css + a local id/css and you have no issue with overlap. Best of all, you gain the ability to make easier reusable components as your CSS are the components, not some JS/... whatever call you need to do to render something. It gets messy fast if your breadcrumbs is a components with items, and you need to change something later on. But if its a basic breadcrumbs{} css, adding feature is just a matter of adding naming.
Trust me, took me years to get out of this mindset (and it helped that CSS evolved a lot but most people do not even realize that CSS today != what they know/grew up with)
It's because we've normalized React and tight coupling. Styling belongs to components, not in design systems. I feel the JavaScript-first engineering ecosystem needs brave new design-led companies, who see the power of modern CSS and systematic design.
> Historically, we avoided this to maintain a separation of concerns, but it's puzzling why some prefer reintroducing similar methods. Is it just to save a few keystrokes?
In bigger projects, if we start looking at the amount of files one has to deal with, Tailwind becomes very appealing.
We've went through the regular `.css` route but then you have weird names, and, potentially, duplications or even conflicts.
`css modules` is an option but you've now essentially duplicating the number of files that you have for each component / page.
`sass` or `less` essentially bring the problems from `css modules` and regular `.css` into one.
I don't inherently like or dislike Tailwind (although I very much started by absolutely disliking it) but you feel its value in a project with 200+ files composed of components and pages
The parenthesis are a strength that allows for faster editing and easier parsing. Although I respect every en-devour to have fun with code, I hope people don't run with this as a serious option. It would be better to have editor extensions that emulate this with regular Clojure code; that! I could get behind.
@@ -10298,7 +10298,7 @@ w32_read_registry (HKEY rootkey, Lisp_Object lkey, Lisp_Object lname) /* mingw.org's MinGW doesn't declare _dstbias. MinGW64 defines it as a macro. / #ifndef _dstbias -__MINGW_IMPORT int _dstbias; +__MINGW_IMPORT long _dstbias; #endif
/ Fix a bug in MS implementation of 'tzset'. This function should be