We've hit the part of the cycle where the tooling is now a new prison to break free from.
I guess I'm getting old now??? That said, the JS build process is insane and due for an evolution.
I recently wanted a lil drag and drop web-based mood board. Drag pictures in, have functionality to move around screen.
I searched GitHub and found one that was almost perfect. Open source, so I went to go and make changes. 500MB of build dependencies later, I was troubleshooting deep in react build tooling to just get the dang page to render.
I ended up writing my own with about 200 lines of JS (if that).
Your "getting old now" implies to me that this is the first time in maybe 15 years. To my eye we've got this point every 3-4 years now.
I understand why people don't want to "just write JavaScript" but the JS community has a cultural problem with overestimating the benefits of some approach, but much moreso, utterly neglecting costs, to the point of yelling at people who want to talk about them. It is slowly and laboriously getting over that, but I see a long way to go still.
> Open source, so I went to go and make changes. 500MB of build dependencies later, I was troubleshooting deep in react build tooling to just get the dang page to render.
This happens on open source web projects where the lead maintainers want pull requests that are consistent with a given code style and feature set with docs someone else already wrote. Much easier to blame the underlying libraries and refuse the PR and let someone fork if they really want the feature that bad.
This isn't crazy to me. If you want to talk about cruft, web isn't even the worst.
The react universe is the absolute worst for this sort of thing. Honestly you should have just used a jQuery plugin. You'd be done in 1hr, with nary an npm install in sight.
>jQuery
Now that's a name I haven't heard in a while. Seriously though, it is amazing how long jQuery basically single-handedly supported the entire public facing internet. I know there was ASP and PHP/WP, but for non-cookie-cutter sites there was about 10-15 years where you could bank on jQuery as a dependency.
I kept waiting for "the next jQuery" but I guess it's never happening.
It really was (and still is, I guess) such a remarkable project. A unifying, simplifying thing that was so good it replaced 95% of the competition for a number of years.
Today... god. I realize that today's complex frontends are far from feasible in jQuery, and we could never have anything as simple as jQuery replacing them. But I'm not sure anybody actually likes what we wound up with.
I’d consider things like cheerio and alpine as the next iterations of jQuery.
Also Frontend tooling doesn’t have to be complicated, only if you let it be.
Using things like svelte or Htmx when appropriate are vastly easier than herding react or angular around.
Also things like Laravel, Rails, and Django are still massively productive web toolkits that handle nearly everything you need to do to launch projects people want to use.
I really need to check out svelte and htmx.
Definitely check out HTMX! I do like Svelte myself but I don't like how it seems like the majority of development is spent on Sveltekit itself. That said, Svelte is in a great position and can easily pair with things like Go or C# or PHP. It really reminds me of a more thoughtful react in a new age after a decade of previous lessons.
As for HTMX, they published a great book that is available for free:
https://hypermedia.systems/
The book is well written IMO, it goes through the history of hypermedia and how to create a CRUD app with HTMX + Python (Flask). The backend portions are very simple where you can easily replace it with the language of your choice, it's also not hard to find some repos online that do this too.
[deleted]
I had a similar experience. I wanted to make a mindmap/flowchart for a very complex project. Well, almost all flowchart software is meant for organizations to use, so it's got a bunch of extraneous steps that would've gotten in my way. And all the mindmap software was huge and suffered from the same problems on top of having obtuse interfaces. I just wanted something where I could right click, make an ellipse, right click it to add text that would resize the ellipse instead of the other way around, repeat, and then drag between the two in order to make a line.
I gave up and made a conspiracy board on my wall with Post-It notes and some green yarn. The only downside is I only have access to it when in my house.
My only issue with this idea is "till it hurts" or "until it becomes unworkable" may be a threshold that's hard to notice. If you're building a website just by copying and pasting html as described in the article rather than say using a simple template system you may introduce typos, lose sync between changes across pages, etc. without realizing. "Automating" copying, for example, your header html across pages isn't just about convenience, it's about consistency.
It's true. And, the sweat-hours poured into doing things "manually" might all be wasted once you automate.
Worse, you might literally doom your project -- once you're doing things the "painful, manual" way for too long, the effort required to correct course might be too great for the project to survive.
And yet...
I still think simplicity is worth striving for. "Manual till it hurts", radical simplicity, YAGNI, etc. All of it.
There are paths to failure there, but there are plenty of paths to failure when we overcomplicate/overautomate from the start too.
Yeah, I think this is a real problem for developers. Nobody gets into software development without a pretty high pain tolerance. I think the tricks here are a) developing a sensitivity to particular kinds of pain (e.g., duplication), and b) accepting that you'll have to push through a different sort of discomfort (e.g., refactoring toward DRY code) to avoid it in the long term.
you shouldn't have to copy paste html. any backend language you use probably has templates
FWIW, templates imply generation, which implies a build system (even if it's as simple as make or even a bash script).
At least that's how I interpret the lack.
No, there are tons of PHP/ERB/etc style templates that do dynamic server-side rendering at request time.
There are obvious tradeoffs involved there, but I suspect the majority of web traffic is still served that way.
Actual problem: too many people have a hard time distinguishing between a simple website and everything else.
Build tools are great for apps and "not-simple" websites.
Once you get into building a ton of CSS into a theme according to corporate design guidelines, several similar pages that only differ by their contained sections in the body, all kinds of custom widgets to support, etc. then you need build tools.
Otherwise I 100% agree people misuse build tools and then complain that the build tools are bad.
I'm fully expecting a ton of push back from the "js sucks" crowd who don't actually do web dev.
>Build tools are great for apps and "not-simple" websites.
The problem is that bootcamps and similar use project generation tools even for hello world sites while baby-devs are learning. There is no nuance. In one respect this is like jumping into the deep end of the pool and gets you moving quickly, but in another it really leaves them spinning if something goes wrong. And unless ChatGPT or a lucky SO post can tell them, optimization, speed, and cost controls are off the table altogether.
The thing is that even on a simple site with html and css while creating it there might be issues that you can quickly catch something that assists you... tools. The page looks broken? Oh, being able to lint that html or css will quickly find any issues stemming from that but hey those are tools to introduce. Not a build tool as in generating an artifact in this case but often checking is part of that pipeline to avoid errors.
I agree that it's gotten pretty crazy for certain things over the years but there's a good balance in there somewhere and it's only natural to advance technologically speaking with the addition of tools.
I think this applies at a variety of levels on a project, too.
I used to give my love of imagining futures and my love of building things free rein. But that meant I ended up building a lot of stuff that never got used, or had a bad ROI. Looking back, it just made me sad how much well-engineered stuff never really got used because I was building to my or an exec's vision, not to real needs.
I still go hog wild with imagining, but now I store the results of that in bullet-pointed lists of things we might build. Then I wait for proof of actual need before hauling out an idea (or just coming up with a new one). And even then I may write a bit of throwaway code [1], to see how sustained the need is. We manually solve a problem the first time, throwaway code the second time, and only then invest in proper automation.
I'm much happier working this way, and I get better results, because a) delaying design until actual need means your designs are based on maximum information, b) I have more time to focus on what matters, and c) I'm not carrying around as much out of date code to sort out when I realize the actual need.
[1] Note: To make this work, you have to have the discipline to throw away throwaway code. If you (or your team or your company) have a track record of not cleaning up messes, this approach is probably not for you.
I think this is too simple a rule personally. What you want to optimise for is the discounted long-term cost of not automating vs the upfront cost of automation.
While I'd agree developers often prematurely optimise, advocating to put off optimisation is crippling in many cases – especially if you're building a company with a small team. Being obsessive about efficiency in a startup is an unappreciated factor in what separate companies that succeed from those that don't imo.
It's also not so much that it hurts to not optimise, but that after a while most your day will be filled with mundane but achievable tasks, and this will prevent you from spending your time more productively.
It's the same reason you shouldn't put off fixing tech debt "until it hurts". If you wait until it starts to hurt then you've probably been suffering the efficiency / security / performance costs of putting that work off for some time. Just because it wasn't noiticably hurting doesn't mean it wasn't a cost.
I basically followed that approach with my web (browser) extension: Started with the absolute basics (HTML, CSS, vanilla JS) and slowly ran into situations where I needed more modern features – notably file splitting/imports and types to manage the growing and repetitive JS code.
The approach worked for me and I learned some neat things about vanilla CSS and JS features, but I would also rather start new projects with a boilerplate or framework, because even small projects easily grow in scope and it’s nice to be prepared for the eventuality.
Is doing this really that unworkable nowadays? It wasn't even 10 years ago when I got into programming that every tutorial just started and ended with teching you how to do it manually...
I was just trying this -- you can even do in-browser typescript compilation.
But I was missing hot-reload -- Constantly switching between the browser and my editor.
A refresh timer helped, but wasn't quite the same snappyness.
It goes to show how horrible javascript is that it has the concept of a "build step".
Not taking on any dependencies would seriously slow down most projects I work on.
All of this is performative masochism for clicks, IMO. There is nothing to be learned from here.
Performative?
It’s a simple trade-off. Some prefer to be frustrated in different ways.
Plenty of people do that without blogging about it for HN upvotes.
Yes, and it's those people we might best learn from. But that's hard to do, because they're the ones not writing about what they're doing. Possibly because they don't want their sincere views reflexively dismissed for being about the upvotes.
Maybe your projects hurt.
Maybe his project simply has expectations beyond being a static website from 1995