murex
linaria
murex | linaria | |
---|---|---|
55 | 46 | |
1,376 | 11,197 | |
- | 0.6% | |
9.6 | 8.4 | |
7 days ago | 14 days ago | |
Go | TypeScript | |
GNU General Public License v3.0 only | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
murex
-
Show HN: a Rust Based CLI tool 'imgcatr' for displaying images
This is how murex works too https://github.com/lmorg/murex/blob/master/config/defaults/p...
- Xonsh: Python-powered, cross-platform, Unix-gazing shell
-
The Bun Shell
I agree. I’ve written about this before but this is what murex (1) does. It reimplements some of coreutils where there are benefits in doing so (eg sed, grep etc -like parsing of lists that are in formats other than flat lines of text. Such as JSON arrays)
Mutex does this by having these utilities named slightly different to their POSIX counterparts. So you can use all of the existing CLI tools completely but additionally have a bunch of new stuff too.
Far too many alt shells these days try to replace coreutils and that just creates friction in my opinion.
1. https://murex.rocks
-
Jaq – A jq clone focused on correctness, speed, and simplicity
This is exactly what Murex shell does. It has lots of builtin tools for querying structured data (of varying formats) but also supports POSIX pipes for using existing tools like `jq` et al seamlessly too.
https://murex.rocks
- Murex rocks v5 is out
-
The Case for Nushell
Stable is a problem because a lot of these shells don’t offer any guarantees for breaking changes.
My own shell, https://github.com/lmorg/murex is committed to backwards compatibility but even here, there are occasional changes made that might break backwards compatibility. Though I do push back on such changes as much as possible, to the extent that most of my scripts from 5 years ago still run unmodified.
- Murex
- FLaNK Stack Weekly for 20 June 2023
- Show HN: A smarter Unix shell and scripting environment
-
Nushell.sh ls – where size > 10mb – –sort-by modified
This is similar to how my shell works. It still just passes bytes around but additionally passes information about how those bytes could be interpreted. A schema if you will. So it works as cleanly with POSIX / GNU / et al tools as it does with fancy JSON, YAML, CSV and other document formats.
It basically sits somewhere between Powershell and Bash: typed pipelines like Powershell but without sacrificing familiarity with all the CLI commands you already use day in and day out.
https://github.com/lmorg/murex
As an aside, I’m about to drop a massive update in the next few days that will make the shell even more intuitive to use.
linaria
-
How we improved page load speed for Next.js ecommerce website by 1.5 times
The code duplication occurred due to disabling the default code splitting algorithm in Next.js. Previous developers used this approach to make Linaria work, which is designed to improve productivity. However, disabling code splitting led to a decrease in performance.
-
An Overview of 25+ UI Component Libraries in 2023
KumaUI : Another relatively new contender, Kuma uses zero runtime CSS-in-JS to create headless UI components which allows a lot of flexibility. It was heavily inspired by other zero runtime CSS-in-JS solutions such as PandaCSS, Vanilla Extract, and Linaria, as well as by Styled System, ChakraUI, and Native Base. ### Vue
-
Why Tailwind CSS Won
I like Linaria [0] because your IDE typechecks your styles and gives you autocomplete/intellisense when typing styles. With Tailwind you have to look everything up in docs because it's all strings, not importable constants. Leads to a lot of bugs from typos that aren't a thing with type checked styles.
[0] https://github.com/callstack/linaria
-
I've decided to go back to using the Pages Router for now (long post)
And if you're wondering why I'm not using something like Linaria or some other runtime-less CSS-in-JS tool, it's simply because I don't want to have to spend my time setting things up and working around stuff and all that jazz. I just want something that works, and I've already got a personal scaffold for getting SC to work out of the box with Next, so, right now, it's either that or sticking to CSS/SCSS/SASS. For me, that is. I know it's such a small thing, but, honestly, one less headache for me is 2 steps forward.
- What's the best option these days for CSS in JS?
-
How bad is it to use CSS-in-JS with regards to the future of React?
I know that there are solutions that generate static css files (like vanilla-extract or linaria), but neither of them work with app router currently (1, 2).
-
JSS vs Styled Components? and why?
If you really want tighter interaction with JS, try a zero-runtine solution like linaria
-
What is the best CSS framework to use with React? why?
https://github.com/callstack/linaria is objectively the best. It's 100% styled component compatible, but with zero runtime which not only makes it substantially faster, but also makes it easy to do things like server side rendering, etc.
-
Why is tailwind so hyped?
tags inside SFCs are typically injected as native
</code> tags during development to support hot updates. <strong>For production they can be extracted and merged into a single CSS file.</strong></p> </blockquote> <p>There are also 3rd party CSS libs that do the same thing such as <a href="https://linaria.dev/">linaria</a>, <a href="https://vanilla-extract.style/">vanilla-extract</a>, and <a href="https://compiledcssinjs.com/">compiled CSS</a>. Which can be used in the event you're stuck with something that doesn't have baked in support via SFC formats (looking at you React).</p> <p>These are my preferred ways of handing it.</p> <ol> <li>Tailwind</li> </ol> <p>Option 2 is tailwind, which works backwards.</p> <p>That is, instead of the above with extraction where you write the styles, and the framework or libs extract them and replace them with class names, it's the other way around.</p> <p>You're writing class names first (which are essentially aggregated CSS property-values) which then generate and/or reference styles.</p> <p>It has the advantage of being easy to write (assuming you've got editor LSP, linting, etc), but as you've discovered, it's difficult to read / can get really messy really fast.</p> <p>As far as all the other claims on the Tailwind site, it's all marketing, at least 80% bullshit.</p> </div>
- Individual css for every component?
What are some alternatives?
elvish - Powerful scripting language & Versatile interactive shell
emotion - 👩🎤 CSS-in-JS library designed for high performance style composition
nushell - A new type of shell
Tailwind CSS - A utility-first CSS framework for rapid UI development.
tidy-viewer - 📺(tv) Tidy Viewer is a cross-platform CLI csv pretty printer that uses column styling to maximize viewer enjoyment.
styled-components - Visual primitives for the component age. Use the best bits of ES6 and CSS to style your apps without stress 💅
fx - Terminal JSON viewer & processor
vanilla-extract - Zero-runtime Stylesheets-in-TypeScript
jc - CLI tool and python library that converts the output of popular command-line tools, file-types, and common strings to JSON, YAML, or Dictionaries. This allows piping of output to tools like jq and simplifying automation scripts.
classnames - A simple javascript utility for conditionally joining classNames together
xonsh - :shell: Python-powered, cross-platform, Unix-gazing shell.
React CSS Modules - Seamless mapping of class names to CSS modules inside of React components.