8 ms·

A Supermarket Bag and a Truckload of FOMO

116 points by julik 2y ago

throwanem 2y ago
I have genuinely never understood Tailwind's value proposition, other than as padding for its developers' CVs, at which I assume it excels. We stopped inlining style attributes for a reason - is this just how the next generation needs to learn?
- refulgentis 2y ago
  The comparison to inline styles is understandable but misses Tailwind's real value. Inline styles failed because they were arbitrary, inconsistent, and impossible to scale. Tailwind, by contrast, offers a constrained, standardized set of utilities that enforce consistency, simplify maintenance, and reduce CSS complexity. For example, instead of arbitrary inline styles like `style="padding:7px; margin-left:3px; font-size:14px;"`, Tailwind provides predictable classes like `p-2 ml-1 text-sm`, ensuring uniformity across your app.
  - timr 2y ago
    > Tailwind provides predictable classes like `p-2 ml-1 text-sm`, ensuring uniformity across your app. This is literally what bootstrap did/does. You could also trivially do this yourself with just a tiny bit of discipline -- it's part of why variables were valuable in SASS/SCSS. Why must we re-invent CSS to get semantic class names? Like the parent, I have yet to hear an explanation for Tailwind that doesn't sound like "someone who didn't fully understand CSS re-wrote it, and a generation of bootcamp coders adopted it without knowing why, or what came before."
    - throwanem 2y ago
      I didn't say word one about "bootcamp coders." That's all you, pal. Every generation has to invent sex and politics for itself, or at least imagine for a while in its 20s and 30s that it did. Why not the same in another preparadigmatic field like computing?
      - timr 2y ago
        Yeah, I know. That's all me. > Every generation has to invent sex and politics for itself, or at least imagine for a while in its 20s and 30s that it did. Why not the same in another preparadigmatic field like computing? Because it's not "preparadigmatic"? There was a perfectly good paradigm before it was tossed out and re-written in Javascript (and then again in some other language, apparently). There have certainly been some revolutionary paradigms in my career (e.g. the web itself), but this "reinvention" of basic front-end tech doesn't qualify. This stuff holds back the industry. It's part of why software engineers over the age of 30 are considered "old".
        throwanem 2y ago
        Yes, and it is also what doesn't really appear to happen in mature engineering fields, isn't it? No one is reinventing, I don't know, bolts. Or ohms, or amperes, or how one determines a Young's modulus. In those fields you see incremental refinements; mostly, when you see claims of major revolutions, like the recent flap over supposed high-temperature superconductivity in the "LK-99" material, mostly those receive deep suspicion that typically turns out to be justified, because these are fields where exist sizable, coherent bodies of well-tested and reliably predictive theory whose consequences can for most purposes be taken as known. If there is any similar body of knowledge in this engineering discipline then the discipline still qualifies as preparadigmatic for having developed a paradigm its exponents failed to become competent to transmit. But I think there simply exists next to none of such knowledge. (Even the damned alchemists have their ball-and-stick models! And sure, we have S-expressions, had them for something like seventy years, and do we use them? Do we, hell...) It's how you get people thinking that the web was revolutionary, and not a product of decades and generations of work toward the concept of a global communications network. But the idea that this inchoate condition holds back the industry doesn't seem to me to hold much water. The first boilers blew up a lot too, before the underlying principles were understood, and mere prolonged survival quickly came to be seen as no mean qualification in a steam engineer. How much did that "hold back" the building of railroads, from where the trains were to where the money was? That, if you care to know, is the overarching metaphor with which I like to describe this industry - though I concede the machines we build are not nearly so hazardous to we ourselves. If I had to boil down my entire analysis of this industry to something expressible in a single adjective, the only word to fit would certainly be "irresponsible." But I'll also mention at this time that I topped out at a high-school diploma on a sub-3.0 GPA, so if as the holder of a doctorate you find you begin to become bored or uncomfortable talking with me, experience strongly suggests the option of impugning any or all of my intellect, discipline, character, and decency of motivation in speaking is always available as a resort.
  - throwanem 2y ago
    Okay, that's reasonable, I see value there and have worked productively with similar systems in pure CSS and relatively lightweight Sass. The next thing I'd like to see addressed is why something so conceptually straightforward still needs so heavyweight a build step that it has to care what ISA it runs on. (Full disclosure, I haven't worked with Tailwind since 2020 or so. Though I was obviously not too favorably impressed by it, I don't recall it having problems like this then, which if anything I'd expect to have been exacerbated by the Apple CPU architecture transition then ongoing.)
Levitating 2y ago
> See, I know that shipping end-user software - like the Tailwind compiler - if that software is written in an interpreted language - is fucking hard. 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. 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.
- davedx 2y ago
  Speed, I guess? Although I use tailwind on all my projects and not once have I thought "oh boy, development is so slow because of tailwind, I sure wish it was implemented in a compiled language!"
  - julik 2y ago
    I think it's more like "having less moving parts". In which they kinda-sorta-succeeded, except that the choice of bun seems misguided for something where you want broad adoption. And Tailwind is, by now, a product that is clearly clamoring for broad adoption (and achieving it).
- whywhywhywhy 2y ago
  A lot of CSS tooling feels designed to overcomplicate it so it feels more like "engineering" rather than "markup". I find Tailwind particularly bizarre, essentially writing your CSS as inline styles via single use non-semantic classes is absurd to me. Wasn't CSS invented so we didn't have to write every html element "its blue, centered text and bold font" yet people willingly choose to use class="items-center font-bold text-blue-600" and running it through a compiler.
  - rsynnott 2y ago
    Huh. Yeah, I'd never heard of Tailwind before, but this looks suspiciously like how people formatted HTML _before_ CSS existed.
arealaccount 2y ago
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. 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. 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.
- mmcclure 2y ago
  Yeah, I've been a fairly vocal curmudgeon about Tailwind within my team. Some folks really like it. They're doing the work and I trust them, so I rolled with it. I still have qualms with Tailwind. My classic CSS sensibilities are offended, but whatever. The part that I still don't like is really what this post boils down to: a massively complex build system that creates footguns in the weirdest places. That being said, Tailwind that's set up well in coordination with a complex design system really does feel like it's a win. Seeing that in action was an aha moment where I was able to see value that made some of the tradeoffs worth it.
  - yurishimo 2y ago
    The other thing that people seem to just either forget or ignore is that you can do _both_ things! Tailwind can be used for the areas that it makes sense for, and you can write a sitewide layout using insane (in a good way!) grid declarations using plain old CSS and a few extra classes in your markup. If you're using Vue, you even get a <style> block that can be injected into any component so you're still working in the same context. It's all delightful and optional and you can still do whatever you want.
    - douglee650 2y ago
      Yes, exactly. You can use TW for the utility classes and copy-paste-and-go components, and append your own over/under/side-lay layers to create whatever css you want. What about a system that could take a really long TW className and let you give it a single name, and you could still append more TW after for here and there adjustments.
irrational 2y ago
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.
- wackget 2y ago
  What did you move into?
  - irrational 2y ago
    Other engineering work. Currently I'm doing integration work.
haburka 2y ago
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. 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.
- lelanthran 2y ago
  > 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. While keeping in mind that this isn't a field that I have a ton of practice in, I can confidently assert that a parser for HTML input that outputs CSS classnames does not need all of the following: 1. A recent Node (+ dependencies) 2. Pnpm 3. Rust (+ dependencies) 4. Bun build environment 5. A binary size of 100MB I'm pretty certain I needed an HTML parser at some point in the past, and it was built as a single standalone file, that compiled to a single standalone ~50Kb binary, that took a single day to write. Actually, here it is: https://gist.github.com/lelanthran/896a2d1e228d345ecea66a5b279aea24 https://gist.github.com/lelanthran/896a2d1e228d345ecea66a5b2... Now, fair enough, that doesn't spit out class names (because I didn't need it at the time, although looking at the query language it seems that it might be able to do that) that, but it's very easy to add a single flag for "spit out class names". The build dependencies are: 1. A C compiler. There's no makefile/build-script - simply doing `$CC program.c -o program` is sufficient. So, sure, while I don't have a ton of practice in this area, I have enough to know that the binary/program in question is heavily over-engineered. Their dependencies are artificial requirements (we require this because this other technology requires it), not functional requirements (we require this because this feature requires it).
  - unwind 2y ago
    Nice! Micro-fix: you should remove the final `;` in the `FPRINTF()` macro definition, that's supposed to be added at the callsite to keep the syntax natural (for C). :)
zem 2y ago
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.
- julik 2y ago
  That would be nice. There was also duktape, which was very compact and very embeddable - it could have been a decent carrier for Tailwind too.
- lelanthran 2y ago
  > reading that really makes me wish there were a compiled-to-static-binary language with a reasonably easy migration path from javascript I'm working on it ;-)
  - zem 2y ago
    do tell!
    - lelanthran 2y ago
      Still a work in progress, so not much to tell.
lelanthran 2y ago
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. 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. 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". 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] [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.
- julik 2y ago
  Absolutely with you on "no build". Sometimes it doesn't work (for me - where I need NPM modules with annoying math I don't want to do myself), but the basic premise of "nobuild" is absolutely and completely how it all should have always worked. It's the JSX+webpack perversion that ruined it for us all.
