[giancarlostoro]

I have been coding frontend, backend and other system things since at least 2007 and the state of web development scares me. I shouldnt need a build tool to get JS on a website. I should be able to just run JS on a website. The web went from extremely simple and usable to "oh my what the hell is this?" It gets worse when you code frontend on proprietary systems that are hard to extend. Ever had to override something in Bootstrap with your own CSS files?

[kybernetikos]

You don't need to use these tools if you don't find it worth it. If you want to write the same sort of JS as we wrote in the old days you can still do that. If you want to write modern JS, you'll either need to restrict your audience to the most recent browsers, or you will need tooling to help you.

But it's perfectly possible to write a modern PWA using modern js, modules, and a library like react (loaded from a cdn) without any build step at all. I've done it, and it's not all that hard as long as you don't mind only targeting the latest browsers (and writing out a bunch of file names manually).

[giancarlostoro]

Honestly looking forward for WebAssembly to mature, just seeing what Microsoft has done with Blazor[0] is impressive, and that's just scratching the surface.

https://github.com/aspnet/Blazor

[symlinkk]

So you're upset that people use build tools with JavaScript but you're totally ok with using a build tool with Blazor?

[rafaelvasco]

Tons of build tools vs one build tool, I guess... People not always want to have to choose.

[asdkhadsj]

I mean, you don't have to use it, right?

I think the reason it is like that is because there were many problems with JS "back in the day", and so people felt they had to come up with solutions.

Just look at Svelte. It's a library about compiling JS to get back to the "just JS" days. I mean, it's more than that, but it's about reducing runtime complexity. So another way to think about it is that writing "old style simple JS" is so convoluted that the author felt the need to write a translation layer from modern frameworks to old style JS. Sort of a mindblower to me haha (though, I love and agree with Svelte, to be clear).

The great thing though is that you can still use plain old JS, right? Nothing has changed for you if you don't want it. So is there really a problem?

This "modern web" stuff is just people solving problems. Some of these problems are the fault of old JS/web. Some of them are problems of our own making. Remember how amazing modern UI frameworks were? It's because we had PTSD from horrible jQuery codebases. A problem of our own making.

So stick with what you like, and other people can use the more complex stuff. It's a win win, no?

[z3t4]

I did classic server side rendered apps, but experimented with pure JS apps early on where the only way to get persistence was to store things in cookies. The "app" was just a html file on the desktop that you double clicked on to open in the browser. Then came AJAX. and during the last fifteen years more and more pieces have fallen into place to make web apps more viable, like service workers, local storage, add to desktop, etc. But JS apps are much harder to develop compared to server rendered app, because you have to manage state, while server rendered apps are just a snapshot of the database.

[DonHopkins]

PTJSD: Post Traumatic JavaScript Disorder.

[jessaustin]

I don't know your situation, but ISTM you want to override Bootstrap with sass, not css? Also I wouldn't really call npm a "build tool". If you need a build tool, use parcel.

[e12e]

Npm can be pretty nice if you know what you need (which might not be the case always; the modern web stack can get pretty deep).

But I still like:

https://www.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool...

And the accompanying example repo:

https://github.com/keithamus/npm-scripts-example

I'm not eniterly clear on what parcel/webpack does better/simpler - maybe windows support?

I certainly see how one might prefer yarn over npm for dependency management, though - so maybe npm isn't as nice a build tool anymore?

[jessaustin]

I haven't used Bootstrap in a while, but all I was saying above is that it rebuilds itself with a simple "npm run dist", which under the covers is a call to node-sass. That compiles sass files, but it's still not what I consider a build tool. (Attempting to override bootstrap with a css file is DOING IT WRONG.) For build tools, people used to use Grunt and Gulp. Now they use Webpack. Parcel is better than any of those, because does the right thing automatically. That could include calling node-sass, if you want.

[e12e]

> Parcel is better than any of those, because does the right thing automatically.

Parcel does seem nice, because it does do a lot of things automatically. But I'm not sure that can always be "the right thing". For example it seems a bit surprising that plain js will always be compiled, to support ie11, while typescript will not.

Neither option is "always the right thing".

And as far as I could figure out, there's no easy way to target deploying to separate cdns?

Not trying to move the goal posts here, it's just that some configuration is to expected in the complex reality of the modern web stack.

And a benefit of npm is that that'll pretty much always be part of the stack anyway.

Did come across this, which (if it isn't outdated) fills in some information that wasn't obvious from the official documentation:

https://golb.hplar.ch/2018/01/Bundling-web-applications-with...

[jessaustin]

That's a nice link that points to some details I haven't had to consider before. I'm not sure what's going on with the "public-url" flag, because I've never needed to use that and when I look up the default [0] it says "/" which is what one would expect. Maybe this is just out of date?

I don't care much about typescript or ie11, but if there are specific improvements that could be made you could open a PR.

I don't think parcel concerns itself with deploying to separate CDNs. You can do that in npm! Does anything need to be built differently to support that? Maybe just keep files bound for different CDNs in different directories?

[0] https://parceljs.org/cli.html#set-the-public-url-to-serve-on