> See, I know that shipping end-user software - like the Tailwind compiler - if that software is written in an interpreted language - is fucking hard.<p>This I don't get. This is interpreted code, most web backends integrate node, why not just ship a node module? Why in gods name ship bun.<p>The whole web development scene has had some of the worst software engineering I've ever seen. With the exception of the Ruby scene, we have Tilt and Nokogiri for these types of things.
I was hesitant to give tailwind a try, like most aging web developers I couldn't stand that it breaks the "cascading" part of CSS.<p>But eventually I didn't have choice as I inherited a web app that has all of the newfangled build components that web apps come with. I love that we're coming full circle back to MVC with server components.<p>After getting used to it, I ended up liking Tailwind, mostly because it breaks the cascading part of CSS. There are so many unique parts to webpages these days that I think it makes sense to keep the styles close to their components, as opposed to global cascading components.
I've got a number of vanilla JS, HTML, CSS libraries that work only from within the browser, using the standard tags to include them.<p>For me, not having a build-step means that, yes, I miss out on typescript, but the upsides are easier to read, easier debugging and lower cognitive burden during both writing and reading the application.<p>It means I will never, like the author in the article, spend $X weeks, and then spend a further $Y dollars just to build something "modern".<p>My "modern looking" applications are developed, and then tested, on a machine from 2010 (1st-gen i7) that has 16GB of RAM and oodles of slow spinning-rust disks, and it isn't painful at all.[1]<p>[1] It is, in fact, quite nice when I see a client use their system from their own PC and it's just a little bit snappier than I am used to.
I have genuinely never understood Tailwind's value proposition, other than as padding for its developers' CVs, at which I assume it excels.<p>We stopped inlining style attributes for a reason - is this just how the next generation needs to learn?
I try to stay away as much as I can from front-end, because modern front-end is a shit show.<p>Unless I do the front-end for my own app and then, the order of preference is server rendered HTML, HTMX, Web Components, Vanilla JS. Stuff I am sure I can maintain with ease 100 years from now. For CSS I would use something simple such as bootstrap.<p>I kind of agree with the author of using tools you know are reliable as opposed to chasing fads. Of course you must and should learn and use new things, but proceed with care and carefully consider both upside and downsides.
I generally have nothing to do with webdev, but my general expectation was always "okay, it's a mess now, and everything is terrible, but everything will settle down eventually". Instead, every time I hear about it, it has somehow gotten worse.
I find the discussion here somewhat amusing, because I am on another level of disbelief when looking at the state of things in the npm world.<p>Most people ask "why ship bun (whatever that is), why not just be an npm module".<p>I am baffled as to why we have forgotten the lost art of spitting out something from a build and then using that thing. As in, "make" producing a CSS file. Or a JavaScript file. Or multiple files. Why does npmness have to force itself into every nook and cranny of our software and consume it all?<p>In my webapp I use several small CSS and JavaScript libraries, and for building those I use docker containers. The npm horrors live in the docker containers, I try not to look in there, but whatever happens there, a bunch of css and js files come out. Reproducibly. Reliably. And things don't break if there is a headwind or a tailwind (ahem) today on the internet.
I like this post and agree with a lot of what it says. Shipping Bun at this stage is probably not a great idea, particularly with overly-optimistic CPU requirements, and the complexity of the stack is very far from ideal. At the same time some of that criticism seems slightly mistargeted. Bun didn't drop support for your hardware arbitrarily: your OS vendor dropped support for your hardware. Your "computer with 128GB of RAM and 6 CPU cores" is obsolete according to the manufacturer.<p>This is bad, and it should not be an acceptable situation, but a relatively short support cycle is a choice you made by buying their product. I'm not sure it's right to then blame others for following along.
Front end is definitely pretty hard nowadays. It seems like the technology should be easy but keep in mind you’re getting everything for free and this isn’t the field you have a ton of practice in. It’s grown a lot while also being backwards compatible with browsers which are some of the more complicated pieces of software.<p>Trust me, I get very confused and frustrated whenever I have to figure out python deps or kubernetes, but I accept it’s going to be difficult since I’m not familiar with the field.
I was a web developer from 1996 until 2023. I jumped ship because of exactly this sort of nonsense. I still do private web development, but I do it all using native vanilla HTML, JS, and CSS. It just works.
I feel for the author, and influencers have a lot to answer for. Through a lot of this article I was thinking about next.js, another tech you almost have to know to get hired these days, and how much I dislike it for a myriad of reasons, and despite my dislike, Vercel just absolutely dominates at marketing and devrel so here we are, with every startup and even bigger companies using it.<p>Unfortunately that's the world we live in now.
reading that really makes me wish there were a compiled-to-static-binary language with a reasonably easy migration path from javascript (sort of like ruby->crystal, where the latter tries hard to look like ruby so that at least some fraction of your code translates mechanically). there really is no reason that a tool like tailwind should be this hard to ship in a robust and compact binary.
TLDR; lots of software now relies on AVX2 instructions which aren't present in older x86 hardware. This prevented author from running some web development stuff.<p>Recompiling the (open source) code should have offered a solution but OP could not make this work.<p>On some platforms you can emulate the missing AVX2 instructions with intel SDE but not apple.