- pjmlp 2y ago
  Same approach over here for side projects, I only put up with "modern" Web development when ir isn't my choice. Classical ASP.NET, Spring with vanilla js.
davedx 2y ago
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. Unfortunately that's the world we live in now.
- julik 2y ago
  That one I try to avoid at all costs, but I hear what you are saying. The owner of the company selling Next.js and adjacent services is firmly in that list of influencers I have muted going forward.
fancyfredbot 2y ago
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. Recompiling the (open source) code should have offered a solution but OP could not make this work. On some platforms you can emulate the missing AVX2 instructions with intel SDE but not apple.
rsynnott 2y ago
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.
- DistractionRect 2y ago
  This would happen if browser technologies/standards would, you know, standardize. However, everyone and their uncle picks and chooses what they'll support, how they'll support it, and what extensions to the standard they want to champion for "standardization".
  - julik 2y ago
    I'd say these days the support is pretty decent across the board, if you can limit your app to a relatively modern set of evergreen browsers (or at least - to the versions from "2 years old or newer").
jwr 2y ago
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. Most people ask "why ship bun (whatever that is), why not just be an npm module". 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? 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.
- thi2 2y ago
  So instead of managing your versions in one package.json and installing your dependencies with one npm i command you manage several different docker container that produce builds you then consume? What kind of horrors did you encounter that led to this abstraction?
  - mbreese 2y ago
    I get this. I also do this (to some extent). Instead of installing whatever tooling I need for each project, I’ll store the tools in a Docker container. Then I don’t have to think about each project and how they interfere with each other. Even better, when something inevitably goes wrong, I can nuke the container from orbit and start over.
  - jwr 2y ago
    But in this case it is me who controls when anything gets updated. And I have all of my dependencies in the container. So I get reproducible builds. Also, dependencies of one package do not interfere with dependencies of another package.
