JLehtinen

I find it a little bit backwards that semantic CSS class names should be invented by the developers. If there's a working and well-organised design system in place, then there should be little need to come up with arbitrary names for things. At the very least the designer(s) should be consulted, because they have experience and insight into which elements have common styling with each other and how they are placed in context. In general, I think Tailwind's popularity has a lot to do with developers typically not being designers.

Several reasons to use "primary" class for buttons – `button` is just one of the elements that gets used with button styling, but there might also be `a`, `div` or `input` tags that look like buttons, depending on the use (or source).

They are (encapsulated in reusable components). But when the project grows big, Tailwind's shortcomings become apparent, the biggest ones being the loss of context (cascading) – and of course the lack of separation of concerns, when the concerned parties are also separate (developers and designers).

When building a design system, there are a bunch of default styles, and then there are variations based on context. To put it in a real world example, imagine a newspaper heading style that varies depending on where the heading appears. Front page headings are bigger, sports pages might use a different style, and so on. Same with buttons, cards, tabs, what have you.

This isn't impossible to build with Tailwind by adding, say, react logic, but it becomes a mess quickly. If you have a well-built design system, class naming shouldn't be that hard to figure out and communicate to developers. But deciding on a coding logic to account for these context changes and sticking to it seems not as easy, especially when developers come and go.

I’ve worked on some large projects including refactors with Tailwind and my view is opposite. I can see how Tailwind would work on small projects, or ones where the designer never touches the styling inside the code. But on the other hand, avoiding naming because it’s hard isn’t how I approach organising design, and it doesn’t sound like a good approach to coding either. But I can see how there may be a need to bypass it in projects where there is no designer, or a design system.

Being a designer who does his work inside code, Tailwind is a nightmare. I hand off my design files, the developers do their thing. But then, maybe I want to tweak things after a review, or the design system changes, so I have to do a sweeping change to those buttons. Now I need to touch dozens of jsx/tsx files around the platform and make humongous pull requests, and the result is often dozens of merge conflicts. If I only touched CSS/SASS files, there might not even always be a need to have the files reviewed.

Another problem is readability. When things aren’t getting named, the files are often unreadable at first glance. And that’s what they are to external services like Pendo, which rely on classes to tie their thing into the UI. Which are now susceptible to change on a very regular basis, because when you change Tailwind styles “that only changes that particular instance”, or so the story goes.

Agreed 100%. However, the previous all-male panel of government party leaders was also thankfully noted in the media.

I've seen a sneak peek before and learned that things evolve pretty quickly at this point :) Cannot wait to see where all this goes, congratz on the release!

We find the Free version extremely good value considering it offers unlimited users/traffic/data.

We're Finns afterall. https://www.youtube.com/watch?v=DvidoBBJSRA

Well Tero's fiercest opinions typically take the form of code :)

Riot 2.0 was completed and submitted yesterday after lunch (Finland time), blog post was completed today at the same hour. We genuinely felt they were worth telling the world about and people seem to agree.

This blog entry offers more detail on the Redis setup: https://muut.com/blog/technology/redis-as-primary-datastore-...

Yes, embedding is done by inserting a couple of lines of html, and styling to make Muut look like the rest of your site is easy with the included CSS designer tool. You can also write CSS by hand if you wish.

Check https://moot.it/upgrade — we currently offer 2 paid upgrades, Branding and SSO. — Janne/Moot

Thanks! They were drawn in Adobe Illustrator.

> There's almost literally nothing here

True. There's 0.85kb + license.

Reasons for why Moot is a hosted solution: https://moot.it/docs/technology.html#distributed-service

Yeah, yeah, I know: I'm just a graphic designer without a deep knowledge of the technology... But what happens in the diagram is still pretty close to what you describe, to be fair: messages duped and delivered simultaneously. Absolute accuracy would have made for a pretty complex illustration. Point taken anyway, I'll try harder next time!

Btw, did you notice it has blue heads? I thought those were cool.

I'm also not a big fan of his use of hyphens '-' for dashes '—', since we're so passionate about typography.

I don't even know where to start with this post.

Arial has its flaws (what font doesn't?), but to call it "a bad copy of Helvetica" is just plain wrong. If Arial is a copy of Helvetica, then Helvetica is a copy of Akzidenz Grotesk, and so on.

Traditional web fonts had their place and might still be a valid choice for some sites, but with higher resolution screens becoming more and more commonplace solely recommending "web fonts" no longer makes sense. If anything, Verdana and Georgia look clunky on retina screens (like they do in print), whereas classic fonts aimed for print have regained their subtle shapes and now look elegant on screens.

Yes, Lucida has a larger x-height and thus looks 'more readable' to a lot of people — but only at the same pt size. I'm so used to Helvetica's word shapes and tight letterspacing, though, that I'll have to disagree on that as well.

You could say that, but Nokia had very similar designs (albeit with a couple more buttons at the bottom and a hidden keyboard) before iPhone. When iPhone4 came out I remember thinking how familiar some of the details looked.

Oh yeah, for iPad apps it's certainly different. App store for iPhone is far too cramped for that.

I'd add screenshot collages to the list of things to avoid. Instead of showing just one, informative screenshot at a time, some developers stick 4 screenshots into one, making all of them too small to be legible or comprehensible.

Guitar players who can also play drums are at a big advantage, just like composers who can write lyrics or sing. Graphic designers are often illustrators too, but copywriting, photo retouching and photography skills can also be very useful for a designer — and not every designer necessarily has them.

From what I've seen as a designer, development is highly opinion oriented. There are dozens, likely hundreds of choices you can make regarding languages, server strategies, 3rd party services, modularity etc. There is a reason why a part of the development process is actually called "design".

Likewise, there are a lot of rules that apply to design. It's not simply about what something looks like — it's just as much about whether "it works" or not. If users can't find your "sign up" button, then no amount of engineering and optimizing the way it works will make click rates better.

Developers and designers both have to think about usability, and there are numerous overlapping technical and aesthetic considerations for both to arrive at the final product.

You end up lost when you see there's a new reply on a thread you've been following (post count is 67 but yesterday it was 66) and then you go trying to find it for about five minutes. You end up re-reading about 30% of all the posts until you finally find what you were looking for. Repeat until you've read the entire thread 20 times.

But that's not a bad experience compared to when you go read a threaded conversation for the first time when there's over 50 posts — the whole thing is just unreadable. Add to this that even the most technical people can rarely reply to the right post 100% of the time.

This is true of any service anywhere, even regardless of whether the company makes money or not. Btw, any ideas of a good replacement for Google Reader?

Moot architecture is a distributed cloud based service - unless someone wants to set up the dozen or so servers it would require for a basic Moot setup, it wouldn't be feasible even if the infrastructure setup was open sourced.

A couple of days back that was just a page with a story, now there's two, so I guess an RSS is now a must. Coming soon...

And of course Moot also offers forums, which Disqus does not.

The concept of internet forums has mostly been gathering dust for the past ten years while the ways people discuss over the internet have changed profoundly, so some re-imagining is definitely in order.