Trabe
Asís & David
https://trabe-teaching.github.io/vanilla-all-the-things
Context
- We develop front and back with JS (15+ years)
- In the beginning there was the browser... hell
- Solution: vast ecosystem of libraries and tools
- We are old 👨🏻🦳👴🏻
Let go of the past!
Vanilla all the things
Disclaimers
- JS focus. Also valid with other languages/technologies
- Vanilla slides: HTML + CSS + JS (Just a bit)
Vanilla frontend
frontend developer eating vanilla
Vanilla forms
- Custom calendars ⮕
<input type="date" /> -
Time Picker ⮕
<input type="time" >- Beware: Designing a time input
- Form libs ⮕ FormData + string values
-
Validation libs ⮕ Browser validation
- Formik (44kB) + Yup (60kB)
- Check weight: bundlephobia
Modals
- Custom modals and dialogs ⮕ Browser
<dialog> -
Weight
- react-modal (25kB), react-focus-lock (15kB)
- Not only weight: modality and controlling the focus
- Don't fight the browser!
CSS
-
SASS, postCSS, CSS in JS ⮕ Plain CSS
-
Custom properties and calcs:
calc(var(--space-xl) / 2) -
Advanced selectors:
has,where,is
-
Custom properties and calcs:
- Metodolotions!
-
Scoping: CSS-in-JS, CSS modules
- Cannot fight the global CSS scope
- Runtime problems (style injection, SSR, etc.)
- Weight: Emotion (15kB)
i18n
-
Luxon, Moment ⮕ Temporal + Intl
- Luxon (72kB although can be pruned)
Summarizing
-
The bundling/npm hell
- weight
- security
- updates
- Run away from deps
- Always audit
-
Beware of the coziness of
npm install - Try not to fight the browser
Vanilla React
a pirate with a hook eating a vanilla cake, 3d render
Some hints
useEffectdeps ⮕ no depsuseCallback,useMemo⮕ nay- Redux, Jotai, etc. ⮕
useState,useReducer - Use React events, avoid DOM events (anti-vanilla 😉)
Vanilla full stack
full stack developer eating vanilla in the wild
Know your APIs 1
- lodash ⮕
Array.map,Array.forEach,Array.filter - Master some FP basics!
Vanilla-inception (vanilla inside vanilla)
-
SSE instead of Websockets
- Zero setup
- Simpler API
- HTTP transport
- Server push only: keep it simple
Vanilla backend
backend developer eating vanilla in a cave
Know your APIs 2
- yargs ⮕ util.parseArgs
- chalk ⮕ inspect.colors
- pino ⮕ util.debug
- fs-extra ⮕ fs (no extras!)
Know your APIs 3
-
axios, bluebird ⮕ fetch
- Less features but simpler and portable
- Features arrive (E.g.
AbortController). Better later than never!
DSLs
- Beware of DSLs to generate standards
-
E.g.
joi-to-json-schema- Simpler/compact API...
- ...but not developer-portable
Vanilla tooling
tools and vanilla ice cream
Dependency management
- yarn, pnpm ⮕ npm
- npm is usually enough. It's also ubiquitous
One tool to rule them all
-
Reduce. Simplify. Do not mix
Webpack + Jest + ESLint + Pretier ⬇ Vite + Vitest + ESLint + Prettier ⬇ Vite + Vitest + Rome ⬇ Rome?
Alternative tooling
- For simple features use standard solutions
- Jest ⮕ node test runner
- Nodemon ⮕ node --watch
- Husky ⮕
hooksPath - Lerna, Nx, Turbo ⮕
npm monorepo
Transpilation
- Ditch Babel! Use ESM and supported features
-
JS stages
- Stage-0: Nope
- Stage-1: Nope
- Stage-2: Nope
- Stage-3/4: Most probably already available
TypeScript?
Use plain JS because... reasons
Even more vanilla
- Cloud infrastructure
- Shell
- Editors/IDEs
- Etc.
Summing up
a hammer nailing a piece of vanilla cake
When to vanilla
- No vanilla if dealing with older browsers or node versions, or when the UI requires it
- Evergreen browsers, modern node (or Deno): go vanilla!
Is vanilla possible?
- Can I Use
- Look for green
- Know your constraints
- Always verify!
Keep up to the changes
- Know your APIs
- Be up to date: newsletters, feeds, whatever
Progressive enhancement
- Vanilla stuff to give basic support
- Then progressively enhance 😃
Do not fight the browser/environment
Be developer-portable
- Vanilla means Standard (or de facto standards)
- Standard means developer-portable
Vanilla all the things!
Questions?
We are always hiring
rrhh@trabe.io