Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
turbo
The speed of a single-page web application without having to write any JavaScript (by hotwired)
-
practical-aspnetcore
Practical samples of ASP.NET Core 8.0, 7.0, 6.0, 5.0, 3.1, 2.2, and 2.1,projects you can use. Readme contains explanations on all projects.
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
I wouldnt say an iframe and this are in any way shape or form comparable. this is a "full-fledged" website.
> except that if node.land or crux.land go down, you've lost your reproducibility.
Dependencies are cached. This is no different from if npm would go down.
> The only semi-interesting thing here is that this demo pulls dependencies from 3rd party registries via HTTP without an explicit install step
Given that this seems interesting to you, it seems you haven't heard of Deno (https://deno.land). It is not related to node in terms of environment, its a new completely separate runtime.
In regards to your node example, this is fairly different:
The truth I learned building my own SSR JavaScript framework is that it's not that complicated, it's just made complicated.
1. Get some data from a database/source.
2. Pass that data to a template/component.
3. Convert that template/component to HTML (using the given framework's version of renderToHTML()).
4. Return the HTML to your HTTP request.
For example, here's the SSR for my framework: https://github.com/cheatcode/joystick/blob/development/node/.... It blew my mind when I wrote it because I was under the impression it would be more difficult.
Not sure if matter of preference or matter of right tool for the job and industry agreed best practices regarding simple vs complex. In the sense that you may prefer the round peg, but it doesn't fit the square hole.
I've been doing JavaScript myself for about 15 year, unfamiliar with the UNIX philosophy (to be doubted as any doctrine). Started doing web development using plain HTML the "old school" way, I personally dare to say the _normal_ way.
Before the rise of SPAs I very much agreed with the idea of progressive enhancement which is coming again into attention with the likes of https://turbo.hotwired.dev/.
While doing SPAs I always felt that stuff constantly didn't fit, that we were constantly using unfit tech, doing hacks for benefits of using a single (unfit?) language both on the server and the client, partial loads (faster loading times) and having a single codebase for all OSes. Stuff felt hacky most of the times and we were hiding those complex hacks under what _seemed_ as elegant and simple abstractions. But I believe most experienced JavaScript developers agree that the elegance and simplicity is mostly on the surface. I constantly felt dissatisfied with the code I wrote. I refuse to go on a full rant regarding SPAs and JavaScript but that's the gist of it.
While configuring my dev environment I stumbled up the https://suckless.org/ guys. Their code embodies the UNIX philosophy well although some people, including me, might say that some stuff is too simple. Simplicity for the sake of simplicity is not a good idea (nothing for the sake of anything is a good idea to be honest) but rather as a consequence of you understanding of what's not really needed.
While investigating more more the UNIX world, discovering OpenBSD and using it as a daily driver things started to fit and make sense.
Now, regarding how mkws fits generating static sites, it mimics building a small C project except the Makefile is replaced by a shell script, so all the principles fit and are well established. pp is the compiler, .upphtml files are the sources, html files are the output binaries. Everything integrates and fits well. I feel satisfied about how everything works.
Code is small and simple, abstractions are kept to a minimum. I, as a single person, am able to investigate, understand and change every part of the generating process. Can't say the same thing about a JavaScript static site generator, you don't really need the v8 engine to generate a few HTML files, that's complex, most of use agree simple is relatively good, complex relatively bad as an industry best practice.
Regarding SPAs, I believe they were a quick solution until we properly solve the problems they solve via progressive enhancement.
ASP.NET Core is pretty minimal in ceremony nowadays. You can easily do single file web development.
https://github.com/dodyg/practical-aspnetcore/blob/net6.0/pr...
and I was a little surprised how much convenience there was baked in. That someone created an issue[1] makes me think I am not just not looking good enough and it's actually tedious.
[1]: https://github.com/denoland/deno_std/issues/1884
TiddlyWiki is a whole wiki in a single file, been around a while, great system:
https://tiddlywiki.com/
PHP (or, in my case these days, Deno serving templates, typically nunjucks) that have https://htmx.org/ in them for interactivity gets you productive, quickly, for a lot of the tasks I need to do.
That said, React makes building even more interactive, complicated things simple, and is easy to hire for, so thats what we use at work.
I do think the world is still ripe for a PHP-like language. The template-style webserver-aware way of doing things, with modern features. Maybe one day.