hownowbrowncow

We're at the point where each day this week I lose PR comments and have to come back later. Constantly slowing down work.

Prettier and other format-on-save tools remain a huge quality of life improvement. I also think it found success because the defaults and choices outlined in the article were very wisely chosen: very readable in almost every context. The right tradeoffs were made both in printing logic and psychology with options/rollout.

One other subtle interaction that is hard to live without now: watching code shift with format-on-save is the fastest feedback on whether code will build/run. Don’t need to look at another console for a syntax error almost ever.

Amazing.

One wonders how you might gain a representation of physics learned in the model. Perhaps multimodal inputs with rendered objects; physics simulations?

I work on the marketplace team—most of our software engineering roles are remote friendly, especially on the marketplace and transport teams. I recommend applying as we have a strong ratio of remote folks and can place you in teams where that’s well supported.

I'm quite sad they have removed 3D Touch from the phones. A minor feature I really enjoy with quick peeking — and bummed to lose that touch information for apps like Procreate Pocket and other drawing tools.

Yikes.

I agree that this might help you move quickly when starting a project and might be a fine approach for a small prototype or personal site (or, more unkindly, in a consulting project). But you pay a huge cost: maintainability. There is no encapsulation at all, not to mention the pain of having all these generic classes floating around, colliding with anything that might accidentally match. I’ve worked on projects like this where huge HAML views chain many of these functional CSS classes. It makes it very difficult to accommodate new external components or design updates which I would say are pretty much inevitable in any product company. Even if you don’t add anything new, good luck updating the entire system to adjust the padding on all buttons unless you were disciplined enough to truly create encapsulating classes (which is really the opposite approach of functional CSS anyway).

I really think CSS modules got it right (or similar approaches where you have a unique class name per component). Our team approaches component styles like a UIView in iOS—it should render acceptably with reasonable constraints. This means any parent component / view can render this and set display: block, flex, etc and the contents should largely adapt. These days this is pretty easy with flexbox and grid. Even better—you can ensure that the markup classes stay private to you and only allow modifications through JS (or mark some classes as :global). Even better than that—your components can adopt delegation or renderProps to allow parent views to replace / modify with their own markup so everything in the component can truly be encapsulated.