Hacker News Reader

Comment by wackget | Hacker News Reader

Not trying to sound like an asshole but articles like this always confuse me. "Experimenting" with no-build web apps makes it sound like web apps require build steps by default. The opposite is true.

The idea of building/compiling in web development is (and has always been) totally alien. HTML, CSS, JavaScript. None of these require a build step.

It also further confuses me when authors talk about simplifying their web tooling but instead of using the actual web languages mentioned above, they resort to using some weird framework which just introduces another learning curve and more cognitive load.

As a web developer of 20 years, you know what I build web apps with? HTML, CSS, and JavaScript.

View on HN

Also a web developer of 20 years. Used to use PHP to write old-school server-side webapps a bunch. When I first started things were just transitioning to PHP 5 as I recall. Exciting times.

Honestly, what confuses me the most is that looking at the codebase FTA it just looks like a modern webapp codebase (albeit a small one) except without TypeScript. I don't really see the point in this case. It was one thing when tooling really sucked, but we're past the Webpack days: you can setup Vite in a minute and have a really nice and very fast bundled workflow out of the box. Nowadays the performance critical bits of bundlers are written typically in Go or Rust and decently optimized, so it's not like it takes a ton of memory or CPU time to bundle a modern app, especially one that is fairly small.

There's really nothing wrong with rawdogging HTML/CSS/JS like the old days, I've certainly done it from time to time, but in this case it doesn't really look like the outcome is much different. If you're going to write a client-heavy app in a style that works perfectly well with modern tools, why not use the tools? If you don't like them, you can always get rid of them later. You can always strip out the TypeScript types and remove any reliance on bundler features and ship it as normal ES modules. It's really not hard at all, the reason why people don't do it is lack of obvious benefit.

There's some middle ground between "only dev tool is Notepad" and "hello welcome to my Vite + TypeScript + ESLint + Prettier + Svelte + SvelteKit + tRPC + Y.js + leftpad starter pack", you could always just choose the high-impact tools that help improve the code and the resulting application experience and be very deliberate about what you depend on.

I read the article but I still don't entirely understand the point. (There's a focus on "not using JS the browser doesn't understand" but also, you don't have to? Browsers now understand ES Modules and async and most other modern features even going back a few years. Even Ladybird Browser has little trouble with any of the modern features I care about!)

> The opposite is true.

Kind of.

A lot of the apps I work with have front-ends developed by one team, and those rely on back-ends developed by one or more teams. Serving server-rendered HTML is not a great option in this case (as much as I loved the "3270 way" of 1990's web). As client-side complexity increases, it starts to pay off to build on foundations that add more functionality, such as React, Vue or Angular, the same way some teams will prefer TypeScript over vanilla JavaScript. Adopting a well known framework makes easier to onboard new team members, as nomenclature and organization are already known to them. And, while we are at it, the team in charge of the visual representation will appreciate ways to better organize their CSS files, and, if possible, just serve a single CSS assembled from a set of files with definitions organized by subject or function. A build step allows an application to be served with files that define only the functionality needed, leaving most of the framework behind.

Not all web applications require it, of course, but I wouldn't say the expectation is to build a web application with bare HTLM/CSS/JS.

> A lot of the apps I work with have front-ends developed by one team, and those rely on back-ends developed by one or more teams

I hope that one effect of AI assistance will be that we can go back to full stack teams again. It should be easier to know enough about both sides to be productive in them with AI help.

Then things like backend templates + HTMX would maybe work great for 90% of apps and be vastly simpler than the huge pile of technology we've been using in the frontend.

> we can go back to full stack teams again.

Not sure it'd be good. We'd only be hiding complexity, not actually removing it. The ideal scenario would be that both front and back ends could be described in simple enough terms a single team (and less than two lifetimes of training) could handle it.

> "Experimenting" with no-build web apps makes it sound like web apps require build steps by default. The opposite is true.

It's not that it's required per se, just that when it seems like most people use applications with a build step, experimenting is the right word to use when going the other way, even if it is the default. It might even be the case that the author hasn't made apps without a build step so again in their case, they indeed are experimenting with it, even if to others it doesn't seem like an experiment. In any case, as with any experiment, they are learning something new.

This. Add in some PHP and MySQL, and I still don't have to 'build' anything.

Well, I have to build it of course. As in, me as the developer has to make it.

The website in your profile isn't even loading for me

Okay. For me it is. Never had complains like this, even with thousands of HN visitors an hour.

It's loading now

Cool, thanks for letting me know! ;) I see some traffic from HN now.

