The5thElephant

> Why do people keep mentioning Tailwind and CSS-in-JS in the same sentence?

Because one of the biggest arguments for each is scoping styles to a component instead of the default global cascade.

> And no, Tailwind would still have its place even if Svelte appeared first because instead of writing the same styles everywhere you'd still want to extract them into a file, and have sensible defaults for them.

Writing same styles everywhere? I'm not sure I understand what you mean, that isn't related to Tailwind or frameworks. Sensible defaults are just design system tokens, those are usable in way more styling approaches than just Tailwind.

I'm not saying Tailwind wouldn't exist, I'm saying it wouldn't be as wildly popular as it is now. React's lack of CSS features has encouraged a generation of frontend devs to simply not learn CSS fully. Sure you need to know some CSS to use Tailwind, but in many cases people just copy-paste Tailwind templates from elsewhere (another benefit of Tailwind) and don't actually understand the styling. I see Tailwind classes that do nothing in the wild all the time.

Of course it's just class names, what I mean is that if fewer people used React and more used Svelte/Vue they would feel less need for things like Tailwind or CSS-in-JS.

My argument is that React is actively bad for writing HTML/CSS, and therefore people came up with clunky solutions to get around those limitations. Certainly Tailwind is more than just a solution for React, but a large part of its popularity is due to it.

This is achievable in a much nicer way with SFC frameworks like Vue and Svelte where you also get scoped styles and other benefits. One of the reasons Tailwind is so popular is that so few developers know anything other than React.

Exactly. Tailwind and CSS-in-JS are both a reaction to the limitations of React JSX and how poorly it treats HTML and CSS.

If Vue/Svelte had gotten the popularity React has you would see a lot more people realizing that SFCs and scoped style blocks solve most of the problems people poorly solved with CSS-in-JS.

Tailwind has some other benefits to it like good token setup and ability to copy paste from project to project and have it just work, but the mess it makes of your templates and the difficulty of then editing it down the line doesn't make those benefits worth it.

Vue handles it just fine with doing the hard work behind the scenes and just passing you some CSS classes to connect your animations to (and there are JS events to use as well if you need a JS animation). Main difference is Svelte gets the benefit of being able to do some fancier stuff like items changing order or doing more than just entering/exiting. Vue has this as well, but not as easy to use.

That being said I overall prefer the Vue CSS approach to animation, it inspired my brother and I to make https://animxyz.com which has been my most successful side project yet. We wanted to make it work for Svelte as well but they don't have the CSS classes so we can't hook into their events the same.

I love Vue 3, but 99% of the reason I love it is the SFCs and not using JSX/TSX most of the time. Vue can't optimize render functions as well as it can optimize templates, and templates are significantly more approachable for people like me who come from the design/HTML/CSS world and want to contribute to the codebase (especially since most front-end devs coming from JS world suck at HMTL/CSS).

Is typing really the main issue there? Working in render functions and TSX is sooooo much more clunky for doing the same basic things, and you lose all the nice benefits of Vue's SFCs and things like built-in class array logic.

I like Transit for their quick at a glance public transit arrival times in NYC, but generally prefer Citymapper's overall step-by-step directions and multi-modal transit options. That being said Citymapper did put a bunch of things behind a paywall in the last few years that have made it less useful outside of pure public-transit directions.

This would be way easier if everyone didn't default to using React or even worse React-Native-Web. Not only do you have to deal with handling CSS recalcs (not so bad on its own), you also have to deal with React rerendering the entire DOM when you don't want it to and then the layers of div-soup and absurd style abstractions React-Native-Web uses.

Tauri + Vue/Svelte/Solid/Etc seems like a great way to build a decent desktop and web app, but you just don't have teams picking anything but React React React React.

You might be interested in what they are building at http://felt.com/ they have a lot of great data sets already built in and it can handle imports of all kinds of mapping data. Not for actually updating the core data of maps, but seems like the tool to address the UX of mapping multiple types of data and presenting or exploring it.

I know for a fact a lot of the people participating in these communities were fully adults, and the age of the people being racist does little to mitigate the impact it has on the people on the receiving end of it.

I find it really bizarre how many people here are insistent on diminishing or excusing the experience the original commenter had.

How is that relevant? Yes communities tend to be prejudiced against things outside their assumed norm and the anonymity of the web makes it easy for them to express it without repercussion. That doesn't make the negative impact it had on people in those communities not real.

