[HN Gopher] Writing JavaScript without a build system
___________________________________________________________________
Writing JavaScript without a build system
Author : panic
Score : 43 points
Date : 2023-02-16 20:38 UTC (2 hours ago)
(HTM) web link (jvns.ca)
(TXT) w3m dump (jvns.ca)
| tarkin2 wrote:
| 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 wrote:
| JavaScript and CSS are to Stoicism as Typescript and SASS are
| to _____?
| loop22 wrote:
| Epicureanism?
| bernardv wrote:
| 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.
| bernardv wrote:
| Why is this opinion resulting in negative points? It speaks to
| the sentiment of the post. Happy to discuss the topic
| constructively.
| nonethewiser wrote:
| Huh... in Python I feel like the tooling is largely missing.
| zelphirkalt wrote:
| 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.
| mr_toad wrote:
| > Hopefully people keep dependencies of projects to a
| minimum
|
| This is not my experience of Python. Some of the tools I've
| installed via Homebrew have whole forests of dependencies.
| And don't get me started on all the different Python
| versions they require.
| agumonkey wrote:
| python is rarely streamed across HTTP, I believe that's the
| reason js is treeshaked.
| bernardv wrote:
| Precisely, because there is generally little need for it.
| irrational wrote:
| > 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.
| bitwize wrote:
| 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 wrote:
| 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.
| anderspitman wrote:
| 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
|
| [1]: https://www.jsdelivr.com/
| thex10 wrote:
| > I'd love more tips for no-build-system javascript
|
| Me too. And the tips already in here are pretty good!
| hdaz0017 wrote:
| looks like HN demand might have brought the site down :P
|
| This site can't be reached
| KrugerDunnings wrote:
| Deno solves all of this, too bad they don't support Solid.js.
| shaftoe444 wrote:
| Great she mentioned 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.
| dgb23 wrote:
| > 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/Guid...
|
| [1] https://github.com/bigskysoftware/htmx
|
| [2] https://github.com/lit/lit
|
| [3] https://github.com/lit/lit/tree/main/packages/lit-html
| kitsunesoba wrote:
| 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 wrote:
| 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
| duped wrote:
| 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.
| insin wrote:
| 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" } }
___________________________________________________________________
(page generated 2023-02-16 23:00 UTC)