- julik 2y ago
  The irony of my situation was that even using a Docker container would not help, because Docker does not emulate CPU instructions.
DeathArrow 2y ago
I try to stay away as much as I can from front-end, because modern front-end is a shit show. 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. 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.
jorams 2y ago
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. 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.
- julik 2y ago
  The vendor does not officially publish its dropped support. But from a brief piece of research I did, Jared dropped support for macOS 12 before Apple shipped the last update for it. And while on a formalistic, nitpicky level it is a "what are you complaining about with your old box" - in actuality I do find the idea to require a CPU upgrade to run a CSS pre-processor (a CSS pre-processor! come on! not an H265 encoder. Not some sophisticated animation system. Not an AI blob. A tokenizer for HTML...) absolutely, completely excessive. And I know why that decision came - it is because building portable binaries for the Mac is a pain in the butt. Well, guess what - if you made the call of shipping a multi-platform runtime - that backwards compat is part and parcel, Apple's LLVM versions, the linker and the dylibs and whatnot. So no, I understand that you are "right" formally, but the situation this brought me to - I still find bad, and the choices made by the chain of maintainers - I still find inconsiderate.

116 points by julik 2y ago

I have genuinely never understood Tailwind's value proposition, other than as padding for its developers' CVs, at which I assume it excels. We stopped inlining style attributes for a reason - is this just how the next generation needs to learn?