For some of my websites I block traffic from certain timezones and/or browser languages, I just double-checked but Hey Homepage doesn't block anything. May I ask from what country you're visiting? I myself experience long loading times for websites from Japan for example (I am visiting from western Europe).

> The idea of building/compiling in web development is (and has always been) totally alien. HTML, CSS, JavaScript.

Then you may be serving your users broken implementations or you may be spending way too much time handling progressive enhancement. If not, congratulations on mastering every edge case.

The rest of us use polyfills, linting, transpilation, treeshaking, and other alien tool chains to help us out.

The last 12 years of browser development (and the people who make said tools, so things get adopted quicker) are to thank for letting you do more things with less tools today.

Also minifying code seems like a no brainer for someone developing a web app.

Is it?

Bootstrap CSS: 147KB

Bootstrap CSS Minified: 122KB

Bootstrap CSS GZipped: 22KB

Bootstrap CSS GZipped and Minified: 20KB

I'm not convinved 10% is worth adding a minifier. And I ask this question for every build tool in my projects.

source: https://css-tricks.com/the-difference-between-minification-a...

CSS minifies quite poorly compared to JavaScript. JavaScript generally minifies quite well (I've seen savings as high as 85%). The minifier can mangle variable and function names as much as it wants with no effect on behavior as well as do automatic dead code elimination and constant expression evaluation. CSS does not compress nearly as easily because the minifier is much more limited in what it can compress (mostly formatting).

A way I think of this is to categorize skills by whether they'll last a decade.

Python, SQL, Linux, those are core skills I've used for over a decade and are just as useful as they were a decade ago.

Javascript is obviously more than a decade old but a reason I've avoided that ecosystem is that you're often operating in the domain of year to year tools and skills on top of it.

Decade long skills come as easily to you as English. (Or whatever your native language.) It's easy for people to overlook this because it's so easy to "learn" a skill right away and feel fluent.

I've optimized for keeping as much of my work as possible/practical in decade long skills because it's pure productivity. If I'm turning over frameworks and tools regularly I'll still be productive, but not productive. I see it as a qualitative difference, not quantitative.

There are a plethora of different ways people are using all of the tools that you mentioned.

There are so many SQL implementations and flavors, no one could possibly have a thumb on all of them.

Acting if it is somehow easier to master than the many web development tools (frameworks, build tools, etc) that you can learn how to use in a few hours seems like a confusing take.

Now I find this fascinating. Working with JavaScript, I've just come to assume continual training is part of the job -- but what if it didn't have to be?

Of course I still learn new skills in the Python/db ecosystem, but I stick to the fundamental Python/Postgres/Flask/Django/Redis/Nginx stack where possible and it not only helps productivity but it reduces surprises. We understand the exact risk profiles of these systems. You can "learn" a new tool very quickly but you won't know how to assess or reason about what will be the operational experience of it in production. We do not factor surprise tolerance into our decisions often enough.

I've interviewed "Front end Devs" who don't know the difference between a class and an id. We're becoming dinosaurs

Recently I showed somebody https://search.feep.dev and they opened the browser network tools and went “Where’s the XHR? Where’s the JavaScript?? How did you change the URL?”

They had no idea that <form><input></form> is all built in to the browser and you can make GET and POST requests without any frontend code. (Not that this is a new problem, <a onclick="document.location='...'"> has been a thing for decades at this point...)

I basically have the same approach. Still need a micro-build to fingerprint assets, though.

Well the stack has deepened.

10 years ago I would have expected you to know the HTTP protocol well.

But now I don’t ask about HTTP anymore and ask more about raw HTML/JS, because I also need to ask you about frontend things like accessibility.

I feel like this is needless nitpicking. Some of us may have grown up with PHP, DHTML, actual XML HTTP requests, and so forth. I guarantee that there is a major crowd, even on HN, who have not had this experience and who think that webpack etc. are required.

You are not the audience for this post.

Reply on news.ycombinator.com