Furthermore in regards to race specifically I would argue there probably were very few online tech/engineer communities anywhere in the world that widely targeted and denigrated white people until maybe just recently, and even then they are likely not popular or widely participated in.

I'm struggling to understand what the point you and other commenters here are trying to make responding to the original comment.

But it is unclear what you are disagreeing with. They never said that there was nothing positive in those communities. So what is the point of your comment? To make sure no one leaves this thread thinking that those communities were a net negative or something? I understand the desire to defend something you were a part of and got something positive out of, but the original commenter isn't criticizing people for enjoying or benefiting from those communities, they are pointing out that they had a clear negative impact on people who were targeted by those types of awful comments.

The point isn't to figure out whether these communities were a net positive or negative. I wasn't a target of any of the racism, sexism, homophobia, etc on these forums and chat rooms but I sure saw a lot of it everywhere I participated at a level that was kind of ridiculous in some cases. It clearly had impact on the people it was targeting, the degree to which it "clouds a persons recollection" is entirely irrelevant.

Is your point that their recollection should be dismissed? That they were too sensitive? It's unclear what this response's intent is.

Sure, virulent about everything that differed from the "engineering norm". How often were comments made mocking, stereotyping, or denigrating whiteness and white people? I can tell you not nearly as many as were made punching down at everyone else, and not nearly as harsh or gross.

The argument isn't that there was no good to be had from those communities, it's that you can't dismiss or ignore the bad that they put out as well.

The difference between Vue/Svelte style scoped CSS and CSS modules isn't really that different in practice. When working with a larger team it is harder to enforce being careful with class name uniqueness, so the auto-scoping is beneficial but in a personal project I honestly don't mind turning off scoping entirely and just being strict about BEM class names. I LIKE the cascade part of CSS. So when working with a team Vue/Svelte-style scoping gives me the best of both worlds, global classes when I need them, scoped classes when I want to keep it component-specific.

The issue isn't that the companies/people I work with don't want to write JS, it's that they ONLY want to write JS. They don't hire the people that know HTML/CSS and accessibility better than their React devs so they don't even know what they are missing, they just think it is normal for implementation to be clunky, not match designs, and have poor performance. This is pretty much the standard at most early stage SAAS startups except the ones started by people who actually care about this stuff and understand it technically. At every company I have worked with (usually under 100 people) I as product designer have written more CSS than any front-end developer.

The point is to make codebases that are accessible to people who come from all sorts of backgrounds, not just JS developers. I have worked with designers who knew HTML/CSS well and they were so happy to be able to write simple template logic and plain old class names in Vue without having to figure out the correct JS syntax for modifying an array of style objects or writing a conditional and not leaving an accidental 0. Passing classes and props into child components and not having to explicitly tell it what to do with each one makes building JS components a LOT easier for people who aren't JS experts.

Discworld is a true joy, I miss Terry Pratchett! I read the books in publishing order, but I have had the urge to go back and read them as sets of related themes.

But it's a far worse developer experience, particularly for designers and HTML/CSS/A11y folks who aren't as JS focused. It's not like you really are getting that much benefit from writing CSS in JS besides familiarity with a language you prefer. It's harder to read and parse at a glance (even for the devs who wrote it, I see this in practice all the time when pairing and attempting to fix layout and style issues with my devs), harder to inspect from the browser, encourages practices that undermine many of the core benefits of CSS, etc.

My whole point is that we should not be finding worse workarounds just so we can stick with the familiarity of React. Even outside of HTML and styling it is easier to do stuff in other frameworks than it is in React. React is not providing some magical level of power other frameworks don't provide.

I don't hate React, I'm just sick of it being the defacto standard. We are creating a React monoculture in web dev and it absolutely has secondary impacts on how we write markup, styles, and how approachable and accessible our codebases are. So many major decisions being made just so a team can stick with React.

Why not pick a different framework and get better performance, easier to write JS logic, easier to write and read markup and styles, and a code that designers and others can engage with easily without having to be JS fluent?

> For me, the ideal abstraction here is CSS modules, where the class names are scoped, but the actual declarations behave like normal CSS.

How is this different from Vue or Svelte scoped style blocks? Those are just normal CSS with scoped class names.

> Different tools work for different people and in different contexts. You talk about the awfulness of CSS-in-JS, but last time I used it, I found it gave a really good balance between conventional CSS (albeit not in CSS format), while still being collocated with JS components.