refulgentis 2y ago
The comparison to inline styles is understandable but misses Tailwind's real value. Inline styles failed because they were arbitrary, inconsistent, and impossible to scale. Tailwind, by contrast, offers a constrained, standardized set of utilities that enforce consistency, simplify maintenance, and reduce CSS complexity. For example, instead of arbitrary inline styles like `style="padding:7px; margin-left:3px; font-size:14px;"`, Tailwind provides predictable classes like `p-2 ml-1 text-sm`, ensuring uniformity across your app.
- timr 2y ago
  > Tailwind provides predictable classes like `p-2 ml-1 text-sm`, ensuring uniformity across your app. This is literally what bootstrap did/does. You could also trivially do this yourself with just a tiny bit of discipline -- it's part of why variables were valuable in SASS/SCSS. Why must we re-invent CSS to get semantic class names? Like the parent, I have yet to hear an explanation for Tailwind that doesn't sound like "someone who didn't fully understand CSS re-wrote it, and a generation of bootcamp coders adopted it without knowing why, or what came before."
  - throwanem 2y ago
    I didn't say word one about "bootcamp coders." That's all you, pal. Every generation has to invent sex and politics for itself, or at least imagine for a while in its 20s and 30s that it did. Why not the same in another preparadigmatic field like computing?
    - timr 2y ago
      Yeah, I know. That's all me. > Every generation has to invent sex and politics for itself, or at least imagine for a while in its 20s and 30s that it did. Why not the same in another preparadigmatic field like computing? Because it's not "preparadigmatic"? There was a perfectly good paradigm before it was tossed out and re-written in Javascript (and then again in some other language, apparently). There have certainly been some revolutionary paradigms in my career (e.g. the web itself), but this "reinvention" of basic front-end tech doesn't qualify. This stuff holds back the industry. It's part of why software engineers over the age of 30 are considered "old".
      - throwanem 2y ago
        Yes, and it is also what doesn't really appear to happen in mature engineering fields, isn't it? No one is reinventing, I don't know, bolts. Or ohms, or amperes, or how one determines a Young's modulus. In those fields you see incremental refinements; mostly, when you see claims of major revolutions, like the recent flap over supposed high-temperature superconductivity in the "LK-99" material, mostly those receive deep suspicion that typically turns out to be justified, because these are fields where exist sizable, coherent bodies of well-tested and reliably predictive theory whose consequences can for most purposes be taken as known. If there is any similar body of knowledge in this engineering discipline then the discipline still qualifies as preparadigmatic for having developed a paradigm its exponents failed to become competent to transmit. But I think there simply exists next to none of such knowledge. (Even the damned alchemists have their ball-and-stick models! And sure, we have S-expressions, had them for something like seventy years, and do we use them? Do we, hell...) It's how you get people thinking that the web was revolutionary, and not a product of decades and generations of work toward the concept of a global communications network. But the idea that this inchoate condition holds back the industry doesn't seem to me to hold much water. The first boilers blew up a lot too, before the underlying principles were understood, and mere prolonged survival quickly came to be seen as no mean qualification in a steam engineer. How much did that "hold back" the building of railroads, from where the trains were to where the money was? That, if you care to know, is the overarching metaphor with which I like to describe this industry - though I concede the machines we build are not nearly so hazardous to we ourselves. If I had to boil down my entire analysis of this industry to something expressible in a single adjective, the only word to fit would certainly be "irresponsible." But I'll also mention at this time that I topped out at a high-school diploma on a sub-3.0 GPA, so if as the holder of a doctorate you find you begin to become bored or uncomfortable talking with me, experience strongly suggests the option of impugning any or all of my intellect, discipline, character, and decency of motivation in speaking is always available as a resort.
