121–130 of 170 posts
I mean, you can literally just download the files to a folder on your computer. It's not like it stops working just because it's not hosted on a javascript cdn
Sigh... Another post like this. Sure, it works well enough for the example shown in the article, but won't work well beyond this. Bundlers, package managers and other tools were created to address problems people saw in medium-large projects for websites with a lot of traffic. And as soon as the project has dozens of files and even just two or three external libraries, this becomes unmaintainable. Not to mention mini…
"Sure, it works well enough for the example shown in the article, but won't work well beyond this." Sigh...the entire bloody point of the author is to use this for light projects, to scale the sophistication of the setup gracefully. With very obvious benefits: easy to understand, not linked to any setup so it works forever, interoperable and transferable. Typescript isn't universally important for development. It has…
The other side of it is it's not really clear what the author is gaining here. They're still reliant on NPM package structures, and they're still pulling in third party dependencies. They're just doing it in an overly complicated way.
In contrast, this is what I'd do to get to the same point the author does in this example: (I'm going off the top of my head here, and I don't have a computer to check this, but it should just work.)
mkdir myproject/ && cd myproject/
npm init # although I think just doing echo '{}' > package.json is enough here
npm install -D vite
npm install solid-js
# write some actual code
$EDITOR index.html
npx vite
> Some frameworks have a hosted CDN option, but I’m similarly uncomfortable accepting that infrastructural dependency. Ideally, I’d just grab the framework files, import them from my JavaScript, and then carry on with my file:// URL. I mean, you can literally just download the files to a folder on your computer. It's not like it stops working just because it's not hosted on a javascript cdn
Sigh... Another post like this. Sure, it works well enough for the example shown in the article, but won't work well beyond this. Bundlers, package managers and other tools were created to address problems people saw in medium-large projects for websites with a lot of traffic. And as soon as the project has dozens of files and even just two or three external libraries, this becomes unmaintainable. Not to mention mini…
The author is pretty clear that their intention is to use this as a simple first step to creating an app without the hassles of bundlers, they don't seem to be advocating that one would create "medium-large" projects like this. The word "incremental" is mentioned in the first sentence. Nor does their message come across as "why don't people do this" to me. > Until recently though, I wasn’t sure how to make this step…
> Some frameworks have a hosted CDN option, but I’m similarly uncomfortable accepting that infrastructural dependency. Ideally, I’d just grab the framework files, import them from my JavaScript, and then carry on with my file:// URL. I mean, you can literally just download the files to a folder on your computer. It's not like it stops working just because it's not hosted on a javascript cdn
That's what I've been doing for decades, but in current browsers `import` doesn't work with file urls, and whatever you download will need that
Sigh... Another post like this. Sure, it works well enough for the example shown in the article, but won't work well beyond this. Bundlers, package managers and other tools were created to address problems people saw in medium-large projects for websites with a lot of traffic. And as soon as the project has dozens of files and even just two or three external libraries, this becomes unmaintainable. Not to mention mini…
I’ve been doing it professionally for 20 years, and I agree. Modern front end development with TypeScript, Vite, Preact, and even the much maligned npm are so much better than anything that preceded them for building complex front end applications. I like having a build step for code that I write. I build C, I build Go, I build C#. I don’t ship debug builds of those things. I don’t know why I’d want to forego all of…
With JS, it seems like many of the negatives are much more sticky and refuse to go away. Not sure why. Perhaps it’s related to how that ecosystem has a tendency towards cyclical reinvention of the upper layers while foundational/structural issues get considerably less attention, and so they get swept under the rug more often than they’re fixed, leading them to rear their heads every so often to remind everybody of their existence.
Sigh... Another post like this. Sure, it works well enough for the example shown in the article, but won't work well beyond this. Bundlers, package managers and other tools were created to address problems people saw in medium-large projects for websites with a lot of traffic. And as soon as the project has dozens of files and even just two or three external libraries, this becomes unmaintainable. Not to mention mini…
"Sure, it works well enough for the example shown in the article, but won't work well beyond this." Sigh...the entire bloody point of the author is to use this for light projects, to scale the sophistication of the setup gracefully. With very obvious benefits: easy to understand, not linked to any setup so it works forever, interoperable and transferable. Typescript isn't universally important for development. It has…
https://deno.land/manual@v1.30.3/basics/import_maps
Maybe add aleph too (which is similar to nextjs)
Deno won't require nearly as much tooling as nodejs, but it still has tooling for the cases you need it.
The problem with writing a shell script to fetch and download NPM packages is that it won't do so in parallel. I'm sure that's fine if you only depend on one or two packages, but dependency explosion is practically a feature of the NPM ecosystem, and that'll stretch the script runtime. Not to mention fetching packages that you already downloaded, and no compatibility with outside tooling like Dependabot for automatic…
A neat way to organize that mess is to just use docker for tools and use maybe a simple Makefile to call those tools. Build your docker container once, push it to a docker registry and use it many times. Also nice for CI/CD.
I did that for my website which is a simple static site that I generate with some bash scripts, pandoc, and other tools from markdown files. The scripts run in Docker. I don't use node.js for this but it doesn't matter. It's just another set of tools. The only tools I need on a laptop are docker and make to build this website.
The issue with npm is that it pretends that everything happens inside of npm/node.js. Just npm this or that. It's a package manager. It's a build tool. And it's a way to run tools that you install via the package manager. And then almost as an afterthought there are a few run-time dependencies that it minifies into your actual application as part of some convoluted bundling toolchain (typically installed via npm).
The actual size of those run-time dependencies is surprisingly small for most applications. And of course with modern web browsers and html 2 & 3, loading them as one blob of minified js is not necessarily even the best way to pull in dependencies anyway. You can load a lot of this stuff asynchronously these days.
mkdir -p myproject/{public,src} && cd myproject
touch src/index.js public/index.html
npm init -y && npm i -D react-scripts
# add to package.json scripts:
# "start": "react-scripts start",
# "build": "react-scripts build",
npm start
Hot reloading definitely saves me some extra RSI.
Sigh... Another post like this. Sure, it works well enough for the example shown in the article, but won't work well beyond this. Bundlers, package managers and other tools were created to address problems people saw in medium-large projects for websites with a lot of traffic. And as soon as the project has dozens of files and even just two or three external libraries, this becomes unmaintainable. Not to mention mini…