Only $4.85 per month (non commercial; otherwise contact us for enterprise pricing) if you want to keep it working. Very reasonable. Bulk discounts for multiple fonts. Sign up today.
In fact, they just released a video a month ago detailing some of the areas they're working on, including dart macros, their new impeller engine, performance updates for the web platform, and more.
Hmm. I recalled a story from 2 or 3 months ago about them having laid off the Flutter and Dart team. Looking at it more closely it looks like the story was actually just that they had laid off some staff from that team.
I spent the last week learning and then writing technical docs on tailwind for my org. I was skeptical of it at first, now I have an informed dislike of it.
I often interact with people who don't like something but haven't used it before, so I'm definitely going to steal your term "informed dislike" to distinguish between those cases and ones that are legit gripes.
Any field in a DB can be vulnerable to SQL injection. Filtering out characters is a terrible way to mitigate that attack, you should be using prepared queries where it does not matter what chars you have in your username or password. You should never form a query with string concatenation.
You may want to limit chars in a username to ones allowed in URLs (or even ones that don't need escaping) if you ever want it to appear in a URL though. Or any other places the user name might be used, but a entry in a DB should not matter.
There are a lot of edge case characters around visually indistinguishable names. If that is a concern usernames should use a restricted known character sets instead of trying to block specific characters. You likely should also treat lookalike characters as equivalents when checking for username overlap.
This person thinks Tailwind is just a grift to make money, prioritizes separations of concerns over all else (I contend they have SoC brain-worms, but I don’t want to get too spicy), and ignores all the actual arguments people use for Tailwind, like how it’s specifically built to suit component frameworks over someone raw-dogging that HTML and CSS. Their argument boils down to “get good” which is the argument that folks use when they’ve never been on a team and have never had to make actual trade-offs.
Their arguments included the size of the web page, and the time to display the first content, both of which were significantly better in Nue when compared to Tailwind.
By all means argue on what is important (because what is important for your projects may be significantly different from mine), but there were many points that the author was highlighting, not just the separation of concerns. And for my projects, all these concerns are important.
They’re valid concerns, for sure. I have less issue with this article in particular than I do with some of the other things he’s written. In the context of his other opinions, I feel pretty dismissive of whatever arguments he presents, valid or not. He’s extremely biased and I think folks have to take everything he says with a grain of salt.
There's absolutely a massive internal bias people have where they naturally believe that others develop the same kinds of content, when really it's half working on page based content, and half working on component based content.
Page developers know that putting their styles in the content itself is a disaster when you want to make a global change.
Component developers know that putting their styles external to their components is a dx nightmare because developers keep making changes that they think only affects one component when it actually impacts a different component (and that change might not be found until months or years later).
Both are correct.
The real problem is developers thinking that there are only two methods for making styles: external css files, and tailwind/atomic styles in class names.
Component developers should have their styles inside their components, but not inlined in style attributes (like in tailwind).
Component developers should instead place a style tag inside their component that is scoped to just that component.
So let's say you're making an accordion component.
Make your html+js/jsx like you already do, and add an "accordion" class to your component's root element. Now add a style tag in your component with a single selector targetting the .accordion class. Now you can use nesting to style anything in the accordion exactly how you want. Want to style something based on whether an element is open or not? Use an attribute selector. Want to style something based on whether it's child is doing something? Use the :has() selector. etc...
If you're making a widget system, use container queries. If you're making a card system, use subgrid.
There's so many obvious use cases that modern css provides for, so use modern css! and not any of this BEM or tailwind nonsense. Now your css is so much smaller, robust and more maintainable.
Follow up questions:
Q: But I don't know modern CSS
A: Learn, it'll be much better for you in the long run compared to using tailwind, then needing to learn something else once people switch off tailwind for something else.
Q: But wouldn't putting a style tag in every component mean that there's going to be two style tags on the page if I put two of the same component on the page?
A: It'll only do that if you make it do that. Most component based frameworks are already set up to reduce repetition, check your framework's docs. (e.g. react's many css-in-js solutions, web component's :host selector, vue's <style> and <style scoped> elements, SSGs like Eleventy have Asset Bucketing, and even native html is getting it's own solution this year with @scope).
Tailwind feels like CSS i have to re-learn. It's maybe slightly easier? mostly it just makes my html unreadable to the point i barely know what's going in anymore.
I don't do much frontend stuff but i'm gonna go back to plain old CSS for my next project.
It all sounds good in theory, but in practice, tailwind has been more work rather than less.
I feel like i put a fair amount of time in understanding how everything works too.
It just really feels like one of those things that makes little difference but i wasted way roo much time on trying to give it it's fair chance.
I've seen people advocate for Tailwind because "CSS is too hard, I don't want to think about selectors".
CSS isn't too hard, there are easy ways to do things, and hard ways to do things (for backwards compatibility reasons). If you don't learn modern CSS then you're only going to be doing things the hard way.
That's how i got sold on it too. My CSS skills aren't great, tailwind made it just slightly harder to deal with CSS i feel.
Seems healthier to learn actual CSS instead of abstracting it away if the benefit is that low in the best of cases.
Sure, large projects are a thing, but nobody puts a whole project in 1 css file anymore anyway, so what does it matter at that point.
I've seen people advocate for Tailwind because "CSS is too hard, I don't want to think about selectors".
Yep, those people are wrong :)
(I mean sure, you can sort-of mostly skip selectors if you use Tailwind, but selectors are about the easiest part of CSS. I've never heard of someone struggling specifically with those but not with e.g. layouts, stacking context, relative font sizes, etc.)
I think most of the arguments here are kinda ridiculous and poorly thought out. A lot of them also sound pretty imaginary and made-up. For example:
To assert that frontend languages are not programming languages is to assert that what one is doing when writing them is not programming, but something else. Something different.
Something—perhaps not explicitly spoken, but undeniably implied—lesser.
Basically, he's arguing that everyone who thinks HTML/CSS isn't a programming language is wrong, and then the only reason they feel this way is because of a prejudice against front-end developers. I think this is really just a wild leap in logical reasoning, personally.
(No mention of Javascript/Typescript here by the way.)
If you wanted to find the dev specialization with the most people who aren’t cishet white males, you’d pick frontend.
Do we honestly believe the language around frontend is different purely by mere coincidence?
... yes? His argument that HTML/CSS should be considered programming languages is honestly quite weak. Couldn't that be the reason instead?
Certain pursuits are validated with importance, dignity, and honor.
... we relegate others to the role of the sidekick - even though their labor is no less important, and they do at least as much to push the work toward success.
Who the hell is making these groupings?? Front-end developers compared to nurses? Software engineers to doctors? And software engineers being held in the same light as CEOs... wtf???!?!?
(Surely it’s a coincidence the first group tends to be more male than the second.)
Once again, he's attributing his feelings with prejudice when really, I think his arguments are just very poorly thought out.
Other forms of development are generally considered serious work. They’re important. They’re real computer science. (Computer science itself being a higher level of things we’ve decided are real, serious, and important—maybe not quite as much as medicine or law, but then again, maybe so in some circles.)
Again, I don't see anyone arguing or claiming this. I'm sure the author would argue that just because we don't say it aloud, but it's just implied, but I honestly just think no one says it because it's just silly.
Writing CSS seems to be regarded much like taking notes in a meeting, complete with the implicit sexism and devaluation of the note taker’s importance in the room.
Though critical to the project, frontend work will quite often be disregarded by those who consider it beneath them (usually men, and usually only tacitly, never explicitly). It’s not serious enough; not important enough; not real enough. Too squishy. Like soft skills.
Once again, just unfounded accusations of bias. "You didn't say it, but I'm telling you that you said it anyway."
Their [software engineers'] output is easily measurable. A new API feature; a more efficient database; crises averted and crashes prevented. They go on charts and get presented to board members.
Board members couldn't give less of a shit regarding what software engineers do. We're considered a cost that they'd love to get rid of as much as any other position. Look at all the AI hysteria going on right now, like Nvidia's CEO telling people not to go into software because it won't exist anymore. Again, I have no clue where this guy is getting his ideas from.
If our job title does include the word “engineer,” it will almost certainly specify what we’re engineering. It’ll be UI engineer, or frontend engineer, or maybe the newer (and arguably more fitting) design engineer.
But it’s probably not “software developer” or “software engineer” without any other qualification. Because that, tacitly, is not what we do.
Completely disagree. Front-end development is a subset of software engineering. He even admits this as much:
Sure, this is nuance of language and these titles serve to disambiguate. I get that.
but then he goes on to dismiss that by saying "that's not really it though, it's really because we're not considered real engineers":
by definition, somehow what we do isn’t seen as software engineering. It’s different than that. It’s softer than that.
By what definition exactly? He just explained the reason for the difference in terms above, but then goes on to say that's not really it - the real reason for everything bad is (what he perceives as) negative bias.
There's a couple interesting ideas in here. He makes a good point that layoffs on the front-end are more likely to hit underrepresented classes, though there's not much that can be done about that. Layoffs are happening everywhere, and DEI is probably not what's on CEOs' minds when they make those decisions. And sure, there are unrealistic expectations at times, but that happens everywhere, not just in the software industry, but in pretty much any labor scenario.
But overall, I think this guy has major issues with his self-perception. Pretty much all of his arguments are predicated on very poorly thought-out or straight up imaginary ideas. And blaming everything that's wrong with his perception of front-end development on the white male hierarchy is just... I can barely even find words for it... nonplussing? I think he figured it out by the end of the article:
Maybe I’m feeling sorry for myself. Maybe I’m just a little depressed right now. Maybe I have an inferiority complex and I’m projecting it on everyone else.
I'm pretty sure it's all of those.
I wish this guy the best. Shit is hard right now. But I'd be a fool to say that I agreed with more than 10% of what he's trying to argue.
I wholeheartedly agree: the article is just plain stupid.
What I find more amusing is that front-end work ends up being the most critical work in any user-facing application. Apps can still lumber around if big chunks of backing services are down, but if a page is rendered poorly or a button is showing up weird, or if text is missing in a place everyone looks at, that's automatically a SEV1 right there.
I really dislike having to watch an entire video to catch the one bit of useful information. I wish I had the time to watch entire videos, but honestly, I don't. On top of that, my brain has often wandered off well before I get to the interesting bit.
Oh wow, I didn't know this existed. A little bit thin on the information, but better than nothing. I also want to look at the new capabilities of the Gemini model to help me create blog posts from my videos.
Kind of horrible timing, as Apple will disable PWAs in the next iOS update for the EU. Kind of crazy, but I guess they will get punished for this behavior. So let's hope this will be reverted soon...
And if you're European, participate in the elections in June to get more parties into the EU bodies that will take legislative action against companies like Apple. The EU is the reason Apple is even attempting this silliness because Apple was designated a gatekeeper in the Digital Markets Act: one of the great EU acts for consumers.
A big group of Apple fanbase are not ignorant, rather willing accomplices. Just look at the downvotes here. They will do anything to defend Apple's rogue behavior - like resorting to whataboutery, blaming the EU or even claiming that PWAs are bad.
My theory is that by defending Apple, they're trying to make themselves feel important with their overpriced products.
With Shopify you can't run anything locally, it's all in their cloud. So you're constantly typing CSS into a textbox in a web site. Also pretty much every Shopify plugin ("app") costs $5 or $10 per month which adds up fast. Wordpress plugins are pretty money hungry too but it's much worse on Shopify.
It's ok if you're just making small tweaks to a theme that is already 80% of what you need.
I don’t have a favorite one and I love decentralized tech so I forked Lemmy to try and repurpose it for that. Honestky, I would have done it in Haskell or Purescript had the Lemmy devs not gotten as far as they have been with Rust.
It probably can’t have 1:1 feature parity with Shopify (actual commerce being handled on pub/sub would be a nightmare) but I at least intend to broadcast inventory changes using (a variant of) the pub/sub protocol. Instances will theoretically be run by vendors (or alliances of vendors).
I’m at the VERY early stages. I’m currently trying to build Lemmy using nix to declaratively glue together the patchwork they use to build it. I figure having it continuously roll with the original would be helpful for this rapidly evolving pub/sub world.
2 years into web dev (with 20 years of other software dev experience) and I’m rolling my eyes with all this. OK, sure. And I’m exhausted in myself at reaching for frameworks (I’m working on being better) but the fetish around avoiding JavaScript is silly. CSS is amazing, learning how to use selectors better is definitely on my list, but that is not an interview question of any substance.
I agree - it's like a fun code-golf challenge in that you end up with awful, write-only code but you may well end up with a deeper understanding after solving it. It's for circumstances almost opposite to an interview.
The proposed solutions don't even work - for example the tan is only meant to display once per letter.
The actual question does at least ask when it's JS suitable and when isn't it - for example it's irritating to have to wait for a page to init just to be able to access a drop-down menu (hint: use active in CSS instead of a JS toggle).
I'm glad we can use logical properties now. Dealing with systems that support both LTR (like English) and RTL (like Hebrew and Arabic) languages used to be a pain because we had to have a build script that generated a second CSS bundle with everything flipped (eg converts margin-left to margin-right, border-left to border-right, etc. Logical properties make it a lot easier.
I love the gap property for flexbox... I use that one all the time. Easily solves the "I need padding between all these items, but no padding at the start or end" use case.
Web Development
Top