rain-1

Purpose

Bootstrap knowledge of LLMs ASAP. With a bias/focus to GPT.

Avoid being a link dump. Try to provide only valuable well tuned information.

Prelude

Neural network links before starting with transformers.

WebReflection

About

Highly Experimental

If you are using this already, consider changes soon due the discussion around current ESX proposal.

Feel free to keep an eye on udomsay as that will be the implementation reference for consumers.

---

developit

export const h=(t,p,...c)=>({t,p,c,k:p&&p.key})
export const render=(e,d,t=d.t||(d.t={}),p,r,c,m,y)=>
  // arrays
  e.map?e.map((e,p)=>render(e,d,t.o&&t.o[p])):
  // components
  e.t.call?(e.i=render((render.c=e).t(Object.assign({children:e.c},e.p),e.s=t.s||{},t=>
    render(Object.assign(e.s,t)&&e,d,e)),t.i||d,t&&t.i||{}),d.t=t=e):(
  // create notes
  m=t.d||(e.t?document.createElement(e.t):new Text(e.p)),
  // diff props

sandren

Tailwind CSS best practices

Utility classes

1. When writing a string of multiple utility classes, always do so in an order with meaning. The "Concentric CSS" approach works well with utility classes (i.e,. 1. positioning/visibility 2. box model 3. borders 4. backgrounds 5. typography 6. other visual adjustments). Once you establish a familiar pattern of ordering, parsing through long strings of utility classes will become much, much faster so a little more effort up front goes a long way!

2. Always use fewer utility classes when possible. For example, use mx-2 instead of ml-2 mr-2 and don't be afraid to use the simpler p-4 lg:pt-8 instead of the longer, more complicated pt-4 lg:pt-8 pr-4 pb-4 pl-4.

3. Prefix all utility classes that will only apply at a certain breakpoint with that breakpoint's prefix. For example, use block lg:flex lg:flex-col lg:justify-center instead of block lg:flex flex-col justify-center to make it very clear that the flexbox utilities are only applicable at the

just-boris

.cache
dist
node_modules

TrueSlu

Animated CSS Gradient Border

Inspired by the github universe alert: https://s3-us-west-2.amazonaws.com/s.cdpn.io/173256/github-universe.png

A Pen by Mike Schultz on CodePen.

License.

willfrew

type Head<T extends unknown[]> = T[0];
type FnWithArgs<T extends unknown[]> = (...args: T) => void;
type TailArgs<T> = T extends (x: unknown, ...args: infer T) => unknown ? T : never;
type Tail<T extends unknown[]> = TailArgs<FnWithArgs<T>>;


// Lol
type Decr<T extends number> =
 T extends 10 ? 9 : 
 T extends 9 ? 8 : 

rauschma

This content moved here: https://exploringjs.com/impatient-js/ch_arrays.html#quickref-arrays

ncochard

When you create a npm package, remember it might be used in a browser or a server, or even a command line utility… For each package you create, please pay attention at what it will be used for:

1. Is it going to be used as a dependency to a nodejs application that is not bundled? (e.g. command line utilities)
2. Is it going to be used as a dependency to a nodejs application that is bundled? (e.g. AWS Lambdas)
3. Is it going to be used as a dependency to a browser application (always bundled)?.

• In cases 2) and 3) you want to allow for tree shaking.
• In cases 1) and 2) you want to benefit from the "ES6"/"ES next" features supported natively by nodejs.
• In case 3) you also want to benefit from the native support of "ES6" from your browser.

jayphelps

{
  "scripts": {
    "build": "npm run build:es2015 && npm run build:esm && npm run build:cjs && npm run build:umd && npm run build:umd:min",
    "build:es2015": "tsc --module es2015 --target es2015 --outDir dist/es2015",
    "build:esm": "tsc --module es2015 --target es5 --outDir dist/esm",
    "build:cjs": "tsc --module commonjs --target es5 --outDir dist/cjs",
    "build:umd": "rollup dist/esm/index.js --format umd --name YourLibrary --sourceMap --output dist/umd/yourlibrary.js",
    "build:umd:min": "cd dist/umd && uglifyjs --compress --mangle --source-map --screw-ie8 --comments --o yourlibrary.min.js -- yourlibrary.js && gzip yourlibrary.min.js -c > yourlibrary.min.js.gz",
  }
}