4 ms·

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

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). :)
  - lelanthran 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). I agree; this was probably an oversight (done in a single day, on a weekend day, so I probably spent no more than about 6 hours on it). If I want to make this production-ready, I'd move it into a repo, split it into a library (so I can drive it from Python or similar), add some tests, etc... I literally needed a once-off tool to parse HTML, and had some time to spare.
- julik 2y ago
  So do I, but we were told that "open source is a gift", and I can only have opinions about choices made by others, not command them "do it this way instead". I am not the inventor, owner or maintainer of Tailwind nor do I aspire to be. And as much as I prefer things be done well instead of.... like that... there are only that many hills to die on - and only that many people interested in my opinion :-)
  - lelanthran 2y ago
    You're a much more patient person than I am. I would've literally opened an editor, wrote a quick parser in JS, bundled it in and be done with the problem without going any further. This functionality, if I am understanding correctly, is to grab all the classnames from HTML files and then pass that to a tool that includes those, and only those, in a .css file. I'll burnout in no time if I spend even 20% of my time working on configuring or debugging the environment and the rest on the development activities[1]. I can't imagine roles where time is split 50/50 (or more) between "fiddling with YAML, npm, AWS, etc" and "development". [1] I include requirements elicitation, debugging, talking to customers, etc as "development activities".
    - julik 2y ago
      > You're a much more patient person than I am. That is very kind of you to say, thank you!
- haburka 2y ago
  > 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: This is kind of an example of the Dunning Krueger curve. You’re admitting naivety while also claiming confidence, which should give pause. The main issue I have with your argument is the framing - you’re trying to make your build tool as simple as possible to a developer like yourself which is not who the tools were built for or by. Context matters. Not everything is designed to work on 15 year old hardware and most developers would simply scoff at an engineer who thinks the best way to build software is with ancient hardware. If you view everything as trying to use as little dependencies as possible (like a C programmer should) then you absolutely will think it’s bananas that this used 100 MB of dependencies. But if you have a different perspective, you may see that the dependencies don’t matter that much as long as it works. In fact, by using common tools that have good interoperability, that are only used on a developer machine, it doesn’t matter too much what resources they use. Of course if you’re developing on a 2010 laptop with 16Gb of RAM then you may have issues but that’s not the open source developers problem. If all the open source developers had to fit your performance constraints then they would just not get much work done at all. My main point is that developer tools don’t have to be light speed, they just have to be fast enough on modern hardware, which they absolutely are for frontend. I have enjoyed 3-5 second iterative builds on all my projects for the better part of 10 years.
  - lelanthran 2y ago
    I feel you've misidentified my argument. > The main issue I have with your argument is the framing - you’re trying to make your build tool as simple as possible to a developer like yourself which is not who the tools were built for or by. My argument is "Not all of the specified dependencies are necessary", and not "None of the specified dependencies are necessary". See my other post, in which I point out that the functionality required could have been done in plain JS, using Node. That's exactly one dependency. The other dependencies are not required to have the same feature, especially as you point out: > My main point is that developer tools don’t have to be light speed, they just have to be fast enough on modern hardware If we're both agreeing with that main point of yours, there is no reasonable justification for depending on anything other than Node (which is already there in the project anyway). My PoV is less Dunning-Kreuger than you claimed; additional dependencies are added for no additional value, and come with breakages. After all > But if you have a different perspective, you may see that the dependencies don’t matter that much as long as it works. The whole point of the saga is that it doesn't work on an otherwise perfectly capable computer.

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). :)
- lelanthran 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). I agree; this was probably an oversight (done in a single day, on a weekend day, so I probably spent no more than about 6 hours on it). If I want to make this production-ready, I'd move it into a repo, split it into a library (so I can drive it from Python or similar), add some tests, etc... I literally needed a once-off tool to parse HTML, and had some time to spare.
julik 2y ago
So do I, but we were told that "open source is a gift", and I can only have opinions about choices made by others, not command them "do it this way instead". I am not the inventor, owner or maintainer of Tailwind nor do I aspire to be. And as much as I prefer things be done well instead of.... like that... there are only that many hills to die on - and only that many people interested in my opinion :-)
- lelanthran 2y ago
  You're a much more patient person than I am. I would've literally opened an editor, wrote a quick parser in JS, bundled it in and be done with the problem without going any further. This functionality, if I am understanding correctly, is to grab all the classnames from HTML files and then pass that to a tool that includes those, and only those, in a .css file. I'll burnout in no time if I spend even 20% of my time working on configuring or debugging the environment and the rest on the development activities[1]. I can't imagine roles where time is split 50/50 (or more) between "fiddling with YAML, npm, AWS, etc" and "development". [1] I include requirements elicitation, debugging, talking to customers, etc as "development activities".
  - julik 2y ago
    > You're a much more patient person than I am. That is very kind of you to say, thank you!
haburka 2y ago
> 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: This is kind of an example of the Dunning Krueger curve. You’re admitting naivety while also claiming confidence, which should give pause. The main issue I have with your argument is the framing - you’re trying to make your build tool as simple as possible to a developer like yourself which is not who the tools were built for or by. Context matters. Not everything is designed to work on 15 year old hardware and most developers would simply scoff at an engineer who thinks the best way to build software is with ancient hardware. If you view everything as trying to use as little dependencies as possible (like a C programmer should) then you absolutely will think it’s bananas that this used 100 MB of dependencies. But if you have a different perspective, you may see that the dependencies don’t matter that much as long as it works. In fact, by using common tools that have good interoperability, that are only used on a developer machine, it doesn’t matter too much what resources they use. Of course if you’re developing on a 2010 laptop with 16Gb of RAM then you may have issues but that’s not the open source developers problem. If all the open source developers had to fit your performance constraints then they would just not get much work done at all. My main point is that developer tools don’t have to be light speed, they just have to be fast enough on modern hardware, which they absolutely are for frontend. I have enjoyed 3-5 second iterative builds on all my projects for the better part of 10 years.
- lelanthran 2y ago
  I feel you've misidentified my argument. > The main issue I have with your argument is the framing - you’re trying to make your build tool as simple as possible to a developer like yourself which is not who the tools were built for or by. My argument is "Not all of the specified dependencies are necessary", and not "None of the specified dependencies are necessary". See my other post, in which I point out that the functionality required could have been done in plain JS, using Node. That's exactly one dependency. The other dependencies are not required to have the same feature, especially as you point out: > My main point is that developer tools don’t have to be light speed, they just have to be fast enough on modern hardware If we're both agreeing with that main point of yours, there is no reasonable justification for depending on anything other than Node (which is already there in the project anyway). My PoV is less Dunning-Kreuger than you claimed; additional dependencies are added for no additional value, and come with breakages. After all > But if you have a different perspective, you may see that the dependencies don’t matter that much as long as it works. The whole point of the saga is that it doesn't work on an otherwise perfectly capable computer.