saw Brian launch this at Cascadia JS recently, a very interesting "HTML first" approach. feel like the zeitgeist has swung really really hard towards (lasting) web standards so this is the natural culmination of that trend and maybe is the metaframework that really makes web components go mainstream.
Why bother with the dependency hell of JavaScript and Node.js if you’re not forced to go the SPA route? Heck, even Deno would have been a more compelling platform.
If all this is is composing plain ol’ HTML, which are just strings, any language will do. We have file based routing in Go in less than 10 lines of code connecting filesystem calls to Go’s template package. We have live reload with Air, too, and the builds times are under a second. Another nice thing with go is Filesystem embedding, so we build the HTML strings straight into the binary and deploy the binary as is.
Well, this isn’t just server side HTML includes, so your commentary seems like a rambling about your favorite language.
It’s a framework that lets you write JS functions that are used to render HTML on the server but also run on the client for progressive enhancement which is what your Go pitch does not do.
React/nodejs is nice if you do SSR for everything too since you can use some hydration to improve the UX and write all your view code (server and browser) in a single place with the same language.
Nodejs is a performant runtime and React is not only for creating SPAs.
> Why bother with the dependency hell of JavaScript and Node.js if you’re not forced to go the SPA route?
You don't need to be building an SPA in order to want to have some client-side javascript. And you may want to use some third-party libraries for your client-side javascript. Npm is a decent distribution channel / dependency manager for that purpose.
Modern static generators have been using file-based routing the entire time. I recently built something with SvelteKit, and the output was HTML and CSS (no JS emitted because none was needed on the client side).
Given the track record on stability (or rather lack thereof) in the ecosystem around Node.js, it feels like a strange base on which to build "a dependable foundation for ... future-proof web applications".
Why couldn't basic templating or includes have been built in HTML natively? It's stupid that you have to use a static generator, client-side rendering, or dynamic content generation just to get a website with consistent headers/footers on all pages.
I dream of being able to author web content with just a text editor.
> Why couldn't basic templating or includes have been built into HTML natively?
Because HTML started life as an SGML application/vocabulary, and with SGML having entities (and link process declarations/stylesheets) for exactly these purposes, there was no need to invent HTML ad-hoc mechanisms. SGML templating based on SGML LINK works in a push (event-driven) style, with fully type-checked and HTML-aware semantics, quite different from your typical pull style embedding of whole programming languages that spit out unescaped strings ([1]).
Of course, browsers never came around to implement even basic SGML features such as entities (except for character entity references), and by 1994 or so, JavaScript was already introduced, making any HTML evolution inessential by introducing a Turing-complete language into the mix.
A good way to have file-system based routing is to actually use files. And the inclusion of common parts can easily be done on the server-side or locally on the development machine using PHP's include directive.
Using PHP as a template language, it is trivial to generate static HTML content by calling PHP from the command line on your files (this is easily automated to scale for many many pages website) to be able to host the result everywhere even on hostings that do not have PHP :).
This has some traits of astro.build, but the single file component is just a javascript function returning a bag of html. This is kind of nice since you don't need to know any new concepts.
Maybe it could be useful for the project to position itself against these other frameworks more directly?
I look forward to new frameworks being easier to use and helpful. These new Frontend frameworks, React, Vue, Svelte, just made things 100 times more complicated. Sure they're useful for SPA's and certain use cases, but the majority of the web doesn't need to be over-engineered to the nth degree. I laughed hysterically when I learned Google wouldn't spider content properly on SPAs. Then laughed again when they had to build another app, such as Next, or Nuxt, just to do so.
It helps to be a bit more nuanced. I hate JS' guts, mind, you but even I know that Svelte makes things easier and more predictable.
That almost everything on the frontend is over-engineered, I don't think any reasonable programmer would disagree with. It's true.
But since people are stuck with HTML, CSS and JS they try hard to make it more manageable. Pieces of tech like HTMX and Svelte improve the status quo. Not everything is bad in there.
...That still doesn't mean I want to do frontend work though, heh.
[+] [-] swyx|3 years ago|reply
also was discussed on the latest syntaxfm https://syntax.fm/show/515/wtf-is-enhance-framework
(disclosure, am tiny angel investor in Begin, but Enhance is really kind of a different project)
[+] [-] diceduckmonk|3 years ago|reply
If all this is is composing plain ol’ HTML, which are just strings, any language will do. We have file based routing in Go in less than 10 lines of code connecting filesystem calls to Go’s template package. We have live reload with Air, too, and the builds times are under a second. Another nice thing with go is Filesystem embedding, so we build the HTML strings straight into the binary and deploy the binary as is.
[+] [-] hombre_fatal|3 years ago|reply
It’s a framework that lets you write JS functions that are used to render HTML on the server but also run on the client for progressive enhancement which is what your Go pitch does not do.
[+] [-] pabs3|3 years ago|reply
That way lies XSS attacks, might be better to have a DOM of some kind in your language.
[+] [-] Scarbutt|3 years ago|reply
Nodejs is a performant runtime and React is not only for creating SPAs.
How do you plan to add JS to your Go web app?
[+] [-] azangru|3 years ago|reply
You don't need to be building an SPA in order to want to have some client-side javascript. And you may want to use some third-party libraries for your client-side javascript. Npm is a decent distribution channel / dependency manager for that purpose.
[+] [-] djbusby|3 years ago|reply
[+] [-] smt88|3 years ago|reply
[+] [-] juunpp|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] int_19h|3 years ago|reply
[+] [-] simonhamp|3 years ago|reply
Why not have your framework find standard .html files in a well-known location and wrap them in the boilerplate for me?
That way, I don't even need to think of them as something else - they are just HTML - and the magic is happening with me even seeing the wand
[+] [-] hombre_fatal|3 years ago|reply
I suppose it’s a matter of taste.
[+] [-] Evidlo|3 years ago|reply
I dream of being able to author web content with just a text editor.
[+] [-] _han|3 years ago|reply
[+] [-] tannhaeuser|3 years ago|reply
Because HTML started life as an SGML application/vocabulary, and with SGML having entities (and link process declarations/stylesheets) for exactly these purposes, there was no need to invent HTML ad-hoc mechanisms. SGML templating based on SGML LINK works in a push (event-driven) style, with fully type-checked and HTML-aware semantics, quite different from your typical pull style embedding of whole programming languages that spit out unescaped strings ([1]).
Of course, browsers never came around to implement even basic SGML features such as entities (except for character entity references), and by 1994 or so, JavaScript was already introduced, making any HTML evolution inessential by introducing a Turing-complete language into the mix.
[1]: http://sgmljs.net/docs/templating.html
[+] [-] Semaphor|3 years ago|reply
[0]: https://en.wikipedia.org/wiki/Server_Side_Includes
[+] [-] p4bl0|3 years ago|reply
Using PHP as a template language, it is trivial to generate static HTML content by calling PHP from the command line on your files (this is easily automated to scale for many many pages website) to be able to host the result everywhere even on hostings that do not have PHP :).
[+] [-] config_yml|3 years ago|reply
Maybe it could be useful for the project to position itself against these other frameworks more directly?
[+] [-] lemper|3 years ago|reply
[+] [-] eterps|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] hilyen|3 years ago|reply
[+] [-] pdimitar|3 years ago|reply
That almost everything on the frontend is over-engineered, I don't think any reasonable programmer would disagree with. It's true.
But since people are stuck with HTML, CSS and JS they try hard to make it more manageable. Pieces of tech like HTMX and Svelte improve the status quo. Not everything is bad in there.
...That still doesn't mean I want to do frontend work though, heh.