People think too much about how these things work for themselves and their own skillsets, not whether it prevents other great people from contributing as easily. I know HTML/CSS developers who are way better than the average React dev at building great clean and accessible UIs, but they aren't as strong in JS and end up struggling with unnecessarily complicated JS solutions to things that don't need them.

Besides the colocation what other benefits did CSS-in-JS provide you besides the familiarity of JS logic? This feels like again a solution to solve a limitation of React, not actually the best solution.

> React has some of the most gorgeous style solutions around

Can you give an example?

> But idk what React codebases you've been in, the bog-standard, overwhelmingly popular bootstraps and guides since way before Svelte ever existed had some pretty nice style solutions and at the minimum importing CSS.

Vast majority use Styled Components or another flavor of CSS-in-JS that continues the problem of making it harder for HTML/CSS experts to contribute to a JS-only codebase. Tamagui is exactly the issue I'm talking about. It's great for JS/React first devs, but doesn't actually do that much that a good HTML/CSS developer couldn't do without all this added tooling and with much easier to read clean code for people unfamiliar with the framework.

> I think if you looked on average total CSS knowledge is higher than ever,

Definitely not my experience. There are some great CSS devs out there, but it is always secondary to the skillsets that are actually highly paid (JS, React) and they mostly end up in large companies by happenstance of those companies hiring more people. Smaller tech companies make the consistent mistake of not hiring front-of-the-front-end devs and end up with poor UI and experiences because of it.

Can you be more specific? What is easier to do with JSX+JS that is harder to do in Vue/Svelte context? Or another take on the question, will it be easier to read and understand for someone new to the codebase or JS development?

