19 ms·

Writing JavaScript without a build system

334 points by panic 4y ago

sicp-enjoyer 4y ago
My goto build system is: - make - Google's closure compiler (standalone Jar) - imagemagick It builds fast and never goes out of date.
irrational 4y ago
> But my experience with build systems (not just Javascript build systems!), is that if you have a 5-year-old site, often it’s a huge pain to get the site built again. 5 years? More like 5 minutes in my experience. I probably spend 50% of my time trying to figure out why the build system is breaking, again.
- cyanydeez 4y ago
  If you put it in docker there's basically a decade guarantee
  - TimTheTinker 4y ago
    Not if you want to allow developers to continue using the latest JS patterns, frameworks, libraries, etc.
- deleted 4y ago
  [deleted]
thex10 4y ago
> I’d love more tips for no-build-system javascript Me too. And the tips already in here are pretty good!
shaftoe444 4y ago
Great she mentioned https://unpkg.com/ https://unpkg.com/ which is a great place to start. Import maps are also worth exploring. Documentation isn't great but I've managed to ditch npm on some side projects and use import maps and CDNs instead. Worth it for small projects without a doubt.
insin 4y ago
If you use Visual Studio Code and stick a jsconfig.json in the root of your project, you can use JSDoc comments (and .d.ts files if you want) to get build-free type checking using its internal version of TypeScript: { "compilerOptions": { "checkJs": true, "target": "es2020" } }
tarkin2 4y ago
Use npm to install libraries one time only. Try to use as few dependencies as possible. You don't need a framework--components are achievable without vue and react etc. Server side rendering and VDom are really not needed for most projects. Think of Programming in JavaScript, CSS and F5 rather than Typescript and SASS as the equivalent of Marcus Aurelius' Stoicism.
- nonethewiser 4y ago
  JavaScript and CSS are to Stoicism as Typescript and SASS are to _____?
  - loop22 4y ago
    Epicureanism?
  - laurentoget 4y ago
    saint augustine?
  - lioeters 4y ago
    Hedonistic excess.
    - lioeters 4y ago
      An offended stoic.
  - earthboundkid 4y ago
    It should be “JS and CSS are to TypeScript and Sass as Stoicism is to _____?”
- sebazzz 4y ago
  > npm > Try to use as few dependencies as possible. Hahaha. You joke.
  - tarkin2 4y ago
bernardv 4y ago
All those extraneous elements to Javascript are a real turn-off. Python: batteries mostly included. Javascript: feels like you need to drag a dozen suitcases along anytime you embark on any non-trivial project.
- nonethewiser 4y ago
  Huh… in Python I feel like the tooling is largely missing.
  - zelphirkalt 4y ago
    While the Python ecosystem trends towards a similar state as the JS ecosystem, at least no one yet needs to have any ideas about "tree shaking" and hype that as some kind of "new idea". When one needs to "shake out" code, because it has become too much, one should really think about not getting that code in there in the first place. In the Python ecosystem some of the tooling does not exist, because it is not needed. Usually Python code is not shipped over network each time a website is called. Hopefully people keep dependencies of projects to a minimum, avoiding to have to fix their mistakes later by shaking out stuff. Python has an OK-ish module system, not great, but OK, compared to how JS started out. There is no need for 6-10 standards competing and requiring different "build tools" to make one huge cluster f of uglified code out of all the code of an application. Mind, it is 2023 and we still have no good way to tell the TypeScript compiler to simply spit out JavaScript code, that can immediately be served on a website, if the TS code has multiple modules. The JS ecosystem still suffers a lot from the not well thought through basis of the language and historical burden of that. Python is far from perfect itself of course. Plenty of problems in its ecosystem as well.
    - agumonkey 4y ago
      python is rarely streamed across HTTP, I believe that's the reason js is treeshaked.
      - ducharmdev 4y ago
