While I agree with most of the advice given, some are subjective and opinionated and do not necessary reflect universally accepted best practices.
For example, I prefer SASS/LESS over css-in-js. But again, this is my own subjective preference. Similarly, I prefer to use Elm, ReScript or PureScript if I'm overly concerned with the correctness of the app. Otherwise, (JS + tests) is better than TS for fast development and less overhead of maintaining a mountain of TS types that often leak bugs anyways.
Also, it would be better to zoom out and think why React.memo helps. Perhaps restructuring the react tree would make several instances of React.memo redundant.
I know I'm in the minority but I hate hooks because of all the pitfalls one needs to remember when using them, especially when there are nested 2 or more levels deep. Check out RefractJs; no need for hooks. HoCs are better because they're a universal pattern; not a library's API.
Otherwise, (JS + tests) is better than TS for fast development and less overhead of maintaining a mountain of TS types that often leak bugs anyways.
I have been thinking this as well. I would only want to use rescript or elm, or just js. Of those three options, I am slightly leaning towards js with tests because I don't have to deal with any special tooling. If elm gains more momentum, or rescript launches a huge framework developed in rescript, I would make those my default. I am disappointed that Elm hasn't won (yet?). (I very rarely build small front ends, so my opinions here don't have a lot to back them up).
I have also been thinking about leaving business object data as json (e.g. package.elm-lang.org/packages/1602...) instead of converting to records, when using elm or rescript, because I think most business objects will eventually want some user defined fields.
Elm is my go-to for a nice developer experience. For me it has "won".
I let my IDE (Atom/elmjutsu) generate decoders/encoders for me. You can use korban.net/elm/json2elm/ if your preferred editor doesn't support generating them. I don't recommend circumventing decoders.
I only decode/encode the data I need. Sometimes (usually) I want my model to look different that the data in the API, so I make tweaks for that. Decoding even helps me find flaws in my assumptions on data coming from the API too!
I recently started a JS project and had trouble with conflicting versions of npm dependencies. It took me a day to balance the correct versions and still couldn't use the latest version if one of the core dependencies. At some point, I was very tempted to switch to Elm because dependency management is easier. I just didn't want to handle encoding/decoding of JSON; lazy 😂
Css in js and typescript are best practices and every day more companies are joining the bandwagon asking for these skills. While I do personally also like to take a backseat in the bandwagon, css in js and typescript are quickly becoming industry standards (typescript already is) and you're going to hurt your career if you refuse to become proficient in these skills.
Claiming css-in-js and TS are best practices is incorrect. However, claiming there's momentum behind these technologies is correct.
TS, in my opinion, is the new Java. It'll build a massive pile of horrible codebases that future developers will have to maintain. It's an opportunity as well as a curse 😅. Pure FP languages with clear FFI are better for guaranteeing the correctness of apps.
I've worked extensively with existing codebases in both Java, Typescript and Javascript. Your claim that Typescript is the new Java is just a little bit ridiculous tbh... If you want to make such a crooked comparison, Typescript is more comparable to C# than Java. The pile of horrible codebases you talk about, I've seen them but they were all in Javascript.
While I agree with most of the advice given, some are subjective and opinionated and do not necessary reflect universally accepted best practices.
For example, I prefer SASS/LESS over css-in-js. But again, this is my own subjective preference. Similarly, I prefer to use Elm, ReScript or PureScript if I'm overly concerned with the correctness of the app. Otherwise, (JS + tests) is better than TS for fast development and less overhead of maintaining a mountain of TS types that often leak bugs anyways.
Also, it would be better to zoom out and think why React.memo helps. Perhaps restructuring the react tree would make several instances of React.memo redundant.
I know I'm in the minority but I hate hooks because of all the pitfalls one needs to remember when using them, especially when there are nested 2 or more levels deep. Check out RefractJs; no need for hooks. HoCs are better because they're a universal pattern; not a library's API.
I have been thinking this as well. I would only want to use rescript or elm, or just js. Of those three options, I am slightly leaning towards js with tests because I don't have to deal with any special tooling. If elm gains more momentum, or rescript launches a huge framework developed in rescript, I would make those my default. I am disappointed that Elm hasn't won (yet?). (I very rarely build small front ends, so my opinions here don't have a lot to back them up).
I have also been thinking about leaving business object data as json (e.g. package.elm-lang.org/packages/1602...) instead of converting to records, when using elm or rescript, because I think most business objects will eventually want some user defined fields.
Elm is my go-to for a nice developer experience. For me it has "won".
I let my IDE (Atom/elmjutsu) generate decoders/encoders for me. You can use korban.net/elm/json2elm/ if your preferred editor doesn't support generating them. I don't recommend circumventing decoders.
I only decode/encode the data I need. Sometimes (usually) I want my model to look different that the data in the API, so I make tweaks for that. Decoding even helps me find flaws in my assumptions on data coming from the API too!
There's elm-graphql if that's an option for you.
I recently started a JS project and had trouble with conflicting versions of npm dependencies. It took me a day to balance the correct versions and still couldn't use the latest version if one of the core dependencies. At some point, I was very tempted to switch to Elm because dependency management is easier. I just didn't want to handle encoding/decoding of JSON; lazy 😂
I would have just used an escape hatch like package.elm-lang.org/packages/1602...
💯😂
I agree with everything. However I still love hooks💯
TailwindCSS is the shit. css-in-js is the worst and performs really badly.
Css in js and typescript are best practices and every day more companies are joining the bandwagon asking for these skills. While I do personally also like to take a backseat in the bandwagon, css in js and typescript are quickly becoming industry standards (typescript already is) and you're going to hurt your career if you refuse to become proficient in these skills.
Claiming css-in-js and TS are best practices is incorrect. However, claiming there's momentum behind these technologies is correct.
TS, in my opinion, is the new Java. It'll build a massive pile of horrible codebases that future developers will have to maintain. It's an opportunity as well as a curse 😅. Pure FP languages with clear FFI are better for guaranteeing the correctness of apps.
I've worked extensively with existing codebases in both Java, Typescript and Javascript. Your claim that Typescript is the new Java is just a little bit ridiculous tbh... If you want to make such a crooked comparison, Typescript is more comparable to C# than Java. The pile of horrible codebases you talk about, I've seen them but they were all in Javascript.
css-in-js is horrible ,stop your self please.