I found that having a rule like this helped some too:
> * ABSOLUTELY DO NOT use `@deprecated` on anything unless you are explicitly asked to. Always fully refactor and delete old code as-needed instead of deprecating it
I had the same question. There are older and more established component libraries, so why’d this one win? It seems like a scientific answer would be worth a lot.
Alternate title: "How to break your website's styling for 10-20% of your users"
This is a nice reference, and some properties like `scrollbar-gutter` can be used for progressive enhancement.
However, many options listed will require some kind of fallback if `autoprefixer`/`postcss`/etc. doesn't cover it, and if you don't want to exclude a large fraction of your users.
It's reasonable in some cases to have both "new" and the old fallback code side-by-side until _your users's_ browser adoption stats indicate that you can delete the old fallback code without breaking a substantial number of users.
But the reality of using the new CSS hotness is that if the code is not supported by a % threshold that is much higher than many of these techniques show, it actually _increases_ your workload in the near term. You write new + the fallback + ensure that they don't interfere with each other.
P.S. Note the emphasis on _your users_ in the paragraph above. Global browser stats are fine as a basic reference, but your specific site/app's userbase demographics affect the actual percentages tremendously. That may mean you can use ALL of these new techniques today, or some, or none of them.
If your audience is primarily software developers, then after measuring you may find you can use these without a fallback. If it includes people in less wealthy communities or countries, or in countries with restricted access to mobile phone markets, you likely cannot.
I don't follow. Assuming that the caniuse data is also representative of your users (a big assumption), then it's 10-20% of either group. Adjusting the % for the subset that is "your users" can result in either a higher or lower %.
It’s a CLI tool and MCP server for creating discrete, versioned “libraries” of RAG-able content.
Under the hood, it uses an embedding model locally. It chunks your content and stores embeddings in SQLite. The search functionality uses vector + keyword search + a re-ranking model.
You can also point it at any GitHub repo and it will create a RAG DB out of it.
You can also use the MCP server to create and query the libraries.
It’s worth making this very clear for learners: A Computer Science education is **not** the thing that will prepare you to work and make money in many real-world _jobs_.
Some? Yes. Many? No.
This blurb from one of the course pages (unintentionally) says it well:
> Because the point of computer science isn't to teach you a language. Or to teach you to code. Or to teach you to be a fullstack software engineer. Computer Science is a very narrowly-applied applied math with wide-ranging practical usage. But if you strip away all the qualifying language, it's math. Which means it has certain overarching rules that are completely, totally independent of your implementation language.
In short: the point of Computer Science courses is not to teach you to do the thing that you will be doing when employed at the company that pays you.
Another:
> if you want to read white papers you're going to want to read Lisp
Most jobs are not about reading or writing white papers. Almost all Computer Science courses are an _academic_ pursuit, not a practical one, and are taught as such.
If your goal is to _work_ in the industry, this is _a_ path, but it is a very inefficient one.
Depending on what work you are happy with, 80%+ of the content here will not contribute to your success.
Will learning the things taught in these courses exercise your problem-solving and other mental abilities? Yes. Will they teach you broadly-applicable principles that you could apply to your work? Hard _maybe_, depending on their teaching and on how well you learn and generalize. In any case, you may well end up doing work that utilizes little of this.
If you want to work in research, a math-or-fundamental-sciences-heavy field, or with teams of folks creating new programming languages or database engines for example, then certainly some of these courses (and more) are required.
But it’s worth warning potential learners that a full Computer Science education is _neither an efficient nor a necessary path to a job in the field_.
What is?
One example: There is much available and satisfying work in building user-facing applications like web and mobile apps.
If your goal is to do that kind of work, then it’s best to relentlessly focus on the things that you will actually be doing at your job: Building things.
Broadly speaking, employers pay you using the money that they are making (or hope to make) by solving problems and/or providing services using software/applications that you will help write. So practice writing it. Learn to build real things: Mobile, web, or desktop apps that do a thing that _you_ would want to pay for. Find courses that teach that. Practice it. Hit a wall, research and figure out how to overcome it. Repeat. Submit PR’s to open source projects, especially ones where experienced maintainers review your code. Learn from that feedback. Read their code and understand how it comes together to create the app you are using. Have LLM’s review your code, even, if no skilled human is available.
Practice working with other people. Learn how to write and communicate clearly and unambiguously.
Find and fix bugs in open-source codebases.
Embrace that working in the field means a commitment to non-stop, career-long learning.
Later, after you’ve freed up mental space by mastering the basic mechanics of programming, begin researching and applying the techniques and methods for writing code that other people find pleasant to read, interact with, and modify/extend.
Build something that you can show to prospective employers.
You will also learn many more things from the people you work with.
Many of the hard skills you will learn through doing _these_ things will directly transfer to the work you do, because _it is the work you will do._
> * ABSOLUTELY DO NOT use `@deprecated` on anything unless you are explicitly asked to. Always fully refactor and delete old code as-needed instead of deprecating it
https://github.com/yokuze/aix-config/blob/f5094b5c5169261fae...
reply