barryhoodlum

I don't know how people live with the mental burden and clutter of dozens of tabs of things they'll (if they were honest with themselves) never get around to reading. It's like watching one of those TV shows about hoarding, where people live in a rabbit warren of junk they claim they'll use one day.

Yawn.

Functional CSS reminds me of React and JSX - there are plenty of people who will argue at length what a bad idea it is, having not tried it.

I came across this when it was posted to HN a year or two ago and ended up finishing the whole thing. Thank you for making it.

Is that kind of comment necessary?

"I state upfront that I have zero React experience because 99.999999% of tech companies want someone with 18 years of experience with a four-year-old JavaScript framework. I'm being facetious here but that requirement is ridiculous for a fad. Writing CSS in JS? GROSS."

You don't have experience 99% of employers want, and your response is to stubbornly write it off as a fad? Maybe that's got something to do with it? If you have zero experience, how do you know it's gross?

The OP is talking about the way lowest paid employees are treated. Of course paying everyone 200k is ridiculous, but they didn't even come close to suggesting that should be the case.

After using tachyons (http://tachyons.io/) I've gone the complete opposite direction. While tachyons takes it to an extreme, I found having many small classes that (generally) do one thing, then composing those classes in the HTML, is much nicer than giving each element one "semantic" class name and hiding all the complexity in the CSS, with the large file size and many duplicate rules that approach brings.

You are then not scared of changing existing classes, as they are so simple. In fact you rarely have to change them after writing them the first time. Often you can build a whole new component without writing any new CSS.

It works especially well with components, as it's OK if the HTML is "noisy" with many class names, as generally you're not dealing with large chunks of HTML at once.

Yeah, that's what I meant - instead of taking the shortcut with a comment explaining it, just don't take it in the first place.

On top of that, he could have just written "currentChunk++;" and skipped the comment entirely.

He was fired.

The separation of concerns is an illusion anyway. See hacker_9's comment.

It's not proper research.

I live in the UK and know what the Guardian is. It is not a "hippy's" newspaper. Thanks for the condescending Wikipedia link though.

The Guardian isn't left wing. It's centrist.

How do you re-use CSS across components?

It was a very long depression.

That's the joke!

Sorry, I meant to respond to the other comment saying it was a dupe.

This is npm's blog, not the initial announcement.

EDIT: responded to the wrong comment, sorry.

I've thought about this - the existing method of designers coming up with a couple of static designs ("small" and "large" - "medium" if you're lucky) means the developer is burdened with interpreting these static designs and deriving a set of relationships and constraints between them. It seems obvious that the designer should be considering how the design responsively "breaths" at all sizes, rather than putting this on the developer. It's still design, just an added dimension that isn't present in print.

But how do you give the designer the opportunity to "sketch" but also describe relationships and constraints? You could use code, but then the designer is then also a de-facto developer. And having to consider relationships and constraints too much can lead to those considerations dictating the design, rather than the other way around.

I agree, UI development is a different beast.

He briefly mentions hot reloading and declarative UI at the start, but it's drowned out by his ranting on JS and doesn't seem to earn it any points in the end. But those two are huge boons for UI development, to the point where it's worth putting up with JS's flaws as a language. Flexbox and media queries make CSS pretty decent for layouts. Dynamic languages are a double-edged sword - for UI you often want something up and running and useable to see if it actually feels right, without worrying about interfaces and types too much. Objective-C and Java can feel clunky in comparison.

But you're clicking on a link, not downloading and installing an application.

I was just reading a blog post where a guy had written about Steve Reich and Brian Eno's experiments and his attempts at replicating them. It was posted on HN a few days ago: http://teropa.info/blog/2016/07/28/javascript-systems-music....

There are embedded YouTube videos, MP3s, and code samples to illustrate what he's writing about. He's implemented their ideas using the Web Audio API and you can run the code from within the page and listen to the music being generated in real-time. It's a real testament to how great the web can be.

I think being able to do things like that is worth all the annoying parts of the modern web, in the end. For the developer and the end user. I wouldn't want to go back to the old way. I think it's easy to focus on the annoying parts and take the good parts for granted.

And you can write a simple and clean TODO app in any framework. You really need to see how it manages complexity to evaluate it properly.

It's under 40kb gzipped. If that's a sizeable percentage of your total JS code, you probably didn't need React in the first place.

It's not a fair comparison. React is just a view layer. It's not trying to offer everything that you'd need to write a web application.

React has become synonymous in some people's minds with "React + a bunch of other stuff", but this wasn't intentional. It's an unfortunate side effect of its popularity.

You don't "almost certainly" need Flux at all.

By coincidence Dan Abramov just posted this: https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

People who aren't doing complex things start using libraries that are designed to manage complex things, even though they don't need them, then complain that they're overcomplicated. Repeat ad nauseam.