Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing JavaScript without a build system

jvns.ca

Post reply on HN
Print view View original

181–187 of 187 posts

Re: Writing JavaScript without a build system

#181

Post by TheRealPomax »

iamcreasy wrote: post #172
TheRealPomax wrote: post #63

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.

Is JS import similar to Python import?

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)

Re: Writing JavaScript without a build system

#182

Post by iamcreasy »

TheRealPomax wrote: post #181
iamcreasy wrote: post #172

Earlier quoted context omitted.

Is JS import similar to Python import?

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)

That partly answers my question. Thank you.

Re: Writing JavaScript without a build system

#184

Post by cxr »

theteapot wrote: post #128
spankalee wrote: post #35

Earlier quoted context omitted.

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.

Firefox was built with web components? Whaaaat?

The precursor to Web Components was XBL (NB: only ever implemented in Gecko), which was used extensively in the Firefox UI. (The Firefox product consists of literally hundreds of thousands of lines of JS powering the app UI—and many of its background components.) Gecko was doing Electron-style apps before Electron (or Chrome and JITted JS engines) ever existed.

Re: Writing JavaScript without a build system

#185

Post by cxr »

jamesgeck0 wrote: post #79

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 runti…

> 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.

Re: Writing JavaScript without a build system

#187

Post by jamesgeck0 »

cxr wrote: post #185
jamesgeck0 wrote: post #79

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 runti…

> 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…

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.

Post reply on HN