- throwanem 2y ago
  Okay, that's reasonable, I see value there and have worked productively with similar systems in pure CSS and relatively lightweight Sass. The next thing I'd like to see addressed is why something so conceptually straightforward still needs so heavyweight a build step that it has to care what ISA it runs on. (Full disclosure, I haven't worked with Tailwind since 2020 or so. Though I was obviously not too favorably impressed by it, I don't recall it having problems like this then, which if anything I'd expect to have been exacerbated by the Apple CPU architecture transition then ongoing.)

Levitating 2y ago

> See, I know that shipping end-user software - like the Tailwind compiler - if that software is written in an interpreted language - is fucking hard. 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. 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.

davedx 2y ago
Speed, I guess? Although I use tailwind on all my projects and not once have I thought "oh boy, development is so slow because of tailwind, I sure wish it was implemented in a compiled language!"
- julik 2y ago
  I think it's more like "having less moving parts". In which they kinda-sorta-succeeded, except that the choice of bun seems misguided for something where you want broad adoption. And Tailwind is, by now, a product that is clearly clamoring for broad adoption (and achieving it).
whywhywhywhy 2y ago
A lot of CSS tooling feels designed to overcomplicate it so it feels more like "engineering" rather than "markup". I find Tailwind particularly bizarre, essentially writing your CSS as inline styles via single use non-semantic classes is absurd to me. Wasn't CSS invented so we didn't have to write every html element "its blue, centered text and bold font" yet people willingly choose to use class="items-center font-bold text-blue-600" and running it through a compiler.
- rsynnott 2y ago
  Huh. Yeah, I'd never heard of Tailwind before, but this looks suspiciously like how people formatted HTML _before_ CSS existed.

arealaccount 2y ago

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. 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. 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.

mmcclure 2y ago
Yeah, I've been a fairly vocal curmudgeon about Tailwind within my team. Some folks really like it. They're doing the work and I trust them, so I rolled with it. I still have qualms with Tailwind. My classic CSS sensibilities are offended, but whatever. The part that I still don't like is really what this post boils down to: a massively complex build system that creates footguns in the weirdest places. That being said, Tailwind that's set up well in coordination with a complex design system really does feel like it's a win. Seeing that in action was an aha moment where I was able to see value that made some of the tradeoffs worth it.
- yurishimo 2y ago
  The other thing that people seem to just either forget or ignore is that you can do _both_ things! Tailwind can be used for the areas that it makes sense for, and you can write a sitewide layout using insane (in a good way!) grid declarations using plain old CSS and a few extra classes in your markup. If you're using Vue, you even get a <style> block that can be injected into any component so you're still working in the same context. It's all delightful and optional and you can still do whatever you want.
  - douglee650 2y ago
    Yes, exactly. You can use TW for the utility classes and copy-paste-and-go components, and append your own over/under/side-lay layers to create whatever css you want. What about a system that could take a really long TW className and let you give it a single name, and you could still append more TW after for here and there adjustments.

irrational 2y ago

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.

wackget 2y ago
What did you move into?
- irrational 2y ago
  Other engineering work. Currently I'm doing integration work.

haburka 2y ago

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. 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.

lelanthran 2y ago
> 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. While keeping in mind that this isn't a field that I have a ton of practice in, I can confidently assert that a parser for HTML input that outputs CSS classnames does not need all of the following: 1. A recent Node (+ dependencies) 2. Pnpm 3. Rust (+ dependencies) 4. Bun build environment 5. A binary size of 100MB I'm pretty certain I needed an HTML parser at some point in the past, and it was built as a single standalone file, that compiled to a single standalone ~50Kb binary, that took a single day to write. Actually, here it is: https://gist.github.com/lelanthran/896a2d1e228d345ecea66a5b279aea24 https://gist.github.com/lelanthran/896a2d1e228d345ecea66a5b2... Now, fair enough, that doesn't spit out class names (because I didn't need it at the time, although looking at the query language it seems that it might be able to do that) that, but it's very easy to add a single flag for "spit out class names". The build dependencies are: 1. A C compiler. There's no makefile/build-script - simply doing `$CC program.c -o program` is sufficient. So, sure, while I don't have a ton of practice in this area, I have enough to know that the binary/program in question is heavily over-engineered. Their dependencies are artificial requirements (we require this because this other technology requires it), not functional requirements (we require this because this feature requires it).
- unwind 2y ago
  Nice! Micro-fix: you should remove the final `;` in the `FPRINTF()` macro definition, that's supposed to be added at the callsite to keep the syntax natural (for C). :)

zem 2y ago

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.

julik 2y ago
That would be nice. There was also duktape, which was very compact and very embeddable - it could have been a decent carrier for Tailwind too.
lelanthran 2y ago
> reading that really makes me wish there were a compiled-to-static-binary language with a reasonably easy migration path from javascript I'm working on it ;-)
- zem 2y ago
  do tell!
  - lelanthran 2y ago
    Still a work in progress, so not much to tell.

lelanthran 2y ago

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. 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. 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". 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] [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.

julik 2y ago
Absolutely with you on "no build". Sometimes it doesn't work (for me - where I need NPM modules with annoying math I don't want to do myself), but the basic premise of "nobuild" is absolutely and completely how it all should have always worked. It's the JSX+webpack perversion that ruined it for us all.
pjmlp 2y ago
Same approach over here for side projects, I only put up with "modern" Web development when ir isn't my choice. Classical ASP.NET, Spring with vanilla js.

