deepanchor
Joined 13 years ago
Karma
473
Submissions
71
Member since
Oct 31
Recent submissions
Comment · 5 years ago
Comment · 5 years ago
I learned a lot from reading the Perkeep [1] codebase (formerly Calimstore). One of its core developers is Brad Fitzpatrick (former Golang team member) so you can be fairly confident it’s idiomatic Go.
Comment · 6 years ago
Definitely keeping an eye on Stylex! To me, it looks like the optimal solution to the CSS styling problem.
Comment · 6 years ago
Tailwind is not for me, simply because I don't want to have to learn yet another DSL that may or may not be abandoned in the future. I understand this is a personal decision though, but I've been burned too many times by fads.
My ideal CSS solution which doesn't seem to exist yet:
- Be able to write plain old CSS in JS/TS directly within a React component's tags, with a JS object literal
- Automatically generate atomic classes for each CSS rule (or block of rules) and have the system reuse those rules when the same styles are used elsewhere (no rule duplication means smaller bundle sizes for SSR, plus you get the semantic clarity of using plain CSS rules)
- Compiled, with zero or near-zero runtime overhead and critical path extraction, all cacheable by the browser. I don't want a huge runtime just so that I can dynamically apply a background colour.
The thing that comes closest to this is probably something like Linaria [1], but it relies on tagged template literals instead of object literals which means I can't use autocompletion. Their API for dynamic styling also relies on HTML data attributes, which is a little clunky.
Stiches [2] is another interesting project, however adoption doesn't seem very high and it seems to create superfluous wrapper nodes which can cause performance degradation in large VDOM trees. There's also no mechanism to colocate styles within a component's tags.
CSS Blocks [3] looks very promising also, but it doesn't allow co-location of styles with React components (you need to make a separate CSS file for each component).
[1] https://github.com/callstack/linaria
Comment · 7 years ago
Eh, as a non-IDE user myself, I think you’re being a bit harsh as I don’t think that was the spirit of the author’s comment at all. In fact I found it to ring quite true and if there was any name-calling, I certainly did not feel offended. The fact is there is a certain luddite-esque aesthetic to working in a simple modal editor like Vim (or Emacs in your case) and everyone invents their own dogma to follow, to a certain extent. I happen to find that there is merit in using simple tools, and latent benefits like really getting to know a code-base in a way that predictive fuzzy autocompletion will not allow me to do. There is no global optima when it comes to people’s workflows, just individuals finding what works best for them.
The only thing CQRS dictates is that a system's read models are separate from its write models.