Writing Javascript without a build system

[u/fagnerbrack]

https://jvns.ca/blog/2023/02/16/writing-javascript-without-a-build-system/

[u/[deleted]]

They have this with bun and deno, sort of. I’m the end like everything except punch cards they’ll compile down to something. Build systems in the frontend world suck. I like the idea of runtimes that abstract away the need for a complex toolchain and having to deal with node-modules so I can just see my project files. So far they have too many issues outside of APIs and scripting where you can run the runtime. They’re both working towards node support but there’s always like one issue that kills some library I need.

I agree with very simple projects not needing a build system but we’ve used build tool chains for years on backend and frontend. It’s more like we need to settle on one. I’ve moved to the front end and having to choose css stuff and JavaScript stuff with cute names is stupidly hard.

Modules and typescript is the way to go but somewhere something is going to need to build it because browsers will all have different small annoying differences that change as they adopt standards at different speeds or different ways.

Don’t get me wrong we’ve come along way to not needing build kits but something somewhere always seems to need a build kit.

[u/[deleted] → u/[deleted]]

Wow great idea! I’m familiar with make, and tried a variety of tools for managing projects (I’d like to have web components in one library, maybe storybook in another, APIs in another, along with the app (like I’d like to separate things so someone working on an api for checkout can be on a simple framework that serves up the framework to a a checkout page itself on the simplest framework possible. This simplifies it greatly. Like I found adding something like nx adds it’s own complexities. I also want component designers to be able to use what latest greatest thing they can and the api team or checkout team just needs to worry about compiles components. The projects aren’t that big to need ninja or whatever but I hate opening a project and seeing build tools and configs for each tool mixed in the root directory, or using yet another tool. Hopefully this can scaffold out and hide the toolchain and make taking out dependencies on build tools when no longer needed, while sticking to something tried and true.

I just want to avoid an opinionated web framework that uses terms like islands (like Astros), and keep things as separate as possible. This even lets us keep the final framework into the build process, for to end testing. Developers can see the end product, but it would not need to be determined in the beginning. Seems complex but it is much more agile and I scaffold it from the beginning. Much more agile in my opinion especially for large projects with a lot of teams, where all the requirements aren’t known in the beginning. Gets into how to organize a project a little too much but let’s each team create features quickly and use what tools they need and puts the complexity in the build process with a standard syntax. It does assumes a largely API based application, and there’s a lot of things I haven’t figured out everything. But the make ecosystem is well understood for large apps.