[QuadrupleA]

As a dev who avoids build steps entirely in web stacks, hearing that 1.1 sec startup is excellent, or 10-700x faster than the norm seems strange - I've gotten so used to stuff being instant.

If you haven't tried coding a little closer to the "metal" (vanilla js/css/html) I definitely recommend it. Browsers give you a lot out of the box now, and life without builds is sweet - fast iteration time, perfect in-browser dev tool support, and vastly reduced codebase complexity.

[earthboundkid]

I’ve done both. Vanilla is fine, but people use frameworks for a reason. They really are easier, particularly for inexperienced developers, but in general for experienced developers as well. I don’t see any reason to be snooty about not using a tool because you want to keep things simple.

[brundolf]

I'm plenty familiar with "the metal", and that's all I use for my (simple) personal blog, but I happily reach for React or Next.js when they're right for the project constraints. It doesn't have to be either/or.

[spoils19]

That said, similar to GP, I'd definitely recommend it. Browsers give you a lot out of the box now, and life without builds is sweet - fast iteration time, perfect in-browser dev tool support, and vastly reduced codebase complexity.

[brundolf]

It doesn't reduce the actual code complexity at all, in my experience. You don't have to deal with configuration, which is nice (though modern frameworks and tools are simplifying that more and more), and you don't have as many dependencies, which can be a positive thing.

But your actual code - where you spend the bulk of your time in medium to large projects - is not going to be made simpler by avoiding dependencies, especially build tools. The app I work on at my job (which is a very average one in many ways) would be a nightmare of complexity without our frameworks and build tools.

There can be this purity mindset that arises around the raw web. It can be fun to indulge for personal projects, and raw web technologies can even be the right approach for some projects. But don't let the siren's song of purity blind you to the messy reality of real tradeoffs.

[QuadrupleA]

It's always paid off for me to question that assumption - to try extracting the essentials of the app without the framework, as a weekend project or whatever. Often I can cut thousands of lines of code overall and get a faster more maintainable result.

[brundolf]

Simplicity is always a virtue and we should always look for good opportunities to gravitate towards it, it just has to be balanced against other things (as everything does)

That said, I really doubt you cut "thousands of lines of" your own code by re-implementing your own partial framework. Maybe thousands of lines of dependencies were replaced with fewer thousands of lines of your own code, but that's a different question

Anyway, I was mainly pushing back against the original comment which seemed to be suggesting that build tools as a category are unnecessary, and that we should all just reject modernity and go back to living off the land. My point was that this is naive, and that it dismisses the very real value people get out of these tools every day

Questioning is good, dismissing is not

[jupp0r]

I never understood this argument. You are optimizing for a few seconds per day of saved waiting time. You buy that by having to deal with obscure differences between browsers, excluding some users, potential performance problems through lack of tree shaking, missing type safety, etc. Sure it's a trade off but for any non trivial project I've worked on it heavily skewed towards using something like webpack and babel. If you mix in things like web workers, webaudio or wasm, it gets almost impossible to use without a bundler, because otherwise library developers that use {wasm,audio workers,web workers} as an implementation detail of their libraries would leak that implementation detail out all the way to deployments (because these have to be in separate files if they aren't bundled in). Insanity.

[fenomas]

Arguments against bundlers always sound to me like a person who lives next door to their job saying "I don't get why so many people commute by car, walking works just fine".

That is - some projects don't need a bundler, and for those projects, sure, do whatever. I don't think webpack is in any danger of becoming the new jQuery, where devs add it to every project because they don't know how to work without it. People using bundlers are usually doing stuff that can't be done without them, which obviates the whole argument.

[QuadrupleA]

It's more about reducing complexity than the build time I'd say. I work in C++ too, and a couple seconds of compile and run isn't the end of the world.

I don't personally have to deal with browser differences because I stick to subsets of CSS / JS that are 98%+ supported. If all your polyfills just compile down to minimal compatible JS anyway, then maybe those language features aren't that crucial. Always try to solve the problem without the new feature - almost every time I've tried this I find I get a simpler, more maintainable result without it, e.g. simple callbacks instead of promises (sacrilege), var instead of const/let (your poor namespaces), the word “function" instead of an arrow, etc. Those are probably close enough to supported to start using now, though not sure I care. Template literals might be nice, sounds like support is close.

Re: typescript, even coming from the C world, I don't personally find type safety to be a deal breaker. I work on some large python codebases - dynamic typing makes a lot of things much easier and more concise, in exchange for not catching some errors during compile. It's a tradeoff.

Avoiding all this build nonsense does make it harder to use some libraries that come out of the crazy modern node / javascript world, but in general most good ones have release builds, and I find a bit of healthy distance from the technical tail-chasing of that ecosystem is good for productivity.

[ZephyrBlu]

Vite is basically instant for smaller projects + it has HMR for instant updates and React (And Vue, Svelte, etc I'm sure) is way more ergonomic for anything non-trival.

[AbraKdabra]

- ...it has HMR for instant updates and Vue (and React, Svelte, etc)...

Now it's ok.

[cosmotic]

Though I'm totally with you on that approach, I'm unaware of native/vanilla tools that offer hot reloading, which is pretty awesome.

[getcrunk]

If you are not bundling your code to begin with which you wouldn't be without a build step; I think there are ways to reload when a file is changed. Like an extension that speaks to a file system watcher.

[fenomas]

Hot [module] reloading refers to dynamically swapping in an updated module or asset without reloading the page. When building nontrivial stuff HMR is pretty huge for productivity.

E.g. I do a lot of procedural music via WebAudio, and being able to modify the code and hear the results as the song continues to play is obviously pretty useful.

[nop_slide]

Alpine JS plus parcel has been really fun

[blueprint]

but typescript and module inclusion?