davedx 2y ago

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. Unfortunately that's the world we live in now.

julik 2y ago
That one I try to avoid at all costs, but I hear what you are saying. The owner of the company selling Next.js and adjacent services is firmly in that list of influencers I have muted going forward.

fancyfredbot 2y ago

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. Recompiling the (open source) code should have offered a solution but OP could not make this work. On some platforms you can emulate the missing AVX2 instructions with intel SDE but not apple.

rsynnott 2y ago

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.

DistractionRect 2y ago
This would happen if browser technologies/standards would, you know, standardize. However, everyone and their uncle picks and chooses what they'll support, how they'll support it, and what extensions to the standard they want to champion for "standardization".
- julik 2y ago
  I'd say these days the support is pretty decent across the board, if you can limit your app to a relatively modern set of evergreen browsers (or at least - to the versions from "2 years old or newer").

jwr 2y ago

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. Most people ask "why ship bun (whatever that is), why not just be an npm module". 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? 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.

thi2 2y ago
So instead of managing your versions in one package.json and installing your dependencies with one npm i command you manage several different docker container that produce builds you then consume? What kind of horrors did you encounter that led to this abstraction?
- mbreese 2y ago
  I get this. I also do this (to some extent). Instead of installing whatever tooling I need for each project, I’ll store the tools in a Docker container. Then I don’t have to think about each project and how they interfere with each other. Even better, when something inevitably goes wrong, I can nuke the container from orbit and start over.
- jwr 2y ago
  But in this case it is me who controls when anything gets updated. And I have all of my dependencies in the container. So I get reproducible builds. Also, dependencies of one package do not interfere with dependencies of another package.
julik 2y ago
The irony of my situation was that even using a Docker container would not help, because Docker does not emulate CPU instructions.

DeathArrow 2y ago

I try to stay away as much as I can from front-end, because modern front-end is a shit show. 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. 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.

jorams 2y ago

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. 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.

julik 2y ago
The vendor does not officially publish its dropped support. But from a brief piece of research I did, Jared dropped support for macOS 12 before Apple shipped the last update for it. And while on a formalistic, nitpicky level it is a "what are you complaining about with your old box" - in actuality I do find the idea to require a CPU upgrade to run a CSS pre-processor (a CSS pre-processor! come on! not an H265 encoder. Not some sophisticated animation system. Not an AI blob. A tokenizer for HTML...) absolutely, completely excessive. And I know why that decision came - it is because building portable binaries for the Mac is a pain in the butt. Well, guess what - if you made the call of shipping a multi-platform runtime - that backwards compat is part and parcel, Apple's LLVM versions, the linker and the dylibs and whatnot. So no, I understand that you are "right" formally, but the situation this brought me to - I still find bad, and the choices made by the chain of maintainers - I still find inconsiderate.