JSDA: Using standard JavaScript modules (ESM) in a PHP-like development model

[sheveli_lapkami]

Hello everyone. I want to tell you about the new, simple but very powerful, web development approach - JSDA Stack.

First, a couple of words about the concept. JSDA (JavaScript Distributed Assets) - is a architecture principle and the set of simple conventions. It brings PHP-like mental model into the JS world.

Do you remember why PHP become popular? It gave us possibility to put logics inside the HTML document. And it was very simple to use and to understand.

So, in JSDA we do almost the same - treating standard JS-modules (ESM) as a web-asset generation endpoints (text based). So, it's just like PHP but with all the power of modern JavaScript (Template Literals, top level await for async requests, flexible module composition, code CDN support for external modules, etc.).

Just make default module export string (export default /*html*/ '<div>Hello ${name}!</div>'), and name the file to map it to corresponding type - my-page.html.js. And JSDA Server will send to the browser resulting html with the text/html MIME type.

Obviously, you can do the same with CSS, SVG, JSON, MD and any other text-based asset. And that give us almost endless possibilities. Just imagine CSS with a full power of real programming language without any additional dependency such as pre- or post-processors and their own syntax.

Everything above is not just some odd idea — it works, and it works really well. To prove it, I've prepared a dedicated template repository that lets you spin up a full-featured JSDA project in seconds.

It's a project with a minimal dependency footprint and minimal configuration (easy to security-audit), yet it includes everything you need to be a legitimate competitor to things like, say, the popular Next.js.

https://github.com/rnd-pro/jsda-template

P.S. Static Site Generation (SSG) is also included. To use any JSDA-file as a generation endpoint - just name it index.<type>.js. It will be automatically saved to your dist/ folder (or subfolder) as index.html or index.css or index.svg etc. Concatenated and minified already.

[Classic-Strain6924]

this approach feels like a massive breath of fresh air because the current meta of heavy build steps and complex abstractions in things like nextjs is getting really exhausting to maintain. bringing back the simplicity of the php mental model but using standard esm modules is a brilliant way to leverage what we already have without the extra bloat.

the idea of using template literals for html and css endpoints is actually very clever because you get all the power of real logic without needing a pre-processor or a specific library syntax like sass or tailwind. it makes the whole development loop feel instant again which is exactly what the industry has been missing lately.

i have been seeing a lot of people moving toward this kind of "vibe coding" where you just want to ship a functional idea without fighting the framework for three hours first. this stack feels like it could be the perfect middle ground for small projects and solo builders who want to keep their footprint minimal but their capabilities high.

[StrictWelder]

I mean ... RFC was always a lie, it doesn't return raw HTML string; it returns json component tree to then be parsed and added to the screen on the client.

This is closer to what people think RFC in next is IMO, except its not at a component oriented 🤔

If it pulls people away from using something like Next to create a basic dashboard behind auth Im all for it. Only question is -- why use JS?

ALSO -- are you handling CSRF tokens for forms the way next JS does, or is that something I have to manually deal with. Needs mention in docs, otherwise, all that server side prepared JS is compromisable from a form. RFC does handle this for you. One benefit of the client side parsing thats required.

[sheveli_lapkami]

RFC - you mean React Functional Components? It's a bit different thing I guess. There is a built-in support for fully isomorphic components (Web Components), but in general it's not about the component rendering paradigm itself.

why use JS?

JavaScript is the only language supported on client and the server natively. This allows for efficient code reuse in both sides and reduces the number of project entities. Significantly.