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

Modern SPAs without bundlers, CDNs, or Node.js

kofi.sexy

Post reply on HN
Print view View original

131–140 of 170 posts

Re: Modern SPAs without bundlers, CDNs, or Node.js

#131

Post by test6554 »

I hadn't worked with unix/linux much so I had to ask ChatGPT what programming language/scripting language the second code block was written in.

"The code you provided is a shell script, commonly used in Unix-based operating systems. It uses the "set" command to set shell options, "-eo pipefail" means that the script will exit immediately if any command fails and that it will propagate any error code through a pipeline."

"The script then declares four local variables using the "local" command, which are used to construct the name and location of a file that will be downloaded using the "curl" command. The script creates a directory using "mkdir -p" and then downloads a file from a remote URL and saves it to a local file using the ">" operator."

Re: Modern SPAs without bundlers, CDNs, or Node.js

#132

Post by irrational »

ducharmdev wrote: post #86
rwalle wrote: post #78

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 last couple days there's been a lot of negativity towards the build step, but it's like everyone's forgotten the historical context that made the build step so popular to begin with. I'll give credit to the post about the fragility of certain build tools long-term in the npm ecosystem, but I don't think that's a reason to shrug off build tools period. We just need better, more stable ones (and I think we're start…

The historical context is web development became popular and developers from other disciplines moved over and brought their practices from those other areas of programming with them. We compile apps for the desktop, we should compile apps for the web too. They brought their complexity with them and forced it onto web development instead of stopping to consider if that was a good idea. Now we have developers who never knew how things were before transpilers were created and now think that this is how it has to be and that this is the best way.

Re: Modern SPAs without bundlers, CDNs, or Node.js

#133

Post by intrasight »

onion2k wrote: post #56

Import maps strike me as a huge win for making prototypes, or things where you control what exactly you're importing (eg from a private registry instead of NPM), but throwing out the bundler and more importantly the tree-shaking and minification steps of bundling, will result in a massive about of unused code being delivered to the user. You'll be relying on maintainers putting minified, unbloated assets in their pac…

> you'll be relying on maintainers ..

Our team (at Fortune 500 co) are pretty agile and forward looking (compared to corporate IT) but we're still not allowed to use anything from NPL-like repos without permission, and even then it has to get a code review and be pulled into our local repo. Personally, I agree with the CTO's belief that going from NPM directly to production is sort of insane.

Re: Modern SPAs without bundlers, CDNs, or Node.js

#134

Post by bastawhiz »

What does this have to do with SPAs? If you're doing this, you're precluded from using any framework of substance or templates. You can only use packages which are fully compatible with JDM. You're forced to use only systems which require you to model your DOM with function calls, or which parse your templates at runtime.

This is the sort of thing to do for lightweight projects that have a little bit of code. But SPAs are necessarily not that.

Re: Modern SPAs without bundlers, CDNs, or Node.js

#135

Post by techpression »

woudsma wrote: post #129

I usually create a folder containing src/index.js and public/index.html, then install react-scripts and add 'start' and 'build' scripts in my package.json. 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 Now you've got a hot-reloading d…

react-scripts is one of the most bloated pieces of front end horror I’ve ever worked with (and the amount of abstraction on top of it that aims to hide that fact only makes it worse), their webpack config reads as a silly joke. All you have to do is to eject and you see how bad it is.

Esbuild + a script in package.json and you’re done for modern front end. Maybe run a tailwind watcher.

Re: Modern SPAs without bundlers, CDNs, or Node.js

#136

Post by SadWebDeveloper »

> without bundlers, CDNs, or __NodeJS__

> When I need to add a dependency, I invoke download-package and then declare it in the import map. I like this setup because it feels like I’m only using the bits of the NodeJS ecosystem

Thats using node/npm but with extra steps...

Anyway kinda like the importmap thing, it would have been better if he didn't reference solidjs but thats life.

Re: Modern SPAs without bundlers, CDNs, or Node.js

#137

Post by fleddr »

MrJohz wrote: post #122
fleddr wrote: post #100

Earlier quoted context omitted.

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

I think the criticism is exactly of that ability to scale though. This setup is ineffective but manageable at the individual scale, but it's going to get more complicated as soon as anyone else is involved, or if the project lives longer than six months and needs to be updated, or if you wanted to add any dependency more complicated than a single file. The other side of it is it's not really clear what the author is…

My objection is that the author is quite clearly describing this as a bottom-up, small scale approach. Criticizing it as an inadequate approach for something much larger is unwarranted, as nowhere was the claim made that this scales up infinitely.

What is gained? No build step, as the article also clearly mentions. Your alternative approach goes against the goal of the author. Which is to not have a tool chain. "You can also do this by installing these 17 tools and 30 dependencies" is quite missing the point.

Re: Modern SPAs without bundlers, CDNs, or Node.js

#138

Post by gorjusborg »

kitsunesoba wrote: post #126
christophilus wrote: post #83

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

I think the difference lies is how pleasant the tooling/build process are. In the case of C, Go, C#, and other non-web languages, there are comparatively few gripes — the most common being “building takes a long time” with Rust and Swift for example, which is a fairly mild problem. The negative parts of the experience for these languages more often than not get fixed. With JS, it seems like many of the negatives are…

> I think the difference lies is how pleasant the tooling/build process are.

> With JS, it seems like many of the negatives are much more sticky and refuse to go away. Not sure why.

Spot on. I think there is a quality/cultural problem around the javascript ecosystem, but I'm also not sure why it persists. If I had to hazard a guess, I suspect that it has to do with what javascript programmers are usually trying to build. Those things are mostly visual, and the audience cannot see the quality or lack thereof easily, and outputs do not often live long. These incentives steer people to create fast and not worry so much about the soundness, sustainability, or longevity of their solutions.

I made a comment to a colleague recently that javascript tooling is a 'labyrinth of complexity'. That is my main gripe with all of the 'stuff' that comes with the front end. It all feels overcomplicated and thrown together.

Re: Modern SPAs without bundlers, CDNs, or Node.js

#139

Post by fleddr »

kitsunesoba wrote: post #120
fleddr wrote: post #100

Earlier quoted context omitted.

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

> 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 would say even many moderately complex sites/apps have no need for [shiny new feature X]. These days new JS features tend more towards nice-to-have than they do essential. Back in the days when jQuery was ubiquitous it was a different s…

Agree, Babel is bullshit in most cases these days. It's for people wanting to use some syntactic sugar that they just learned about 3 days ago.

Re: Modern SPAs without bundlers, CDNs, or Node.js

#140

Post by mmcnl »

dgb23 wrote: post #60
LordHeini wrote: post #31

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

Imo being "smart" like this is reinventing the wheel and doesn't give you any productivity gains.
Post reply on HN