Hacker News Reader

Hacker News

Comment by simonw | Hacker News Reader

Parent Full thread

simonw

I liked Julia Evans' take on this: https://jvns.ca/blog/2023/02/16/writing-javascript-without-a...

""" My goal is that if I have a site that I made 3 or 5 years ago, I’d like to be able to, in 20 minutes:

- get the source from github on a new computer

- make some changes

- put it on the internet """

Front-end build scripts make sense for projects that are constantly developed by a team that is actively ready to incrementally fix any problems that come up.

For sites that only get maintained every year or so (and I have plenty of those myself) my experience is that they often cause more problems than they solve.

I also found that I started really enjoying JavaScript development again once I gave myself permission to ignore the npm/webpack/etc script world entirely and just write regular code that runs in browsers!

View on HN

This. I very grudgingly learnt nextjs to do "modern" JS development. Don't get me wrong it isn't a bad framework but I think I spent most of my time figuring out how 3p components worked, or how to setup build system parts or write new plugins or upgrading other dependencies - this even if I came back after say a 3 month hiatus. My layouts rarely changes. Server side rendering is a whole other pain. If you are like me and want to server side NOT in node you are sol! I was lamenting the other day that I just want to do Fe in typescript (on the browser only for fe logic) but have layouts etc just server side rendered.

I was very delighted to find htmx solves that problem for me!

I can't believe I forgot about this! I love Julia's writing, I cited a different blog post of hers in this piece.

Front-end build scripts make sense for projects that are constantly developed by a team that is actively ready to incrementally fix any problems that come up

today i had a conversation with another programmer who is doing mainly backend work, and shudders in despair looking at anything more complex with frontend javascript (and that's not even considering build tools or frameworks). i thought, perfect, that's exactly what i can help with, and then i realized that, sure i can use frameworks and build the most complex interface, but if it takes anything more than a script tag to load up the code then they will never be able to maintain it.

"i need to do WHAT to deploy this?"

i love building SPAs, i am not a stickler for minimizing the need for javascript. if it helps to solve a problem then i'll use it. but deployment has to be so easy that someone who has never touched the project can do it. "here is a website. it works. go make a copy of it. add your changes and send it back."

exactly this. i am just in the process of upgrading the framework of a site that has been built this way. the thing is that the default tools all push towards using buildtools, bundlers and transpilers. so i had to dig a little bit until figured out how to do it without.

in the process i asked myself why go through the trouble and not just use the build tools like everyone else. and i came pretty much to the same answer. when i need to make some changes to the site in a few years, i do not want to be stuck with having to figure out how to get 5 year old build tools working before i can even start working on the site.

the current site, btw was build in 2016, and it still works, and i was able to dive in with adding new features without delay. the upgrade of the framework is optional, because i want to take advantage of new features not because the site would have stopped working otherwise.

I don't understand this issue.

With a proper `package-lock` and `nvm` i picked up 3 or 4 year-old projects, installed everything with one `npm install`, made my changes and never faced a problem.

Edit: I remember facing one issue with `node-gyp` but that was just a poor choice of packages that were trying to be too native.

To counterbalance that anecdote, I have never picked up a JavaScript project more than a year old and not have to mess with the build system or package versions in order to deploy some small update.

I just picked up a project after 2 years. When i left it, eveything worked fine. Npm run and it spun right up.

Today, nothing works, module resolution problems everywhere. It's going to take me days of fixing the build system now just to get the initial compile working again.

Node is a disaster.

Could you have prevented future module resolution problems?

Your host might eventually drop the Node version you are running on, and then the house of cards come crashing down. You might have a dependency that doesn't support the new Node version you need to run.

This is why I build my personal projects in PHP even though I'm not really a fan. I use PHP and JQuery. It'll work basically forever and I can come back to it in 15 years and it'll still work.

JQuery was great when the browsers weren't so standardised; I find it unnecessary now.

It's still great for a lot of things. It's not necessary now but you still write way less code with it and it's got a ton of functions that there are no implementations of in the browser.

Plus you basically get it for free because it's browser cached because 75% of the sites out there are using it.

> Edit: I remember facing one issue with `node-gyp` but that was just a poor choice of packages that were trying to be too native.

Bingo.

> `nvm`

That's mostly why!, you need to have installed something. If you don't use a build step you don't even need nodejs, your browser is your only dependency.

Experiences vary wildly.

> With a proper `package.lock`

I've never heard of package.lock. Are you as familiar with the subject as the general tone of your comment implies?

My bad I meant `package-lock`, updated for clarity.

> Especially when the old project in question is not yours

Then it falls out of the stated scope of "updating my small website once every 5 years or so"

How have you never heard of a package lock, yet are criticizing other people's knowledge and tone?

They were being pedantic, in that `package-lock` is a thing, and `package.lock` (which is the comment originally said) doesn't. Because apparently a typo invalidates whatever experience you have.

You seem to have missed that my comment was a response to pedantry. It was not, in itself, an attempt at pedantry, let alone pedantry unprovoked.

If someone writes a comment intended to come across as knowledgeable about something (NB: in service of trying to downplay the experience of others, including the person they are responding to), but their self-report gets something as wrong as referring to package-lock.json as "package.lock", which is in the ballpark, but far enough off to be weird, then it raises questions about just how much experience they actually have with that thing (including and especially relative to the person they were trying to contradict).

This is interesting. I think what Julia might actually want is a build system that isn’t as fragile as the standard frontend build systems seem to find acceptable.

I’m not a front end dev, but I’m found the same to be true with the few occasions I’ve found myself needing to spin something up. For whatever reason, frontend dev culture doesn’t seem to value robustness in tooling - defined, as Julia noted, in being able to have tools that just work. I’m not sure why that is, but it doesn’t necessarily mean build tools as a concept are wrong. It just means that the standard implementations for them don’t seem to value developer experience.

I think Julia knows what she wants, and articulated it perfectly in her article. It wasn't this.

Reply on news.ycombinator.com