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…
Man I cannot wait for bundlers and all of that garbage to go the way of the dodo bird.
Modern SPAs without bundlers, CDNs, or Node.js
91–100 of 170 posts
Re: Modern SPAs without bundlers, CDNs, or Node.js
#92To go quite a bit off topic. The author says that he starts with a single html file and splits it or incrementally adds stuff when needed. That course of action has proven to be a really bad idea on every non trivial web project I worked on. Mostly for teamwork and maintainability reasons. E.g there is no clear project structure, the next dev will not understand stuff and do things differently. And welcome to the cha…
You are optimizing for entirely different use cases. There are a whole bunch of devs who work alone or in (very) small teams. For this type of work it’s really more of a hindrance to have an imposed structure and tooling. We want to get to your goals as efficiently as possible. Minimal abstractions, guidelines, tooling, indirection, magic, surprises and general overhead are in order. We don’t want to struggle with qu…
And you still need to reimplement a bunch of stuff if you don't use oss packages. And the next maintainer will curse your family for generations because of your own custom framework.
Re: Modern SPAs without bundlers, CDNs, or Node.js
#93Doesn't work in Safari!
Re: Modern SPAs without bundlers, CDNs, or Node.js
#94Sigh... 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…
So, in your opinion how do things improve then? People see how painful some tools are and so they try to improve things. Some times it works, some times it doesn't.
Re: Modern SPAs without bundlers, CDNs, or Node.js
#95Sigh... 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 think you're projecting your thoughts about some other thing on to this article... this one is a "this is how I like to do things and I found a new thing that helps do it that way" post.
The tone of the article is really not like what you're suggesting.
Re: Modern SPAs without bundlers, CDNs, or Node.js
#96Sigh... 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…
Re: Modern SPAs without bundlers, CDNs, or Node.js
#97Earlier quoted context omitted.
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…
Comparing building a golang project with "building" a frontend project is pretty laughable. Frontend "builds" are atrocious.
Vite and Turbopack are way easier to use than Webpack, and faster than the next best thing, Parcel.
npm supports lockfiles. Yarn goes further in that you no longer need a million files in node_modules; or pnpm uses hard links to prevent duplication.
That said, typechecking Typescript is unfortunately slow. esbuild (as used by Vite) can strip out type signatures quickly, but can't check them. Rescript is very fast, but is a very different language than TypeScript or JavaScript, namely ML with braces.
Re: Modern SPAs without bundlers, CDNs, or Node.js
#98If you use normal includes instead of imports, and put an object (or better a closure) on the top as a namespace, your SPA will work with any browsers, and you don't force your users to throw out their phones and laptops every 2-5 years.
could you make a code example?
just how you include (or included in the past) jquery or mathjax. I manage my namespaces like function Zebras() {
let l; //local
let e; //has setter and getter
gete = () => {return e}
sete = (x) => {e = x}
function lfunc() {console.log("local function")}
function efunc() {console.log("exported function")}
// exports :
this.efunc = efunc
this.gete = gete
this.sete = sete
}
and import it
zr = new Zebras()
zr.sete(4)
console.log( zr.gete() ) // 4
zr.efunc()
// zr.lfunc()
You can export objects or functions trivially. I don't think you can expose primitives this way.I think this method is working since ~20 years, and will work 20 years from now, when you can't even get your bundlers to run. But then if you have to change it frequently, probably ES modules are easier to automate, test, and handle with bundlers.
Re: Modern SPAs without bundlers, CDNs, or Node.js
#99What’s the benefit of the custom download-package script over npm install? Why would you want to roll a custom solution here?
NPM will automatically install dependencies and run post-install scripts. Those are normally a convenience, but I can understand why someone would want to skip that.
Re: Modern SPAs without bundlers, CDNs, or Node.js
#100Sigh... 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…
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 its advantages for large projects with many developers but it's in no way essential. Most web projects don't use Typescript and the very idea that it's a must-have only a few years old and quite opinionated.
Likewise, Babel isn't important either. You don't need to use some futuristic JS feature on your simple project, you can just stick to well supported ones, thus not needing Babel.
"I have been doing web development as a hobby and professionally for well over a decade and have seen too much of this."
I've been doing web development since 1996, so that makes for 27 years, should such obnoxious statement make anyone's opinion more important. If you need to piss on the idea of somebody scaling a web architecture proportionally to actual needs, you should reconsider who is the "smart" one.