Concepts that are /Global/

Locale
prod/devo
public_path?

...monorepo...

### Tenants
1. Aesthetic
5. Fast
3. Simple
4. Future
scoped
purity


Demonstration of /static/ website.


Home
Photographs
Writing (another word? lexicon, )
Data: I've watched these movies, I play these genre of games, top played songs, daily activities,
Opinion: game reviews, movie reviews, book reviews (lol). ronaldo, violin piano, snowboarding
Guestbook? giant ass form? (save user's progress via localstorage?)
Ops (website health, dashboards, etc)




less interfacing, layers of abstraction, indirection.

more /simplicity/, but /philosophy/.


reduce human error with /design/, not implementation/safety nets.

altering implementation to 'fix' human error (typos) is bullshit. name shit accurately. linters and good programmers fix
human errors. not extra implementation/overcomplicated design.

an Advanced (bloated) boilerplate with XXX dependencies (compare with other top boilerplates)

built on /principles/, /philosophies/, and /concepts/ instead of \tech\.

documented to shit with reasoning behind design choices, app structure/architecutre, naming conventions, etc.

javascript-fatigue ignorant/agnostic.









each README should have a high=level, top-points design decisions with /brief/ explanations, then more long-winded
stuff, then raw notes.









```
v = f*(d$)
```



			push													pull
Single		Promise: prom.then(data => ...)							function call: let data = fn()
multiple	callback/observable: source$.subscribe(data => ...)		generator/fiber: let data = generator.next().value








make a glossery, see redux.js.org glossery. or put readme definitions next to their respective folders.








convention != pattern/design? think reducers, actions...
no. convention is 'magic,' unexplained thing. pattern/design is explicit and self-defining.





monorepo, packages within this package. utils (for all utilities), styles for my /framework/ of styles.



difference/balance between bloat and what is required at the enterprise-level.



"Some assembly required" pattern.
SAR




convention for undersatnding, not for magic implementation.












FAQ: 

Lots of design choices. you will disagree with most of them, but you're wrong.


typescript
no


semicolons
no


default vs named exports
in folders, array as default, then named for individual exports. ????


javascript fatigue
stop crying

why package.json everywhere
/packages/.

leading commas
tryna be different


folder purpose/exports. only export collection through index, otherwise, if folder is not a 'collection,' but rather a
'package,' then... up to caller/implementor to 'assemble' parts?


redux
/concepts/

react
first of all, react engine, schedular, etc are pretty state of the art. alternatives don't compete.
second, the /concepts/ are pretty good too. a 'component' is just function. honestly, what you write is library agnostic
if you write well.



jsx vs hyperscript vs some other markup language?
tryan be different. html syntax is antiquated? 




why gulp vs npm scripts


why no css/styles in react components? why only css-in-js solution?
Would like to use ideal styling principles, reusing rules, semantics, etc. not hacks, one-time appplications, etc. use
css-in-js for dynamic styles that require logic, but that's all you should really need. but probs not, so i dunno.


why stylus vs sscs
because it's so much sexier and people are wrong.



resources:

https://developers.google.com/web
https://developer.mozilla.org/en-US/docs/Web
https://tools.ietf.org/