3 ms·

Clearly you’ve made your mind up so I won’t push harder, except one point: > Oh what's that, you want to change the style of standard button everywhere in the

Clearly you’ve made your mind up so I won’t push harder, except one point: > Oh what's that, you want to change the style of standard button everywhere in the codebase? Tailwind excels when you are using component based frameworks. This change should be at least as simple as updating main.css, except it’s in Button.tsx

stephenr 9mo ago
Why am I not surprised this rube Goldberg style machine seems like a rational thing to people who write xml to generate JavaScript to generate html.
- anon373839 9mo ago
  I think these debates ultimately come down to what you’re making with these tools: is it documents or application interfaces? If it’s documents, then plain HTML, CSS and a touch of JS sprinkles on top works very well, as they were designed for this. If you’re making software, though, at some point you’re going to need some additional tooling to make it feasible.
  - stephenr 9mo ago
    > at some point you’re going to need some additional tooling to make it feasible. I mean sure, most people will pick some kind of abstraction over parsing and constructing raw HTTP messages. But it boggles the mind that apparently a large chunk of "developers" cannot see the insanity in writing XML to generate JavaScript which generates HTML and CSS because they want to write `<Button variant="primary">Save</Button>` rather than... `<button class="primary">Save</button>`. Like I said earlier: so much of the folly in the NodeJS community looks like bizarre adoration of early-2000s J2EE stack. You have a language that requires no AOT.. ah better invent increasingly convoluted and ever-changing build processes for it. You're writing output that's essentially just a string to be sent over the wire... ah better create a wrapper for the wrapper that creates the service which renders the string. But sure. That is totally a rational approach to development, and the nodejs community has never shown itself to be prone to chasing shiny useless things or cargo culting. I must just be overreacting.
    - anon373839 9mo ago
      > But it boggles the mind that apparently a large chunk of "developers" cannot see the insanity in writing XML to generate JavaScript which generates HTML and CSS because they want to write `<Button variant="primary">Save</Button>` rather than... `<button class="primary">Save</button>`. I'm wondering if some of the disconnect here is that you don't have personal experience with this type of development, so you might not see what pain points it solves. The first thing I would mention is that components encapsulate function and styling. Buttons don't illustrate this well because they're trivial. But you can imagine a `<DatePicker>` that takes a `variant` property ("range" or "single"), `month` and `year` properties, and perhaps a property called `annotations` which accepts an array of special dates and their categories (`[{date: "2026-07-04", code: "premium_rate"}, {date: "2027-07-07", code: "sold_out"} ...]`). The end result is an interactive picker that shows the desired span, with certain dates unselectable and others marked with special color codes or symbols. You're going to have a very unpleasant time implementing that with globally scoped CSS classes. And this isn't a string sent over the wire. The "document" that the browser renders is changing continuously as you interact with it. If you were to open Chrome Devtools and look at the subtree of the DOM containing the date picker, you would see elements appearing and disappearing, gaining or losing classes and attributes, in real time as you select/deselect/skip forward/etc. That's what makes it work, rather than being a static drawing of a calendar. I personally do not like the Javascript frontend ecosystem. It's hacks on top of hacks on top of hacks. But, do you know another way to deploy software that's cross-platform and basically free of gatekeepers? Sometimes we just have to do weird things because they're really useful.
      - pyeri 9mo ago
        > I personally do not like the Javascript frontend ecosystem. It's hacks on top of hacks on top of hacks. But, do you know another way to deploy software that's cross-platform and basically free of gatekeepers? One way is what I call the "Modular MVC pattern" that involves pure js routing and manual DOM manipulation without using any framework at all. You handle complexity in two ways: by modularizing the "controller" parts into multiple js modules for each route, and "view" parts into multiple HTML partials - and using the event bus pattern if your app gets too complex (as alternative to modern reactive frameworks like react/vue). Shameless plug: I've tried to implement this exact pattern with limited success in Abhyasa Quiz App[1], a side project. [1]: https://abhyasa.pages.dev/ https://abhyasa.pages.dev/

stephenr 9mo ago

Why am I not surprised this rube Goldberg style machine seems like a rational thing to people who write xml to generate JavaScript to generate html.

anon373839 9mo ago
I think these debates ultimately come down to what you’re making with these tools: is it documents or application interfaces? If it’s documents, then plain HTML, CSS and a touch of JS sprinkles on top works very well, as they were designed for this. If you’re making software, though, at some point you’re going to need some additional tooling to make it feasible.
- stephenr 9mo ago
  > at some point you’re going to need some additional tooling to make it feasible. I mean sure, most people will pick some kind of abstraction over parsing and constructing raw HTTP messages. But it boggles the mind that apparently a large chunk of "developers" cannot see the insanity in writing XML to generate JavaScript which generates HTML and CSS because they want to write `<Button variant="primary">Save</Button>` rather than... `<button class="primary">Save</button>`. Like I said earlier: so much of the folly in the NodeJS community looks like bizarre adoration of early-2000s J2EE stack. You have a language that requires no AOT.. ah better invent increasingly convoluted and ever-changing build processes for it. You're writing output that's essentially just a string to be sent over the wire... ah better create a wrapper for the wrapper that creates the service which renders the string. But sure. That is totally a rational approach to development, and the nodejs community has never shown itself to be prone to chasing shiny useless things or cargo culting. I must just be overreacting.
  - anon373839 9mo ago
    > But it boggles the mind that apparently a large chunk of "developers" cannot see the insanity in writing XML to generate JavaScript which generates HTML and CSS because they want to write `<Button variant="primary">Save</Button>` rather than... `<button class="primary">Save</button>`. I'm wondering if some of the disconnect here is that you don't have personal experience with this type of development, so you might not see what pain points it solves. The first thing I would mention is that components encapsulate function and styling. Buttons don't illustrate this well because they're trivial. But you can imagine a `<DatePicker>` that takes a `variant` property ("range" or "single"), `month` and `year` properties, and perhaps a property called `annotations` which accepts an array of special dates and their categories (`[{date: "2026-07-04", code: "premium_rate"}, {date: "2027-07-07", code: "sold_out"} ...]`). The end result is an interactive picker that shows the desired span, with certain dates unselectable and others marked with special color codes or symbols. You're going to have a very unpleasant time implementing that with globally scoped CSS classes. And this isn't a string sent over the wire. The "document" that the browser renders is changing continuously as you interact with it. If you were to open Chrome Devtools and look at the subtree of the DOM containing the date picker, you would see elements appearing and disappearing, gaining or losing classes and attributes, in real time as you select/deselect/skip forward/etc. That's what makes it work, rather than being a static drawing of a calendar. I personally do not like the Javascript frontend ecosystem. It's hacks on top of hacks on top of hacks. But, do you know another way to deploy software that's cross-platform and basically free of gatekeepers? Sometimes we just have to do weird things because they're really useful.
    - pyeri 9mo ago
      > I personally do not like the Javascript frontend ecosystem. It's hacks on top of hacks on top of hacks. But, do you know another way to deploy software that's cross-platform and basically free of gatekeepers? One way is what I call the "Modular MVC pattern" that involves pure js routing and manual DOM manipulation without using any framework at all. You handle complexity in two ways: by modularizing the "controller" parts into multiple js modules for each route, and "view" parts into multiple HTML partials - and using the event bus pattern if your app gets too complex (as alternative to modern reactive frameworks like react/vue). Shameless plug: I've tried to implement this exact pattern with limited success in Abhyasa Quiz App[1], a side project. [1]: https://abhyasa.pages.dev/ https://abhyasa.pages.dev/