apitman 4y ago
Skipping a build system is my default for new JavaScript these days. The main suggestion I would add is using git submodules[0] for dependencies. It's a bit unwieldy and I always have to look up the syntax, but works pretty well. You can have something like a `lib` directory in your project and place submodules for other projects in there. The dependencies need to provide some sort of a prebuilt artifact in the repo that you can import (or natively support ES Modules), but I've had good luck so far. I'll also shout out jsdelivr[1] which is great for pulling dependencies directly from github. [0]: https://git-scm.com/book/en/v2/Git-Tools-Submodules https://git-scm.com/book/en/v2/Git-Tools-Submodules [1]: https://www.jsdelivr.com/ https://www.jsdelivr.com/
dgb23 4y ago
> I’d love more tips for no-build-system javascript 1. MDN has a comprehensive guide on JavaScript modules [0] 2. A build system free way to build interactive websites could be to combine libraries like htmx[1] and or lit[2] or just the sub package lit-html[3]. Or just go with native web components and a bit of AJAX. [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid... [1] https://github.com/bigskysoftware/htmx https://github.com/bigskysoftware/htmx [2] https://github.com/lit/lit https://github.com/lit/lit [3] https://github.com/lit/lit/tree/main/packages/lit-html https://github.com/lit/lit/tree/main/packages/lit-html
- kyle-rb 4y ago
  +1 for Lit. It seems like they're mostly recommending that you use TypeScript and a build system, but you can 100% still just pull the library from a CDN with native JS modules [0]. It leans into a lot of the web components spec so the library is pretty small, and the templating system is just ES6 tagged template literals parsed by the browser's DOM parser and any embedded variables are updated dynamically [1]. [0] https://lit.dev/docs/getting-started/#use-bundles https://lit.dev/docs/getting-started/#use-bundles [1] https://lit.dev/docs/templates/overview/ https://lit.dev/docs/templates/overview/
  - benforreal 4y ago
    I think Lit is still recommending using web dev server (https://modern-web.dev/docs/dev-server/overview/ https://modern-web.dev/docs/dev-server/overview/), which no, its not a build system, but still a bit of a departure from a simple web server. And that's only needed to resolve imports that aren't a full relative path (like if I want to import Lit, I don't have to do import node_modules/lit/whatever). Someone else mentioned import maps here, and it's now supported in all browsers if you include the Safari preview release. I haven't tried it yet because I've been hung up on it being Chrome only until now, but it should complete the no-build experience. Except yeah, Typescript, but if you use it, you can just leave it watching in the background without much intervention.
    - 4y ago
kitsunesoba 4y ago
I've used `tsc --watch` as an almost-no-build-step way to write plain TypeScript with better structure (separate files, etc) for projects where dependencies aren't necessary, which works reasonably well with a few quirks, but I wish there were something more purpose-built for the task. TypeScript running natively in the browser would be amazing but I doubt that'll ever happen.
- whstl 4y ago
  I wonder how far fetched it would be to have just the syntax of Typescript on the browser without type-checking. We'd have to use tsc locally only for the typechecking, without the need of a build process, but that would be enough for me. I know there's JSDoc but the normal syntax is so much better. EDIT: Looks like there's a proposal: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations
  - mLuby 4y ago
    IIRC that's how the Flow type annotations worked, but of course it lost out to TypeScript.
    - whstl 4y ago
      Correct, but to be more precise, both Typescript and Flow allow for both JSDoc and the more common TS-like syntax.
- duped 4y ago
  The problem with build systems isn't the existence of a build step but the necessity of the build system and its configuration. Typescript is baffling-ly complex to use compared to something like python.
  - eterm 4y ago
    > tsc build What's complex about that?
bitwize 4y ago
The appeal of JavaScript when it was invented was its immediacy. No longer did you have to go through an edit-compile-debug loop, as with Java, or even an edit-upload-debug loop as with a Perl script, to see the changes you made to your web-based application. You could just mash reload on your browser and Bob's your uncle! The JavaScript community, in all its wisdom, reinvented edit-compile-debug loops for its immediate, dynamic language and I'm still assmad about it. So assmad that I, too, forgo all that shit when working on personal projects. (The enterprise fucking loves React and Vue. Can't avoid it at work.)
- dgb23 4y ago
  A thing that I liked when I started out was the fact that you could actually read all of the JavaScript on web pages. You found something interesting? Just fetch the source or open your dev tools (firebug!) and look at the code. There's probably merit in minification and compressing code though. But for the types of projects OP is talking about it's going to be single digit KB of JS anyways.
- theteapot 4y ago
  > The appeal of JavaScript when it was invented was its immediacy. You can still do that. Nothing has changed. It's probably gotten even easier. Have fun implementing a complex UI without some sort of component Framework though.
  - spankalee 4y ago
    You can easily build complex UIs without a framework. Chrome DevTools, Chrome OS, Photoshop, Firefox and other very complex apps have been built with web components.
    - textninja 4y ago
      Web Components aren’t an alternative to React so much as a complementary technology. Yes, you can build UIs without a reactive framework but it will involve compromises in expressivity, code organization, and whatever the Greenspun equivalent is for React.
hdaz0017 4y ago
looks like HN demand might have brought the site down :P This site can’t be reached
KrugerDunnings 4y ago
Deno solves all of this, too bad they don't support Solid.js.
- samjmck 4y ago
  Deno has kinda solved it for the server side, but not for the client side.
nathell 4y ago
One of my favourite hacks I did recently was in 2020 when soup.io was unexpectedly discontinued with short notice; to promote my scraping framework, Skyscraper, I quickly whipped up a content downloader. It produced an archive of assets, and I also added a rudimentary browser. The beauty of it was that it was a single static HTML file, copied verbatim to the archive. The only moving part, apart from the actual images/posts/videos, was a file called soup.js, which was just `window.soup=` plus the content metadata as JSON. I didn’t even bother to have a separate JS file for the actual code, much less a build system. I put the JS right into a `<script>` tag in the HTML. I used ES modules, HyperApp as a minimalistic React/Redux workalike, and mini.css for some sane default styling. I was amazed at how far I could get with such a rudimentary tooling. 117 SLOCs of HTML+JS, working equally well served from a server and from a local filesystem, complete with pagination, permalinks, and a jump-to-page dialog. Here it is in action, serving a friend’s soup archive: https://soup.tomash.eu/archive https://soup.tomash.eu/archive (warning: some content can be touchy and/or NSFW). View source for a glimpse of how it works.
- logicalmonster 4y ago
  > I was amazed at how far I could get with such a rudimentary tooling. Are you just 1 person working on a project? A lot of "best practices" aren't particularly needed when you're flying solo and know your code and mental processes inside and out. Where this starts to get hairy is when you have multiple developers all trying to understand one person's mental model of how the code is structured, all in one file that they have to work in.
pjmlp 4y ago
On personal projects that is my approach, vintage Web development, just like I was doing 20+ years ago.
Waterluvian 4y ago
A lightning rod of an idea I’m sure, but would it help if typescript was accepted by browsers but ignored? Then I can write my typings in-line rather than in comments, and check them, but not have to transpile. I guess “enum” as a special snowflake would fail this. Where I’m coming from is that I can live without most build steps for a small project… but I can’t live without typescript.
- ty___ler 4y ago
  Already being proposed! Would be really cool https://devblogs.microsoft.com/typescript/a-proposal-for-type-syntax-in-javascript/ https://devblogs.microsoft.com/typescript/a-proposal-for-typ...
- shadowgovt 4y ago
  Python typing kind of went in that direction.
- textninja 4y ago
  I can happily live without TypeScript (ka-chow) but at the same time I don’t see why not.
zapt02 4y ago
Getting older projects to run was a huge pain for me when I started working with JavaScript, but I have found two easy steps to get around this: 1. Use nvm + an .nvmrc file in your project to pin the major version of Node.js you are using. I recently got a five year old Node 8 project up and running with no issues using this method. 2. Try to avoid packages that has binary dependencies (like node-sass). 99% of binary issues are fixed when using the correct Node version, the only other problem that can occur is if you switch architecture (eg. x86 => ARM).
- doodlesdev 4y ago
  Why rely on nvm to pin the NodeJS version you are using? That's natively supported as a field in your package.json [0], assumimg you're using npm/yarn/pnpm (you are). Example: { "engines": { "node": ">=0.10.3 <15" } } Also, god forbid you are actually running anything using Node 8 and whatever dependencies you have there, that's a recipe for security disaster. The truth is that to use the NodeJS ecosystem we must have the discipline to keep projects up-to-date. I personally have a policy to update all my NodeJS projects at least yearly, even if they are abandoned, this includes all dependencies and the NodeJS version. Because I do it often most of the times there are not many problems to keep it working, and consequently updating is fast, but if I leave it for a few years and then come back I'll be in for a (bad) surprise. [0]: https://docs.npmjs.com/cli/v9/configuring-npm/package-json?v=true#engines https://docs.npmjs.com/cli/v9/configuring-npm/package-json?v...
  - telotortium 4y ago
    Mostly because you want your project to just work. You've tested your project with a certain version of Node, and you want to ensure that you use the same exact version when you come back to the project in a year and want to perform some minor updates. You can set the node constraint in package.json, but that doesn't install the correct version of Node for you, unlike nvm.
    - doodlesdev 4y ago
      Well that makes sense, as long as the developer running the code has nvm installed. Does nvm-windows read and install the versions in these nvmrc files? If it does your strategy is indeed pretty cool and I might start doing it myself. I wonder if there's any way to force specific versions of NodeJS without relying on nvm or some compatible tool. edit: someone here in this thread suggested Volta [0] which seems literally like what I was looking for. No need for the nvmrc as it simply follows what's in the engine property of the package.json. Even better is that it's not a weird massive shell script but instead an actual program written in Rust. I'll have to try it out sometime. [0]: https://volta.sh/ https://volta.sh/
TimTheTinker 4y ago
AMD was a great module system precisely because the build step was optional. Running the build helped on large projects (for bundling, minifying, etc.), but you could literally deploy your frontend's `src` directory to production and expect it to work as-is. A nice side-effect was that local development only required a simple file http service. I'm hoping ES module tooling, import maps, etc. get us back to that point.
- girvo 4y ago
  Indeed. I miss AMD and tooling from that time, it was all pretty straightforward and browser focused. Combined with PHP and you could do some pretty neat things, too.
cjpearson 4y ago
Regarding Tailwind 3, there's no longer a pre-generated CSS option, but a build process isn't strictly necessary. You can load the library through a CDN URL [0] and the classes will be generated in the browser. It's not recommended for production use though, so if Tailwind 2 has everything you need it's probably the better choice. [0] https://tailwindcss.com/docs/installation/play-cdn https://tailwindcss.com/docs/installation/play-cdn
phist_mcgee 4y ago
That node SSL issue is such a doozy. The fact that they added a breaking change to the way node runs, with no information in the error message about how to fix it, or even what to fix is unbelievable. We're still running node 16 just because some libraries don't work with the new SSL system. It's a massive pain.
ZephyrBlu 4y ago
Use Vite and don't look back. It's so refreshing compared to Webpack.
- Cardinal7167 4y ago
  You’re missing the entire point. That’s still a build process and still has additional overhead for both development and deployment.
  - ZephyrBlu 4y ago
    Have you used Vite before? If you have a simple project it's surprisingly fast and painless. What's the "additional overhead" you're talking about? I experienced that with Webpack, but not Vite. The author even shouts out esbuild as being "a little more stable", which Vite uses under the hood.
    - textninja 4y ago
      I think he just means you have to build before deploying and while developing. Even if that build takes fractions of a second and is trivially scaffolded and automated in a modern context, it’s still technically an extra step. There was a time I might have agreed with that take but I’ve since embraced the build since unless we’re talking about the kind of JavaScript you’d embed in a single blog article and then promptly forget about, chances are you’ll want to introduce build tools eventually.
    - spmurrayzzz 4y ago
      I'm definitely a fan of Vite personally. You can tell the project prioritized a focus on developer experience outcomes and its very well executed in my opinion. But the core package is ~27k SLOC with upwards of 40 dependencies. Thats an indirect, but poignant statement illustrating how much work goes into solving just a tooling problem. And while it may hide some of the overhead in its own abstraction, which it does a fantastic job of, the overhead is still there and it can still break in arcane ways. I think the spirit of the question of "why do we even need Vite in the first place?" is whats really being explored in the original post. I certainly don't shy away from build tools at all, but I do often try to start projects without them just as an exercise to see if they really ever end up being needed. Especially when its so easy to drop-in something like Vite after the fact if its necessary and/or clearly adds an outsized return on investment.
spankalee 4y ago
If anyone's looking for something like a framework that works with buildless workflows you might check out the project I work on: Lit ( https://lit.dev https://lit.dev ) Lit gives you reactive components, declarative HTML templates, runtime encapsulated DOM and styles, interoperability with frameworks and HTML via web components, and a lot more - with no required build tools at all. We take great care to make sure our libraries are usable without build tools. We support plain JS (in addition to TypeScript). Our libraries work straight from CDNs like Unpkg. When installed locally you can use a dev server that rewrites bare module specifiers or use an 8-line import map to make all of our core packages importable (we carefully keep all of our import specifiers compatible with the web and compact import maps). Components are inspectable with regular DevTools. You can even write components right in DevTools, or in a script tag in plain HTML. I honestly wish this weren't a unique selling point of Lit, but as far as I can tell, of the "major" frameworks or component libraries out there (including React, Vue, Angular, Solid, Ember, Svelte, Stencil, Preact, and more) we're the only ones that fully work with plain JS within our regular mainstream usage patterns.
- herpdyderp 4y ago
  I've been doing web dev for 20 years and Lit has finally allowed me to achieve my dream of what I've imagined web dev should've been like this entire time. Thank you for your work, please keep it up!
- swazzles0 4y ago
  We used Lit for a project a while ago and I definitely vouch for it. We were embedding the component into a legacy application and needed to use a build tool for older browser compatibility but it was a breeze to work with even with the extra complication our build setup added. Getting back to basics and targeting what most modern browsers support out of the box is a huge plus.
- sugarkjube 4y ago
  Thanks for the reference, interesting, I will have a look. vuejs can work without build system though. it's mentioned in the article, and I used to wwork that way. Eventually i made my own (minimal) build system though using quickjs and esbuild. Precompiling templates and minimising can be useful.
andai 4y ago
When I was learning HTML and JS in the early 2000s, most web pages had hand-written source code, and most JS I encountered was hand-crafted and unminified. So I learned programming by just reading the code of the pages I was on. That's the main reason for me not to use a build system. You lose that "transparency" and accessibility of the code. With "raw" HTML/JS, the user can just copy paste your HTML/JS (often it was just 1 file for both combined!) into notepad, save as HTML and have their own website/"app"! At least, that's how I felt until I got comfortable with TypeScript, and now I will refuse to use raw JS even for small projects... Alas! (Would be nice if V8 could strip type annotations and just run the plain JS hidden underneath... would also help with pasting TS snippets into the dev console!)
- earthboundkid 4y ago
  What about source maps?
mhd 4y ago
It seems just a few years ago when I was testing out an early version of react, and it had the JSX compiler as a header include. Worked well enough, and with more modern JS supported by default, I wouldn't mind a newer version of this. Instead of the increasingly silly attempts of coming up with weirder ways of doing server side rendering.
- tomstuart 4y ago
  The newer (or perhaps still the same!) version of this is to add `babel-standalone` to the page [0] and put the `type="text/babel"` attribute on any `<script>` tags where you want to use JSX. [0] https://reactjs.org/docs/add-react-to-a-website.html#quickly-try-jsx https://reactjs.org/docs/add-react-to-a-website.html#quickly...
Cardinal7167 4y ago
I’ve been using Fly.io’s default Go template lately since it has binary embeds by default and doesn’t incur any build system. I can’t explain how liberating it is to use vanilla JavaScript and CSS without any additional build process to develop a webapp. My entire deployment cycle is just building a go binary and pushing it. I can’t imagine going back. Even using Vue or React is just as easy as including a CDN or bundling a minified source with the binary.
handsclean 4y ago
I’ve had good luck splitting the difference by writing custom, dependency-free build scripts. You never get this accelerated code rot when you depend only on a mainstream language, it’s pretty trivial to implement a primitive version of bundling, inlining, macros, etc, and being primitive is far less limiting when you’re developing your build script hand-in-hand with your code. Some things can’t be done like this, like TypeScript, for which I keep it to a minimum, look for stability, and often include a full copy in revision control.
jefftk 4y ago
I make a lot of small simple websites, I have approximately 0 maintenance energy for any of them, and I change them very infrequently. I do this too, and no-build is definitely the way to go for them. To make this even less effort, I log directly into the web server and edit them live. Once I'm happy I check in the changes.
throwingtoofar 4y ago
For simple Typescript without node: 1. Typescript in VSCode. 2. Simple script to watch a project directory for changes to .ts files that runs... 3. ...'deno cache <file>' to transpile them to JS. Then copy them from the cache directory. deno also has a bunch of options for formatting, bundling etc.
TheRealPomax 4y ago
With JS having `import` these days, there really is zero point in bundling if you're writing normal modern JS. Just let the browser deal with caching, it's good at that, it's literally half of what it's been optimized for. The other half being JS execution.
- iamcreasy 4y ago
  Is JS import similar to Python import?
  - TheRealPomax 4y ago
    They're completely different programming languages, so: that question's nowhere near specific enough? Similar in what way? (how imports statements map to on disk files, how dependency resolution works, how caching works, etc. etc; There are too many aspects to imports, making it impossible to answer your question as posed)
    - iamcreasy 4y ago
      That partly answers my question. Thank you.
scotty79 4y ago
I wonder how hard it would be for Browsers to natively strip TypeScript syntax from the .ts files without checking and run them as .js
- deleted 4y ago
  [deleted]
- jsmith99 4y ago
  So no compile time checks and no runtime checks? What would the advantage of types be?
  - dragonwriter 4y ago
    With decent dev tooling, you are getting edit-time checks equivalent to compile-time checks (the only difference is that there is no compilation after the checking), so there’s no loss. The advantage of compile-time checking has nothing to do with “compile time” except that compile time is inherently before runtime, and edit time is even earlier.
    - dllthomas 4y ago
      The fact that you can't run without passing the checks is an advantage to compile time checks in some particular (social) contexts, although a disadvantage in others.
deleted 4y ago
[deleted]
bilalq 4y ago
While I think the goal of being able to write JS without a build system is fine, I'd still never skip setting up a build system. Static analysis, formatting, linting, optimizing, testing, and other such parts are way to valuable to ever give up. The ability to run in a dev environment without a build is valuable from a performance and feedback loop standpoint, but at the end of the day, the tooling needs to be there.
- brigandish 4y ago
  I lint using Deno, single binary, no need to pollute the system with anything more than that.
jslakro 4y ago
The fact that ES2015 was not backward compatible opened the Pandora's box to the plethora of build-system-only libs. Now the browser and your application are too distant. Exposes the dev to a world of tooling but increases friction on building, points of failure and complexity. Recently we are trying to fit them again and this post is a useful guide to do it
- deleted 4y ago
  [deleted]
adparadox 4y ago
I'm in the same camp and never want to run a build process for JavaScript ever again. I've been slowly improving https://dlitejs.com/ https://dlitejs.com/ which is a minimal (5kB minified + gzipped) JavaScript framework which works great loaded from unpkg. It's pretty crazy to see how lean a framework can be nowadays (even with two-way binding, directives, and event binding) when leveraging newer standards like Web Components and the Shadow DOM.
- eurasiantiger 4y ago
  Web Components suck, Custom Elements is where it’s at ;) Just leave out the attachShadow.
  - adparadox 4y ago
    https://github.com/adamghill/dlite/blob/main/src/component.js#L104 https://github.com/adamghill/dlite/blob/main/src/component.j... ;)
jamesgeck0 4y ago
My strategy for dealing with bit-rotting builds is to use yarn with plug-n-play. It goes farther than creating a lockfile by saving a zip of every dependency (and yarn itself) in a directory that you check into your repo. Combined with a Node version file, you can be pretty sure that you’ll be executing the exact same code in a decade. The trade off is that because it’s actually reading JS from the zip files at runtime, a lot of Node packages don’t play nicely with it. Once you get things set up, it’s great, but getting there can be exhausting for a hobby project.
- cxr 4y ago
  > plug-n-play [...] goes farther than creating a lockfile by saving a zip of every dependency (and yarn itself) in a directory that you check into your repo Imagine that: using your VCS/SCM to version control the code that goes into making your app work. > Combined with a Node version file, you can be pretty sure that you’ll be executing the exact same code in a decade. I have news for you: the Yarn-/NodeJS-specific stuff isn't necessary. With the code in your repo, you're able to roll back to a specific revision at any time. That's the whole point of version control.
  - jamesgeck0 4y ago
    Keeping a note of which version of NodeJS the project was originally developed with is absolutely necessary; it periodically makes breaking changes in major releases. I literally just had to debug a project where the build was failing due to a Node version difference. And you _can_ manage a dependency tree and keep everything up to date by hand, but it's much nicer to let Yarn do it for you.
mythz 4y ago
Vue.js seems to be the natural choice for progressive JavaScript Apps without a build system. We've also removed npm build systems from our newest .NET Project templates which uses JavaScript, Import Modules to progressively enhance Razor Pages Apps, which I've also written about in: "Simple, Modern JavaScript" https://vue-mjs.web-templates.io/blog/javascript https://vue-mjs.web-templates.io/blog/javascript As you have access to full Vue 3 you're still highly productive being able to use Vue 3's Composition API and Plugins & Components which are able to be loaded directly in the browser. We're still using TypeScript definitions for enabling static analysis benefits for external libraries but have switched to JSDoc type annotations for App code to avoid any runtime transpilation.
deleted 4y ago
[deleted]
treve 4y ago
Also _just_ did something like this and it's really rewarding: https://evertpot.com/node-changelog-cli-tool/ https://evertpot.com/node-changelog-cli-tool/
- deleted 4y ago
  [deleted]
FpUser 4y ago
I just simply do not use anything for my single page web apps that requires build. I still use build on production but strictly for bundling / minification. So far no problems. Also I do not really use any frameworks. Just some libraries with particular functionality when needed.
alxmng 4y ago
You can use ES6 imports for JS and CSS directly in the browser, by including es-module-shims[1]. No need for a package manager, transpiler, or build step. <script type="module"> import Pkg from 'https://site.com/pkg.js https://site.com/pkg.js' import sheet from 'https://site.com/sheet.css https://site.com/sheet.css' assert { type: 'css' }; </script> 1: https://github.com/guybedford/es-module-shims https://github.com/guybedford/es-module-shims
userbinator 4y ago
I might be one of the few users here who looked at the title and thought "isn't that usually true?" I don't need to write JS much, but when I do, it's with a browser open in one window and a text editor in another.
gred 4y ago
Having been away from the JS world for ~5 years, it has been an eye-opener to come back to ES 2022 + VS Code + JSDoc + //@ts-check. I'm writing an application in one big HTML file with one big script tag and no build system, and actually kind of liking it. We'll see if it scales as far as I need it to, but for now I have something with decent DX and minimal bit-rot risk.
bdcravens 4y ago
If this was important to me, I'd just use jQuery, though HTMX also looks like it'd work well (just haven't used it yet, so can't speak with authority).
crabmusket 4y ago
I agree with calling out esbuild as a great, minimal, stable tool. I recently had the chance to start a small greenfield project. As we have a lot of "tribal knowledge" of Vue I decided to keep it, but go with a "minimum viable tooling" approach. This means esbuild with no plugins, .tsx instead of .vue files (because esbuild natively supports TSX), no hot module reloading (just esbuild's simple refresh-the-page-on-build), and absolutely no CSS-in-JS, just a single style.css using BEM conventions. The same approach would probably work with any other frontend framework that can use JSX or plain JS files, even if you do run it through esbuild before it gets to the browser. In my experience, most of the complexity that creeps into JS projects is fancy build tools. Using fewer, better tools which focus on standards-compliant content is the way forward.
- swsieber 4y ago
  Hey, congrats. I have a similar setup, except using react. And I'm torn about styles. I've inlined some and done plain css for others. Though it's still just plain tsx to esbuild. I've loved it. You can add timestamps to log output by piping a command through the ts Linux command. And I have never seen the second change (it doesn't do sub second timestamps) between the start of a rebuild and the rebuild being done. It's amazing.
swsieber 4y ago
I'm working on a bigger long, term project, but I've been aiming for the sweetspot of effective yet fast builds. She noted esbuild for its stability, but it's also quite fast. My setup for a nice ui dev experience now consists of 3 things: - yarn plug-n-play - esbuild, invoked from thr cli and not node, with no plugins. I run it in watch mode. - caddy as the reverse proxy to serve the watch files and the api under a single url It has been refreshing fast. And add into that generating TS api bindings for my backend server automatically... well it's great.
- 8n4vidtmkvmk 4y ago
  i found esbuild to be inadequate last time i tried it. which i think was a couple months ago. doesn't support ts libraries nicely. still need to output to both mjs and cjs and output d.ts files for proper compatibility. only thing that fits the bill is rollup
recursivedoubts 4y ago
i design all my javascript libraries to not require build systems you can just include them in a page an go: https://htmx.org https://htmx.org https://hyperscript.org https://hyperscript.org https://github.com/bigskysoftware/idiomorph https://github.com/bigskysoftware/idiomorph https://intercoolerjs.org https://intercoolerjs.org
FlyingSnake 4y ago
Side note: How on earth did I not know about the cute little websites she makes? They are amazing! https://nginx-playground.wizardzines.com/ https://nginx-playground.wizardzines.com/ https://sql-playground.wizardzines.com/ https://sql-playground.wizardzines.com/ https://questions.wizardzines.com/ https://questions.wizardzines.com/
rcarmo 4y ago
So much this. I using Preact and still have to manually fish out files from build folders in Git repos just to have a usable library to import directly, because somehow “npm install” became the status quo.
- quectophoton 4y ago
  Same situation here, but Mithril.js instead of Preact. For small personal projects I just use git submodules[1] and symlinks, and I still haven't regretted it. Maybe it's because I set `submodule.recurse true` and `push.recurseSubmodules check`, but I still haven't found the reason why they get so much hate. I started using them (only on personal projects) partly to find out by myself what all that was about. For $DAYJOB I obviously go with what's mainstream and "best practices", but on personal projects I try to experiment and challenge assumptions to see how much I can simplify stuff, and what decisions I come to regret 6 months down the line. I either learn that some things are not as bad as others say; or I learn more about the specific pains caused by not following some advice (so I'll have more context on when it shouldn't be applied). [1]: Pointing to my own mirrors. Because not owning your dependencies is a recipe for disaster.
- wizzard0 4y ago
  I made a build-less preact template once, and still use it. It just works %)
axilmar 4y ago
The real question is why do we need React, Webpack, Tailwind, sass, jsx, etc. I've been developing web apps for the last few years and I really can't understand why all these are needed. They do not make my life easier as a developer, nor they make the code more readable. I've asked around why do we need, for example, React, and never gotten a straight answer.
- cloogshicer 4y ago
  How do you keep changes between the DOM and JS in sync without a framework? This is, from my understanding, the main value they provide.
  - distcs 4y ago
    By adding event listeners to the DOM elements that may receive updates? I don't see why you _have to_ use a framework for that. Have people forgotten to write simple code using basic JavaScript?
jibbit 4y ago
wait.. Tailwind is a big CSS file?
- pancrufty 4y ago
  Tailwind is a too-big CSS file. If you want to use Tailwind, you must use a builder. This guy is clueless. wget https://cdnjs.cloudflare.com/ajax/libs/tailwindcss/2.2.19/tailwind.min.css HTTP request sent, awaiting response... 200 OK Length: unspecified [text/css] Saving to: ‘tailwind.min.css’ tailwind.min.css [ <=> ] 2.80M 321KB/s in 10s 2023-02-17 18:44:58 (286 KB/s) - ‘tailwind.min.css’ saved [2934019] In short: 2.8 megabytes, 10 seconds for the download. From the post: > but Tailwind 3 doesn’t seem to be available as a big CSS file at all anymore […] so I’m going to keep using Tailwind 2 for now Gee I wonder why. The length people go to make internet worse for everyone…
- tbran 4y ago
  Tachyons is a similar utility class framework, and a lot smaller at somewhere under 20kb, IIRC. https://tachyons.io/ https://tachyons.io/
nargella 4y ago
I resonate with this topic. Checking your own repos on a new computer is one thing… inheriting someone else’s project and running it on your machine in the node ecosystem is very rough. Anyways, I made a slightly more advanced buildless vue project here: https://github.com/kyleparisi/buildless-vuejs https://github.com/kyleparisi/buildless-vuejs It has the advantage of using .vue files which I enjoy. Oh and guess what… it has code splitting because you have to define what components the page needs ;).
Joeri 4y ago
It is really great to finally see no build web development gaining traction. Ever since the death of IE there has been an opportunity for dramatic simplification of the web dev stack that is unserved by the major frameworks. I did a talk about the topic of no build web apps recently. The slides are here for anyone interested: https://1drv.ms/p/s!ArEoTVF2ayv3lJg4oECZk2h5eN3I3Q https://1drv.ms/p/s!ArEoTVF2ayv3lJg4oECZk2h5eN3I3Q In preparation for that talk I’ve also adapted create react app’s default project into a no build template, including a variant with routing. That can be found in github: https://github.com/jsebrech/create-react-app-zero https://github.com/jsebrech/create-react-app-zero
shantnutiwari 4y ago
>I’m not totally sure why some libraries don’t provide a no-build-system version Yeah, Ive wondered that as well. Whenever I see I have to setup a complicated build system just to run a simple hello world example, I just go yuck and stop
kentbrew 4y ago
No build system was ever used in the making of Pinterest's widgets: https://github.com/pinterest/widgets https://github.com/pinterest/widgets
adaml2017 4y ago
Just use Vue. It's perfect for this use case, has a ton of help online if you need and plenty of paths to take if you want to upgrade your project in any direction. Seriously way reinvent the wheel here?
lurluberlu 4y ago
I use : - jquery - vanilla JS - Vue
iudqnolq 4y ago
I wonder if pinning dependency versions using something like asdf's .tool-versions would help. Then you don't have to worry about node upgrades. Even simpler, you could check the esbuild binary into git.

334 points by panic 4y ago

My goto build system is: - make - Google's closure compiler (standalone Jar) - imagemagick It builds fast and never goes out of date.

irrational 4y ago

> But my experience with build systems (not just Javascript build systems!), is that if you have a 5-year-old site, often it’s a huge pain to get the site built again. 5 years? More like 5 minutes in my experience. I probably spend 50% of my time trying to figure out why the build system is breaking, again.

cyanydeez 4y ago
If you put it in docker there's basically a decade guarantee
- TimTheTinker 4y ago
  Not if you want to allow developers to continue using the latest JS patterns, frameworks, libraries, etc.
deleted 4y ago
[deleted]

thex10 4y ago

> I’d love more tips for no-build-system javascript Me too. And the tips already in here are pretty good!

shaftoe444 4y ago

Great she mentioned https://unpkg.com/ https://unpkg.com/ which is a great place to start. Import maps are also worth exploring. Documentation isn't great but I've managed to ditch npm on some side projects and use import maps and CDNs instead. Worth it for small projects without a doubt.

insin 4y ago

If you use Visual Studio Code and stick a jsconfig.json in the root of your project, you can use JSDoc comments (and .d.ts files if you want) to get build-free type checking using its internal version of TypeScript: { "compilerOptions": { "checkJs": true, "target": "es2020" } }

tarkin2 4y ago

Use npm to install libraries one time only. Try to use as few dependencies as possible. You don't need a framework--components are achievable without vue and react etc. Server side rendering and VDom are really not needed for most projects. Think of Programming in JavaScript, CSS and F5 rather than Typescript and SASS as the equivalent of Marcus Aurelius' Stoicism.

nonethewiser 4y ago
JavaScript and CSS are to Stoicism as Typescript and SASS are to _____?
- loop22 4y ago
  Epicureanism?
- laurentoget 4y ago
  saint augustine?
- lioeters 4y ago
  Hedonistic excess.
  - lioeters 4y ago
    An offended stoic.
- earthboundkid 4y ago
  It should be “JS and CSS are to TypeScript and Sass as Stoicism is to _____?”
sebazzz 4y ago
> npm > Try to use as few dependencies as possible. Hahaha. You joke.
- tarkin2 4y ago

bernardv 4y ago

All those extraneous elements to Javascript are a real turn-off. Python: batteries mostly included. Javascript: feels like you need to drag a dozen suitcases along anytime you embark on any non-trivial project.

nonethewiser 4y ago
Huh… in Python I feel like the tooling is largely missing.
- zelphirkalt 4y ago
  While the Python ecosystem trends towards a similar state as the JS ecosystem, at least no one yet needs to have any ideas about "tree shaking" and hype that as some kind of "new idea". When one needs to "shake out" code, because it has become too much, one should really think about not getting that code in there in the first place. In the Python ecosystem some of the tooling does not exist, because it is not needed. Usually Python code is not shipped over network each time a website is called. Hopefully people keep dependencies of projects to a minimum, avoiding to have to fix their mistakes later by shaking out stuff. Python has an OK-ish module system, not great, but OK, compared to how JS started out. There is no need for 6-10 standards competing and requiring different "build tools" to make one huge cluster f of uglified code out of all the code of an application. Mind, it is 2023 and we still have no good way to tell the TypeScript compiler to simply spit out JavaScript code, that can immediately be served on a website, if the TS code has multiple modules. The JS ecosystem still suffers a lot from the not well thought through basis of the language and historical burden of that. Python is far from perfect itself of course. Plenty of problems in its ecosystem as well.
  - agumonkey 4y ago
    python is rarely streamed across HTTP, I believe that's the reason js is treeshaked.
    - ducharmdev 4y ago

apitman 4y ago

Skipping a build system is my default for new JavaScript these days. The main suggestion I would add is using git submodules[0] for dependencies. It's a bit unwieldy and I always have to look up the syntax, but works pretty well. You can have something like a `lib` directory in your project and place submodules for other projects in there. The dependencies need to provide some sort of a prebuilt artifact in the repo that you can import (or natively support ES Modules), but I've had good luck so far. I'll also shout out jsdelivr[1] which is great for pulling dependencies directly from github. [0]: https://git-scm.com/book/en/v2/Git-Tools-Submodules https://git-scm.com/book/en/v2/Git-Tools-Submodules [1]: https://www.jsdelivr.com/ https://www.jsdelivr.com/

dgb23 4y ago

> I’d love more tips for no-build-system javascript 1. MDN has a comprehensive guide on JavaScript modules [0] 2. A build system free way to build interactive websites could be to combine libraries like htmx[1] and or lit[2] or just the sub package lit-html[3]. Or just go with native web components and a bit of AJAX. [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid... [1] https://github.com/bigskysoftware/htmx https://github.com/bigskysoftware/htmx [2] https://github.com/lit/lit https://github.com/lit/lit [3] https://github.com/lit/lit/tree/main/packages/lit-html https://github.com/lit/lit/tree/main/packages/lit-html

kyle-rb 4y ago
+1 for Lit. It seems like they're mostly recommending that you use TypeScript and a build system, but you can 100% still just pull the library from a CDN with native JS modules [0]. It leans into a lot of the web components spec so the library is pretty small, and the templating system is just ES6 tagged template literals parsed by the browser's DOM parser and any embedded variables are updated dynamically [1]. [0] https://lit.dev/docs/getting-started/#use-bundles https://lit.dev/docs/getting-started/#use-bundles [1] https://lit.dev/docs/templates/overview/ https://lit.dev/docs/templates/overview/
- benforreal 4y ago
  I think Lit is still recommending using web dev server (https://modern-web.dev/docs/dev-server/overview/ https://modern-web.dev/docs/dev-server/overview/), which no, its not a build system, but still a bit of a departure from a simple web server. And that's only needed to resolve imports that aren't a full relative path (like if I want to import Lit, I don't have to do import node_modules/lit/whatever). Someone else mentioned import maps here, and it's now supported in all browsers if you include the Safari preview release. I haven't tried it yet because I've been hung up on it being Chrome only until now, but it should complete the no-build experience. Except yeah, Typescript, but if you use it, you can just leave it watching in the background without much intervention.
  - 4y ago

kitsunesoba 4y ago

I've used `tsc --watch` as an almost-no-build-step way to write plain TypeScript with better structure (separate files, etc) for projects where dependencies aren't necessary, which works reasonably well with a few quirks, but I wish there were something more purpose-built for the task. TypeScript running natively in the browser would be amazing but I doubt that'll ever happen.

whstl 4y ago
I wonder how far fetched it would be to have just the syntax of Typescript on the browser without type-checking. We'd have to use tsc locally only for the typechecking, without the need of a build process, but that would be enough for me. I know there's JSDoc but the normal syntax is so much better. EDIT: Looks like there's a proposal: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations
- mLuby 4y ago
  IIRC that's how the Flow type annotations worked, but of course it lost out to TypeScript.
  - whstl 4y ago
    Correct, but to be more precise, both Typescript and Flow allow for both JSDoc and the more common TS-like syntax.
duped 4y ago
The problem with build systems isn't the existence of a build step but the necessity of the build system and its configuration. Typescript is baffling-ly complex to use compared to something like python.
- eterm 4y ago
  > tsc build What's complex about that?

bitwize 4y ago

The appeal of JavaScript when it was invented was its immediacy. No longer did you have to go through an edit-compile-debug loop, as with Java, or even an edit-upload-debug loop as with a Perl script, to see the changes you made to your web-based application. You could just mash reload on your browser and Bob's your uncle! The JavaScript community, in all its wisdom, reinvented edit-compile-debug loops for its immediate, dynamic language and I'm still assmad about it. So assmad that I, too, forgo all that shit when working on personal projects. (The enterprise fucking loves React and Vue. Can't avoid it at work.)

dgb23 4y ago
A thing that I liked when I started out was the fact that you could actually read all of the JavaScript on web pages. You found something interesting? Just fetch the source or open your dev tools (firebug!) and look at the code. There's probably merit in minification and compressing code though. But for the types of projects OP is talking about it's going to be single digit KB of JS anyways.
theteapot 4y ago
> The appeal of JavaScript when it was invented was its immediacy. You can still do that. Nothing has changed. It's probably gotten even easier. Have fun implementing a complex UI without some sort of component Framework though.
- spankalee 4y ago
  You can easily build complex UIs without a framework. Chrome DevTools, Chrome OS, Photoshop, Firefox and other very complex apps have been built with web components.
  - textninja 4y ago
    Web Components aren’t an alternative to React so much as a complementary technology. Yes, you can build UIs without a reactive framework but it will involve compromises in expressivity, code organization, and whatever the Greenspun equivalent is for React.

hdaz0017 4y ago

looks like HN demand might have brought the site down :P This site can’t be reached

KrugerDunnings 4y ago

Deno solves all of this, too bad they don't support Solid.js.

samjmck 4y ago
Deno has kinda solved it for the server side, but not for the client side.

nathell 4y ago

One of my favourite hacks I did recently was in 2020 when soup.io was unexpectedly discontinued with short notice; to promote my scraping framework, Skyscraper, I quickly whipped up a content downloader. It produced an archive of assets, and I also added a rudimentary browser. The beauty of it was that it was a single static HTML file, copied verbatim to the archive. The only moving part, apart from the actual images/posts/videos, was a file called soup.js, which was just `window.soup=` plus the content metadata as JSON. I didn’t even bother to have a separate JS file for the actual code, much less a build system. I put the JS right into a `<script>` tag in the HTML. I used ES modules, HyperApp as a minimalistic React/Redux workalike, and mini.css for some sane default styling. I was amazed at how far I could get with such a rudimentary tooling. 117 SLOCs of HTML+JS, working equally well served from a server and from a local filesystem, complete with pagination, permalinks, and a jump-to-page dialog. Here it is in action, serving a friend’s soup archive: https://soup.tomash.eu/archive https://soup.tomash.eu/archive (warning: some content can be touchy and/or NSFW). View source for a glimpse of how it works.

logicalmonster 4y ago
> I was amazed at how far I could get with such a rudimentary tooling. Are you just 1 person working on a project? A lot of "best practices" aren't particularly needed when you're flying solo and know your code and mental processes inside and out. Where this starts to get hairy is when you have multiple developers all trying to understand one person's mental model of how the code is structured, all in one file that they have to work in.

pjmlp 4y ago

On personal projects that is my approach, vintage Web development, just like I was doing 20+ years ago.

Waterluvian 4y ago

A lightning rod of an idea I’m sure, but would it help if typescript was accepted by browsers but ignored? Then I can write my typings in-line rather than in comments, and check them, but not have to transpile. I guess “enum” as a special snowflake would fail this. Where I’m coming from is that I can live without most build steps for a small project… but I can’t live without typescript.

ty___ler 4y ago
Already being proposed! Would be really cool https://devblogs.microsoft.com/typescript/a-proposal-for-type-syntax-in-javascript/ https://devblogs.microsoft.com/typescript/a-proposal-for-typ...
shadowgovt 4y ago
Python typing kind of went in that direction.
textninja 4y ago
I can happily live without TypeScript (ka-chow) but at the same time I don’t see why not.

zapt02 4y ago

Getting older projects to run was a huge pain for me when I started working with JavaScript, but I have found two easy steps to get around this: 1. Use nvm + an .nvmrc file in your project to pin the major version of Node.js you are using. I recently got a five year old Node 8 project up and running with no issues using this method. 2. Try to avoid packages that has binary dependencies (like node-sass). 99% of binary issues are fixed when using the correct Node version, the only other problem that can occur is if you switch architecture (eg. x86 => ARM).

doodlesdev 4y ago
Why rely on nvm to pin the NodeJS version you are using? That's natively supported as a field in your package.json [0], assumimg you're using npm/yarn/pnpm (you are). Example: { "engines": { "node": ">=0.10.3 <15" } } Also, god forbid you are actually running anything using Node 8 and whatever dependencies you have there, that's a recipe for security disaster. The truth is that to use the NodeJS ecosystem we must have the discipline to keep projects up-to-date. I personally have a policy to update all my NodeJS projects at least yearly, even if they are abandoned, this includes all dependencies and the NodeJS version. Because I do it often most of the times there are not many problems to keep it working, and consequently updating is fast, but if I leave it for a few years and then come back I'll be in for a (bad) surprise. [0]: https://docs.npmjs.com/cli/v9/configuring-npm/package-json?v=true#engines https://docs.npmjs.com/cli/v9/configuring-npm/package-json?v...
- telotortium 4y ago
  Mostly because you want your project to just work. You've tested your project with a certain version of Node, and you want to ensure that you use the same exact version when you come back to the project in a year and want to perform some minor updates. You can set the node constraint in package.json, but that doesn't install the correct version of Node for you, unlike nvm.
  - doodlesdev 4y ago
    Well that makes sense, as long as the developer running the code has nvm installed. Does nvm-windows read and install the versions in these nvmrc files? If it does your strategy is indeed pretty cool and I might start doing it myself. I wonder if there's any way to force specific versions of NodeJS without relying on nvm or some compatible tool. edit: someone here in this thread suggested Volta [0] which seems literally like what I was looking for. No need for the nvmrc as it simply follows what's in the engine property of the package.json. Even better is that it's not a weird massive shell script but instead an actual program written in Rust. I'll have to try it out sometime. [0]: https://volta.sh/ https://volta.sh/

TimTheTinker 4y ago

AMD was a great module system precisely because the build step was optional. Running the build helped on large projects (for bundling, minifying, etc.), but you could literally deploy your frontend's `src` directory to production and expect it to work as-is. A nice side-effect was that local development only required a simple file http service. I'm hoping ES module tooling, import maps, etc. get us back to that point.

girvo 4y ago
Indeed. I miss AMD and tooling from that time, it was all pretty straightforward and browser focused. Combined with PHP and you could do some pretty neat things, too.

cjpearson 4y ago

Regarding Tailwind 3, there's no longer a pre-generated CSS option, but a build process isn't strictly necessary. You can load the library through a CDN URL [0] and the classes will be generated in the browser. It's not recommended for production use though, so if Tailwind 2 has everything you need it's probably the better choice. [0] https://tailwindcss.com/docs/installation/play-cdn https://tailwindcss.com/docs/installation/play-cdn

phist_mcgee 4y ago

That node SSL issue is such a doozy. The fact that they added a breaking change to the way node runs, with no information in the error message about how to fix it, or even what to fix is unbelievable. We're still running node 16 just because some libraries don't work with the new SSL system. It's a massive pain.

ZephyrBlu 4y ago

Use Vite and don't look back. It's so refreshing compared to Webpack.

Cardinal7167 4y ago
You’re missing the entire point. That’s still a build process and still has additional overhead for both development and deployment.
- ZephyrBlu 4y ago
  Have you used Vite before? If you have a simple project it's surprisingly fast and painless. What's the "additional overhead" you're talking about? I experienced that with Webpack, but not Vite. The author even shouts out esbuild as being "a little more stable", which Vite uses under the hood.
  - textninja 4y ago
    I think he just means you have to build before deploying and while developing. Even if that build takes fractions of a second and is trivially scaffolded and automated in a modern context, it’s still technically an extra step. There was a time I might have agreed with that take but I’ve since embraced the build since unless we’re talking about the kind of JavaScript you’d embed in a single blog article and then promptly forget about, chances are you’ll want to introduce build tools eventually.
  - spmurrayzzz 4y ago
    I'm definitely a fan of Vite personally. You can tell the project prioritized a focus on developer experience outcomes and its very well executed in my opinion. But the core package is ~27k SLOC with upwards of 40 dependencies. Thats an indirect, but poignant statement illustrating how much work goes into solving just a tooling problem. And while it may hide some of the overhead in its own abstraction, which it does a fantastic job of, the overhead is still there and it can still break in arcane ways. I think the spirit of the question of "why do we even need Vite in the first place?" is whats really being explored in the original post. I certainly don't shy away from build tools at all, but I do often try to start projects without them just as an exercise to see if they really ever end up being needed. Especially when its so easy to drop-in something like Vite after the fact if its necessary and/or clearly adds an outsized return on investment.

spankalee 4y ago

If anyone's looking for something like a framework that works with buildless workflows you might check out the project I work on: Lit ( https://lit.dev https://lit.dev ) Lit gives you reactive components, declarative HTML templates, runtime encapsulated DOM and styles, interoperability with frameworks and HTML via web components, and a lot more - with no required build tools at all. We take great care to make sure our libraries are usable without build tools. We support plain JS (in addition to TypeScript). Our libraries work straight from CDNs like Unpkg. When installed locally you can use a dev server that rewrites bare module specifiers or use an 8-line import map to make all of our core packages importable (we carefully keep all of our import specifiers compatible with the web and compact import maps). Components are inspectable with regular DevTools. You can even write components right in DevTools, or in a script tag in plain HTML. I honestly wish this weren't a unique selling point of Lit, but as far as I can tell, of the "major" frameworks or component libraries out there (including React, Vue, Angular, Solid, Ember, Svelte, Stencil, Preact, and more) we're the only ones that fully work with plain JS within our regular mainstream usage patterns.

herpdyderp 4y ago
I've been doing web dev for 20 years and Lit has finally allowed me to achieve my dream of what I've imagined web dev should've been like this entire time. Thank you for your work, please keep it up!
swazzles0 4y ago
We used Lit for a project a while ago and I definitely vouch for it. We were embedding the component into a legacy application and needed to use a build tool for older browser compatibility but it was a breeze to work with even with the extra complication our build setup added. Getting back to basics and targeting what most modern browsers support out of the box is a huge plus.
sugarkjube 4y ago
Thanks for the reference, interesting, I will have a look. vuejs can work without build system though. it's mentioned in the article, and I used to wwork that way. Eventually i made my own (minimal) build system though using quickjs and esbuild. Precompiling templates and minimising can be useful.

andai 4y ago

When I was learning HTML and JS in the early 2000s, most web pages had hand-written source code, and most JS I encountered was hand-crafted and unminified. So I learned programming by just reading the code of the pages I was on. That's the main reason for me not to use a build system. You lose that "transparency" and accessibility of the code. With "raw" HTML/JS, the user can just copy paste your HTML/JS (often it was just 1 file for both combined!) into notepad, save as HTML and have their own website/"app"! At least, that's how I felt until I got comfortable with TypeScript, and now I will refuse to use raw JS even for small projects... Alas! (Would be nice if V8 could strip type annotations and just run the plain JS hidden underneath... would also help with pasting TS snippets into the dev console!)

earthboundkid 4y ago
What about source maps?

mhd 4y ago

It seems just a few years ago when I was testing out an early version of react, and it had the JSX compiler as a header include. Worked well enough, and with more modern JS supported by default, I wouldn't mind a newer version of this. Instead of the increasingly silly attempts of coming up with weirder ways of doing server side rendering.

tomstuart 4y ago
The newer (or perhaps still the same!) version of this is to add `babel-standalone` to the page [0] and put the `type="text/babel"` attribute on any `<script>` tags where you want to use JSX. [0] https://reactjs.org/docs/add-react-to-a-website.html#quickly-try-jsx https://reactjs.org/docs/add-react-to-a-website.html#quickly...

Cardinal7167 4y ago

I’ve been using Fly.io’s default Go template lately since it has binary embeds by default and doesn’t incur any build system. I can’t explain how liberating it is to use vanilla JavaScript and CSS without any additional build process to develop a webapp. My entire deployment cycle is just building a go binary and pushing it. I can’t imagine going back. Even using Vue or React is just as easy as including a CDN or bundling a minified source with the binary.

handsclean 4y ago

I’ve had good luck splitting the difference by writing custom, dependency-free build scripts. You never get this accelerated code rot when you depend only on a mainstream language, it’s pretty trivial to implement a primitive version of bundling, inlining, macros, etc, and being primitive is far less limiting when you’re developing your build script hand-in-hand with your code. Some things can’t be done like this, like TypeScript, for which I keep it to a minimum, look for stability, and often include a full copy in revision control.

jefftk 4y ago

I make a lot of small simple websites, I have approximately 0 maintenance energy for any of them, and I change them very infrequently. I do this too, and no-build is definitely the way to go for them. To make this even less effort, I log directly into the web server and edit them live. Once I'm happy I check in the changes.

throwingtoofar 4y ago

For simple Typescript without node: 1. Typescript in VSCode. 2. Simple script to watch a project directory for changes to .ts files that runs... 3. ...'deno cache <file>' to transpile them to JS. Then copy them from the cache directory. deno also has a bunch of options for formatting, bundling etc.

TheRealPomax 4y ago

With JS having `import` these days, there really is zero point in bundling if you're writing normal modern JS. Just let the browser deal with caching, it's good at that, it's literally half of what it's been optimized for. The other half being JS execution.

iamcreasy 4y ago
Is JS import similar to Python import?
- TheRealPomax 4y ago
  They're completely different programming languages, so: that question's nowhere near specific enough? Similar in what way? (how imports statements map to on disk files, how dependency resolution works, how caching works, etc. etc; There are too many aspects to imports, making it impossible to answer your question as posed)
  - iamcreasy 4y ago
    That partly answers my question. Thank you.

scotty79 4y ago

I wonder how hard it would be for Browsers to natively strip TypeScript syntax from the .ts files without checking and run them as .js

deleted 4y ago
[deleted]
jsmith99 4y ago
So no compile time checks and no runtime checks? What would the advantage of types be?
- dragonwriter 4y ago
  With decent dev tooling, you are getting edit-time checks equivalent to compile-time checks (the only difference is that there is no compilation after the checking), so there’s no loss. The advantage of compile-time checking has nothing to do with “compile time” except that compile time is inherently before runtime, and edit time is even earlier.
  - dllthomas 4y ago
    The fact that you can't run without passing the checks is an advantage to compile time checks in some particular (social) contexts, although a disadvantage in others.

deleted 4y ago

[deleted]

bilalq 4y ago

While I think the goal of being able to write JS without a build system is fine, I'd still never skip setting up a build system. Static analysis, formatting, linting, optimizing, testing, and other such parts are way to valuable to ever give up. The ability to run in a dev environment without a build is valuable from a performance and feedback loop standpoint, but at the end of the day, the tooling needs to be there.

brigandish 4y ago
I lint using Deno, single binary, no need to pollute the system with anything more than that.

jslakro 4y ago

The fact that ES2015 was not backward compatible opened the Pandora's box to the plethora of build-system-only libs. Now the browser and your application are too distant. Exposes the dev to a world of tooling but increases friction on building, points of failure and complexity. Recently we are trying to fit them again and this post is a useful guide to do it

deleted 4y ago
[deleted]

adparadox 4y ago

I'm in the same camp and never want to run a build process for JavaScript ever again. I've been slowly improving https://dlitejs.com/ https://dlitejs.com/ which is a minimal (5kB minified + gzipped) JavaScript framework which works great loaded from unpkg. It's pretty crazy to see how lean a framework can be nowadays (even with two-way binding, directives, and event binding) when leveraging newer standards like Web Components and the Shadow DOM.

eurasiantiger 4y ago
Web Components suck, Custom Elements is where it’s at ;) Just leave out the attachShadow.
- adparadox 4y ago
  https://github.com/adamghill/dlite/blob/main/src/component.js#L104 https://github.com/adamghill/dlite/blob/main/src/component.j... ;)

jamesgeck0 4y ago

My strategy for dealing with bit-rotting builds is to use yarn with plug-n-play. It goes farther than creating a lockfile by saving a zip of every dependency (and yarn itself) in a directory that you check into your repo. Combined with a Node version file, you can be pretty sure that you’ll be executing the exact same code in a decade. The trade off is that because it’s actually reading JS from the zip files at runtime, a lot of Node packages don’t play nicely with it. Once you get things set up, it’s great, but getting there can be exhausting for a hobby project.

cxr 4y ago
> plug-n-play [...] goes farther than creating a lockfile by saving a zip of every dependency (and yarn itself) in a directory that you check into your repo Imagine that: using your VCS/SCM to version control the code that goes into making your app work. > Combined with a Node version file, you can be pretty sure that you’ll be executing the exact same code in a decade. I have news for you: the Yarn-/NodeJS-specific stuff isn't necessary. With the code in your repo, you're able to roll back to a specific revision at any time. That's the whole point of version control.
- jamesgeck0 4y ago
  Keeping a note of which version of NodeJS the project was originally developed with is absolutely necessary; it periodically makes breaking changes in major releases. I literally just had to debug a project where the build was failing due to a Node version difference. And you _can_ manage a dependency tree and keep everything up to date by hand, but it's much nicer to let Yarn do it for you.

mythz 4y ago

Vue.js seems to be the natural choice for progressive JavaScript Apps without a build system. We've also removed npm build systems from our newest .NET Project templates which uses JavaScript, Import Modules to progressively enhance Razor Pages Apps, which I've also written about in: "Simple, Modern JavaScript" https://vue-mjs.web-templates.io/blog/javascript https://vue-mjs.web-templates.io/blog/javascript As you have access to full Vue 3 you're still highly productive being able to use Vue 3's Composition API and Plugins & Components which are able to be loaded directly in the browser. We're still using TypeScript definitions for enabling static analysis benefits for external libraries but have switched to JSDoc type annotations for App code to avoid any runtime transpilation.

deleted 4y ago

[deleted]

treve 4y ago

Also _just_ did something like this and it's really rewarding: https://evertpot.com/node-changelog-cli-tool/ https://evertpot.com/node-changelog-cli-tool/

deleted 4y ago
[deleted]

FpUser 4y ago

I just simply do not use anything for my single page web apps that requires build. I still use build on production but strictly for bundling / minification. So far no problems. Also I do not really use any frameworks. Just some libraries with particular functionality when needed.

alxmng 4y ago

You can use ES6 imports for JS and CSS directly in the browser, by including es-module-shims[1]. No need for a package manager, transpiler, or build step. <script type="module"> import Pkg from 'https://site.com/pkg.js https://site.com/pkg.js' import sheet from 'https://site.com/sheet.css https://site.com/sheet.css' assert { type: 'css' }; </script> 1: https://github.com/guybedford/es-module-shims https://github.com/guybedford/es-module-shims

userbinator 4y ago

I might be one of the few users here who looked at the title and thought "isn't that usually true?" I don't need to write JS much, but when I do, it's with a browser open in one window and a text editor in another.

gred 4y ago

Having been away from the JS world for ~5 years, it has been an eye-opener to come back to ES 2022 + VS Code + JSDoc + //@ts-check. I'm writing an application in one big HTML file with one big script tag and no build system, and actually kind of liking it. We'll see if it scales as far as I need it to, but for now I have something with decent DX and minimal bit-rot risk.

bdcravens 4y ago

If this was important to me, I'd just use jQuery, though HTMX also looks like it'd work well (just haven't used it yet, so can't speak with authority).

crabmusket 4y ago

I agree with calling out esbuild as a great, minimal, stable tool. I recently had the chance to start a small greenfield project. As we have a lot of "tribal knowledge" of Vue I decided to keep it, but go with a "minimum viable tooling" approach. This means esbuild with no plugins, .tsx instead of .vue files (because esbuild natively supports TSX), no hot module reloading (just esbuild's simple refresh-the-page-on-build), and absolutely no CSS-in-JS, just a single style.css using BEM conventions. The same approach would probably work with any other frontend framework that can use JSX or plain JS files, even if you do run it through esbuild before it gets to the browser. In my experience, most of the complexity that creeps into JS projects is fancy build tools. Using fewer, better tools which focus on standards-compliant content is the way forward.

swsieber 4y ago
Hey, congrats. I have a similar setup, except using react. And I'm torn about styles. I've inlined some and done plain css for others. Though it's still just plain tsx to esbuild. I've loved it. You can add timestamps to log output by piping a command through the ts Linux command. And I have never seen the second change (it doesn't do sub second timestamps) between the start of a rebuild and the rebuild being done. It's amazing.

swsieber 4y ago

I'm working on a bigger long, term project, but I've been aiming for the sweetspot of effective yet fast builds. She noted esbuild for its stability, but it's also quite fast. My setup for a nice ui dev experience now consists of 3 things: - yarn plug-n-play - esbuild, invoked from thr cli and not node, with no plugins. I run it in watch mode. - caddy as the reverse proxy to serve the watch files and the api under a single url It has been refreshing fast. And add into that generating TS api bindings for my backend server automatically... well it's great.

8n4vidtmkvmk 4y ago
i found esbuild to be inadequate last time i tried it. which i think was a couple months ago. doesn't support ts libraries nicely. still need to output to both mjs and cjs and output d.ts files for proper compatibility. only thing that fits the bill is rollup

recursivedoubts 4y ago

i design all my javascript libraries to not require build systems you can just include them in a page an go: https://htmx.org https://htmx.org https://hyperscript.org https://hyperscript.org https://github.com/bigskysoftware/idiomorph https://github.com/bigskysoftware/idiomorph https://intercoolerjs.org https://intercoolerjs.org

FlyingSnake 4y ago

Side note: How on earth did I not know about the cute little websites she makes? They are amazing! https://nginx-playground.wizardzines.com/ https://nginx-playground.wizardzines.com/ https://sql-playground.wizardzines.com/ https://sql-playground.wizardzines.com/ https://questions.wizardzines.com/ https://questions.wizardzines.com/

rcarmo 4y ago

So much this. I using Preact and still have to manually fish out files from build folders in Git repos just to have a usable library to import directly, because somehow “npm install” became the status quo.

quectophoton 4y ago
Same situation here, but Mithril.js instead of Preact. For small personal projects I just use git submodules[1] and symlinks, and I still haven't regretted it. Maybe it's because I set `submodule.recurse true` and `push.recurseSubmodules check`, but I still haven't found the reason why they get so much hate. I started using them (only on personal projects) partly to find out by myself what all that was about. For $DAYJOB I obviously go with what's mainstream and "best practices", but on personal projects I try to experiment and challenge assumptions to see how much I can simplify stuff, and what decisions I come to regret 6 months down the line. I either learn that some things are not as bad as others say; or I learn more about the specific pains caused by not following some advice (so I'll have more context on when it shouldn't be applied). [1]: Pointing to my own mirrors. Because not owning your dependencies is a recipe for disaster.
wizzard0 4y ago
I made a build-less preact template once, and still use it. It just works %)

axilmar 4y ago

The real question is why do we need React, Webpack, Tailwind, sass, jsx, etc. I've been developing web apps for the last few years and I really can't understand why all these are needed. They do not make my life easier as a developer, nor they make the code more readable. I've asked around why do we need, for example, React, and never gotten a straight answer.

cloogshicer 4y ago
How do you keep changes between the DOM and JS in sync without a framework? This is, from my understanding, the main value they provide.
- distcs 4y ago
  By adding event listeners to the DOM elements that may receive updates? I don't see why you _have to_ use a framework for that. Have people forgotten to write simple code using basic JavaScript?

jibbit 4y ago

wait.. Tailwind is a big CSS file?

pancrufty 4y ago
Tailwind is a too-big CSS file. If you want to use Tailwind, you must use a builder. This guy is clueless. wget https://cdnjs.cloudflare.com/ajax/libs/tailwindcss/2.2.19/tailwind.min.css HTTP request sent, awaiting response... 200 OK Length: unspecified [text/css] Saving to: ‘tailwind.min.css’ tailwind.min.css [ <=> ] 2.80M 321KB/s in 10s 2023-02-17 18:44:58 (286 KB/s) - ‘tailwind.min.css’ saved [2934019] In short: 2.8 megabytes, 10 seconds for the download. From the post: > but Tailwind 3 doesn’t seem to be available as a big CSS file at all anymore […] so I’m going to keep using Tailwind 2 for now Gee I wonder why. The length people go to make internet worse for everyone…
tbran 4y ago
Tachyons is a similar utility class framework, and a lot smaller at somewhere under 20kb, IIRC. https://tachyons.io/ https://tachyons.io/

nargella 4y ago

I resonate with this topic. Checking your own repos on a new computer is one thing… inheriting someone else’s project and running it on your machine in the node ecosystem is very rough. Anyways, I made a slightly more advanced buildless vue project here: https://github.com/kyleparisi/buildless-vuejs https://github.com/kyleparisi/buildless-vuejs It has the advantage of using .vue files which I enjoy. Oh and guess what… it has code splitting because you have to define what components the page needs ;).

Joeri 4y ago

It is really great to finally see no build web development gaining traction. Ever since the death of IE there has been an opportunity for dramatic simplification of the web dev stack that is unserved by the major frameworks. I did a talk about the topic of no build web apps recently. The slides are here for anyone interested: https://1drv.ms/p/s!ArEoTVF2ayv3lJg4oECZk2h5eN3I3Q https://1drv.ms/p/s!ArEoTVF2ayv3lJg4oECZk2h5eN3I3Q In preparation for that talk I’ve also adapted create react app’s default project into a no build template, including a variant with routing. That can be found in github: https://github.com/jsebrech/create-react-app-zero https://github.com/jsebrech/create-react-app-zero

shantnutiwari 4y ago

>I’m not totally sure why some libraries don’t provide a no-build-system version Yeah, Ive wondered that as well. Whenever I see I have to setup a complicated build system just to run a simple hello world example, I just go yuck and stop

kentbrew 4y ago

No build system was ever used in the making of Pinterest's widgets: https://github.com/pinterest/widgets https://github.com/pinterest/widgets

adaml2017 4y ago

Just use Vue. It's perfect for this use case, has a ton of help online if you need and plenty of paths to take if you want to upgrade your project in any direction. Seriously way reinvent the wheel here?

lurluberlu 4y ago

I use : - jquery - vanilla JS - Vue

iudqnolq 4y ago

I wonder if pinning dependency versions using something like asdf's .tool-versions would help. Then you don't have to worry about node upgrades. Even simpler, you could check the esbuild binary into git.