andyhmltn
Joined 14 years ago
Joined 14 years ago
CSS-in-JS solves a lot of problems that people that have been writing 'real CSS' have been experiencing for a long time. Writing CSS for very large applications that deal with lots of shared components across engineering teams is a hard task. Some of those problems are alleviated by libraries like styled-components.
It's not for every use case and should only be used when there is a genuine need (rather than 'because it's shiny.') But shrugging off CSS-in-JS because you don't understand it is a bit silly.
Took it to an Apple store and was quoted £700 to fix it which is equivalent to almost half the cost of the laptop. For a single key. Absolute insanity.
What unreleased APIs are you needing to warrant this? We've used any a couple times, but usually just as a placeholder until the data model is locked down.
>- Development time is slower than writing in regular JS/React. This started to become a major issue due to the nature of our project being a prototype (fast iterations on ideas and features).
Again, I can't say I've had this experience. Development time is _initially_ a tiny bit slower, but once you've setup types, the time saved from fixing type related issues adds up very very fast. Also, autocomplete / autoimporting has actually sped up my development time hugely. Not having to worry about figuring out relative paths or imports and just being able to type a component to import it is magic.
>- Lots of frustration when a package doesn't have types (although most major ones do have them).
This is true, but I've found that 95% of the packages we use do have types. The few that don't, tend to be very small indie packages that don't do a lot, so the lack of types isn't a huge issue.
Is this one of those instances where the word 'quantum' is used to hand-wave away weird ideas?