• 0 Posts
  • 89 Comments
Joined 3 years ago
cake
Cake day: June 13th, 2023

help-circle







  • I’ve worked at several places that didn’t have formatters when I started. they did by the time I left. you can incrementally adopt them and if it’s automated most people at worst don’t care. advocate for things you want

    reassignment and hoisting are the significant ones. behavior around this does just seem more intuitive than otherwise when it comes up, so I think telling especially new devs to use const arrow fn everywhere but classes is a reasonable rule

    hate to break it to you but it behaves like a variable either way. function just behaves closer to a var variable. const fns are less like variables since no assignment. intellisense/devtools all show them just fine. it really is just a minor aesthetic difference on the definition



  • semicolons? quotes? use a formatter and don’t think about it. I think js world has basically done this already.

    const is simpler. why would I declare an array as let if I’m not reassigning? someone can look at it and know they don’t have to think about reassignment of the reference, just normal mutation. ts has the further readonly to describe the other type of mutation, don’t abuse let to mean that.

    const arrow over named function? gets rid of all the legacy behaviors and apis. no arguments, consistent this, and no hoisting or accidental reassignment. the 2 places you should ever use named fn are generator or if you actually need this






  • I’m saying we weren’t taught when react was the way people wrote sites. if I was writing a site with pure html, css is great, especially modern css.

    but if I’m already using react and their abstractions, opinions on that part aside, I’d personally rather lean on the react component as the unit of reuse. tailwind removes the abstraction that you don’t need, since many people in react tend towards one scoped css file per component with classes for each element anyway

    at this point I’d be more inclined to say for many sites the api and data fetching things are the content and html+css is presentation. csszengarden is cool but I haven’t seen the html/css split help an end user, or really even me as a developer.



  • shadcn is the primary one for react at least. they’ve done a great job filling the space where you’re trying to build up a design system but don’t want to start from scratch, but they’re great if you just want prebuilt components too

    all the components build on something else like radix, and are pretty simple themselves. normally just the radix component with styles. Installing a component just copypastes the source into your project at configured locations.

    if you’ve ever fought against something like mui to get it to fit design changes or change specific behavior, shadcn is great. at some point the extension points of a library aren’t enough, but if you own all the code that’ll never be a problem.


  • except we generally use higher level abstractions now, like component based frameworks. If you’re writing raw html with tailwind and no library you’re doing it wrong and css is a better fit.

    well written straight css ends up building it’s own tree of components. if you’re using react too you’re either only selecting a single component (inline styles but have to open two files) or writing good css (duplicating the component hierarchy in css).

    tailwind is just the former but better since it encourages using a projectwide set of specific sizes/colors/breakpoints and small scope, the two actual problems with inline styles after organization and resuse, which react etc solves.



  • repr is generally assumed to be side effect free and cheap to run, so things like debuggers tend to show repr of things in scope, including possibly exit

    also then it behaves differently between repl and script, since repr never gets run. to do it properly it has to be a new repl keyword I imagine, but I still don’t know if I’m sold on the idea