I love having HTML/CSS/JS in one place, it means things never get detached from their immediately relevant context. Also thanks to nice extensions for VSCode (which wouldn't work across separate files) I can option-click any class name and get a mini-panel to edit the styles inline without hunting for the style section or a separate style file. I can also see when styles I have added are not being used in that component.

When I demo side projects and my own work to my coworkers they are always surprised "I didn't know you could do that!" and the thing is they can't because they are all stuck using React.

How can you say there is no difference? What do you think Vue and Svelte SFCs are? Where does React have built-in component style scoping? Where does React have automatic passing of classes and properties to components? Can I write SCSS in a React JS file and have it just work? Nope.

The platform is more than just JS, and React has plenty of stuff going on that is "magic" enough to be no different for me than the abstraction of a DSL. How is the cost-benefit better for React when I keep seeing developers who actually try other frameworks have their minds blown at how much easier it is to do the same things?

The CSS skill loss is very real, particularly with the number of straight-to-React bootcamps that barely touch on it and the insistence on using CSS-in-JS which makes it way harder for people to explore a production website and learn the fun way. I'm not some HTML/CSS purist, and React was a big step forward for the industry, but now its time is past and we have way better alternatives.

There is no built-in support for writing your styles alongside your JSX the way Vue and Svelte have. Both provide automatic component style scoping, escape hatches, deep selectors, etc. Vue passes classes given to a component instance into the top level element of that component. All of this makes styling with plain CSS and SCSS 1000x easier than it is in React.

Then there is the template side of things where it is much easier to read a basic conditional or loop in Vue/Svelte for someone who doesn't know JS.

How much have you used Vue or Svelte? It is a significantly better developer experience for building HTML and styling it because it doesn't force everything to be written in JS. In React JS is the only first-class language. There is no built-in support for SFCs, style scoping, etc. Thus the awfulness of CSS-in-JS was born.

Regarding your second point, this is exactly why I like Vue and Svelte so much over React (which I am also quite familiar with). Coming from a design background and having learned HTML/CSS first, the Svelte and Vue approach to SFCs and templating makes it far easier to understand, write, and visually parse than React where everything is always JS first. I can't think of a situation where Svelte/Vue limited me from doing something you can do in React, and Svelte/Vue make getting into a codebase far more accessible for people with a wider range of skillsets.

The secondary effects of React's popularity have been a significant loss in emphasis on HTML and CSS skills over doing everything in JS which often results in div-soup that is less performant and less capable. HTML and CSS not being first class-citizens as they are in other frameworks means developers simply aren't encouraged to learn them nearly as well as they used to.

Front-end frameworks should not be just for front-end developers. They should be understandable and accessible to people who are not JS first and who come from backgrounds that are not purely engineering. In my experience it is much easier to teach someone familiar with design and HTML/CSS how to explore a Vue or Svelte codebase than a React one, and the JS devs I have worked with who fully learn these libraries have not complained about any limitations compared to React.

Spotify does work with Siri on iOS but does not work with Siri on Homepod/Homepod Mini. They complain in their Time to Play Fair website about Apple not giving them access to Homepod, but Apple provided them access over two years ago. Also since Homepod uses standard Siri support that Spotify already has in iOS, it's not like it would be significant engineering effort to get it to work, so this is purely Spotify trying to spite Apple. They don't even have AirPlay 2 support yet! Every other major music service supports AirPlay 2 and Homepod already for some time now.

Tailwind certainly has some advantages and nice features, but the length of the class string when you need something common but complex like a custom styled checkbox including focus states, various hovers, media-queries, etc gets absurd and far more difficult to read, debug, and update.

I think one of the primary reasons Tailwind is so popular is how poorly React deals with classes and styles. In other frameworks/libraries like Vue/Svelte CSS is treated as a first-class citizen with a lot of nice quality-of-life improvements that React teams are forced to implement using awful CSS-in-JS solutions or with Tailwind. You get single-file-components, scoped styles, etc, all out of the box and without having to learn a new abstraction.

If the dev world wasn't a React monoculture (and more devs appreciated CSS deeply) I think you would see significantly less interest in Tailwind.

The privacy argument doesn’t make sense to me. The addresses are already in Google Calendar. They don’t need to be saved into a different service to be viewed anonymously in Google Maps. You can already do it in Google Calendar for one event/address at a time.

Yes there are business/internal-politics reasons why some obvious features or experimentation doesn’t happen, but those aren’t necessarily good reasons beyond short term benefit to specific individuals at a company.

But I do think some of it can generally be blamed on large companies losing their ability to be nimble due to the inherent friction of the politics and logistics that build up as an organization grows.

It is absolutely bizarre to me how half-assed Google is with integrating its products.

I have a week of events coming up in Google Calendar each with a different event location. Why can't I see a map of all those event locations alongside the calendar with all the same event details listed? Why can't I associate a Google Calendar event with a specific album or set of photos in Google Photos and see those in the map and calendar as well?

This is why I'm building https://visible.page with my brother. We have all these capabilities of visualizing data on the web, yet no one has actually put them together in a convenient and consumer friendly way to visualize any type of information together in one place.

All these big tech companies seem to just give up on any kind of significant innovation as soon as they reach a certain level of monopoly on their market. Twitter, Spotify, Facebook, Google, etc. I can think of a dozen significant feature experiments they could try that would make my daily life better using those tools yet they don't.

> can you devise an experiment which will determine if a given entity is conscious?

No, without being able to define what consciousness is we can't make an experiment to test for it. The simplest explanation in my view is that qualia are a base "element" of the universe and information systems and our consciousness is a loosely drawn subset of qualia associated with our brain/body's information system. To be clear this is not dualism, the qualia are not some magical thing riding on top of physics and cannot change the path of particles from their physically determined routes.

Regarding quantum immortality I don't know if it necessarily demands a universe in which some form of every person lives forever by some unexpected chance of quantum improbability. At least in terms of a continuity of normal life it may be that the probability of a person living longer than a human body physically can is zero. However some have argued there is a non-zero chance that random quantum fluctuations could lead to brief instances of a person arising from "nothingness" anywhere and anytime in the universe, and some of those persons could by pure luck happen to match the mind of a person elsewhere. However this does start getting into the realm of silliness and quantum randomness and infinite universes allowing for literally every possible combination of particles.

Consciousness does influence the universe by being part of it. That's why we have the illusion of choice within the context of each moment rather than some meta-alien's perspective. But no it can't defeat determinism if that's what you meant.

I believe someone called that idea "quantum immortality" and I find it conceptually interesting if not somewhat terrifying. However it does seem like the inevitable conclusion of these ideas.

Consciousness is not a thing that gets bifurcated. It is just a word for an information state that is aware. If you create two information states, you have two awareness states. That is not bifurcation any more than copying a movie and editing one pixel on one frame (or as a better analogy having an effectively infinite number of frames with every possible pixel combination some of which describe aware states).

I don't see how that would allow or require seeing a cat in a complex linear superposition. You just have one set of frames which describe a live cat and another set of frames that describe a dead cat.