6 ms·

Enhance: a web standards-based HTML framework

132 points by bpierre 4y ago

swyx 4y ago
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. also was discussed on the latest syntaxfm https://syntax.fm/show/515/wtf-is-enhance-framework 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)
djbusby 4y ago
Wild to see file based routing come back, it was cool in 2002, then it was lame in 2012 and now it's cool again.
- juunpp 4y ago
  Just like pizza, there is one for every season.
- deleted 4y ago
  [deleted]
- smt88 4y ago
  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).
hilyen 4y ago
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.
- pdimitar 4y ago
  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.
lemper 4y ago
so, this is php+apache's incarnation in js, yes?
diceduckmonk 4y ago
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.
- Scarbutt 4y ago
  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. How do you plan to add JS to your Go web app?
  - diceduckmonk 4y ago
    > How do you plan to add JS to your Go web app? This is what I mean by Node.js being a hammer and everything looks like a nail. You don’t need Node.js to write JavaScript.
    - nawgz 4y ago
      > You don’t need Node.js to write JavaScript Yes, but you generally do need NodeJS to access NPM packages, which will provide a ton of JavaScript functionality for free. To the user who posed this question, I'm sure what they meant could be more charitably read as: "How do you plan to access the thriving JS / NPM web ecosystem from another language ecosystem entirely?" You've certainly listed some upsides to Go, but then your response to someone requesting a more honest analysis of the downsides is "Node.js devs are idiots". Hm.
      - diceduckmonk 4y ago
        I didn't say Node.js devs are idiots. My argument is that Node.js devs only knows Node.js and sees everything as a nail. You are projecting that that equates to idiocacy, and I won't argue. > "How do you plan to access the thriving JS / NPM web ecosystem from another language ecosystem entirely?" For our project, a search engine with interactive filtering capabilities, we don't plan or need to. With SSR, most logic is already handled by the server. This is a CRUD app. The set of libraries available in NPM that we might be interested would be a handful to zero. If it's that critical, we can just add a script tag. If it's a useful abstraction, it should be available on CDN. If it's not, and it's not succumbing to dependency hell, we can just copy and paste from NPM or Github. The JavaScript aspect is to add interactivity, and that's available thru DOM APIs and VanillaJS. NPM is besides the point. I exit here because you're going in a circle presuming that it's not feasible to build web applications without Node.js' "thriving" ecosystem. Amazon, Google, and so many other apps precede Node.js. I shipped JavaScript-enriched web applications at a few of those companies without having to use NPM as the package manager. Here is one of the most powerful text editors for the web (I've load tested that it can handle 80million+ line buffers, whereas VSCode edges out at <5million natively): https://github.com/ajaxorg/ace https://github.com/ajaxorg/ace. It's a pretty complex JavaScript application but you can develop without ever needing to "build". They use NPM to run tests and some devtools like Eslint, but we've still managed to minification/bundling in Go. I'm building a JavaScript-based text editor, too. Taking inspiration from Ace.js, it uses Makefile to "build". You can just run a static file server such as Python SimpleHTTPServer to host all the files in the directory. I still have and componentized HTML/CSS that are lazy-loaded, separated JS files, thanks to <500 bytes VanillaJS runtime based on HTMX. I do reach for libraries. For that, I look to https://js1k.com/ https://js1k.com/ for inspiration. The libraries there have zero-dependencies. Their source code all fit in screen and I can just copy the relevant bits. This is very similar to pulling in dependencies in Go in that it's humanly possible to do a supply chain security audit, unlike the nature of NPM packages. Currently the text editor with handwritten VanillaJS + copy-pasted libraries can handle 120+ million line buffers. Serious apps and businesses can be built without NPM. Inferring from HackerNews' JavaScript source, and the fact that it's written in Lisp, I doubt HN uses NPM. This doesn't stop HackerNews from being useful and valuable.
deleted 4y ago
[deleted]
Evidlo 4y ago
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.
- Semaphor 4y ago
  Frames work for that, but are obviously deprecated. Slightly more server dependent, but you could use SSIs [0] for that. [0]: https://en.wikipedia.org/wiki/Server_Side_Includes https://en.wikipedia.org/wiki/Server_Side_Includes
  - Evidlo 4y ago
    The problem is that frames live in a separate DOM, so content inside them doesn't flow/resize with the page.
- _han 4y ago
  This is actually part of HTML, but the API is a bit clumsy: https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_templates_and_slots https://developer.mozilla.org/en-US/docs/Web/Web_Components/...
  - Evidlo 4y ago
    If we're allowing Javascript in the picture, isn't this something that's always been possible?
- tannhaeuser 4y ago
  > 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. [1]: http://sgmljs.net/docs/templating.html http://sgmljs.net/docs/templating.html
int_19h 4y ago
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".
config_yml 4y ago
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?
p4bl0 4y ago
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 :).
simonhamp 4y ago
If we're just returning HTML, why the need for the boilerplate in that .mjs file? 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 4y ago
  Having a different way of doing things for static HTML doesn’t seem simpler than just writing a JS function with no arguments. I suppose it’s a matter of taste.
  - pdimitar 4y ago
    "Just writing a JS function". You continue not getting it. That's an unnecessary overhead. Strictly speaking, you don't need it. If you can get away with not including it then you absolutely should skip it. You guys can take some lessons from the so called static site generators. They have the right idea. Also Svelte which kind of does something very similar (although it does compile things to more vanilla JS which I like because less frameworks and inclusions).
eterps 4y ago
So this is all SSR right? Where does persistence/database fit into this concept?

132 points by bpierre 4y ago

swyx 4y ago

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. also was discussed on the latest syntaxfm https://syntax.fm/show/515/wtf-is-enhance-framework 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)

djbusby 4y ago

Wild to see file based routing come back, it was cool in 2002, then it was lame in 2012 and now it's cool again.

juunpp 4y ago
Just like pizza, there is one for every season.
deleted 4y ago
[deleted]
smt88 4y ago
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).

hilyen 4y ago

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.

pdimitar 4y ago
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.

lemper 4y ago

so, this is php+apache's incarnation in js, yes?

diceduckmonk 4y ago

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.

Scarbutt 4y ago
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. How do you plan to add JS to your Go web app?
- diceduckmonk 4y ago
  > How do you plan to add JS to your Go web app? This is what I mean by Node.js being a hammer and everything looks like a nail. You don’t need Node.js to write JavaScript.
  - nawgz 4y ago
    > You don’t need Node.js to write JavaScript Yes, but you generally do need NodeJS to access NPM packages, which will provide a ton of JavaScript functionality for free. To the user who posed this question, I'm sure what they meant could be more charitably read as: "How do you plan to access the thriving JS / NPM web ecosystem from another language ecosystem entirely?" You've certainly listed some upsides to Go, but then your response to someone requesting a more honest analysis of the downsides is "Node.js devs are idiots". Hm.
    - diceduckmonk 4y ago
      I didn't say Node.js devs are idiots. My argument is that Node.js devs only knows Node.js and sees everything as a nail. You are projecting that that equates to idiocacy, and I won't argue. > "How do you plan to access the thriving JS / NPM web ecosystem from another language ecosystem entirely?" For our project, a search engine with interactive filtering capabilities, we don't plan or need to. With SSR, most logic is already handled by the server. This is a CRUD app. The set of libraries available in NPM that we might be interested would be a handful to zero. If it's that critical, we can just add a script tag. If it's a useful abstraction, it should be available on CDN. If it's not, and it's not succumbing to dependency hell, we can just copy and paste from NPM or Github. The JavaScript aspect is to add interactivity, and that's available thru DOM APIs and VanillaJS. NPM is besides the point. I exit here because you're going in a circle presuming that it's not feasible to build web applications without Node.js' "thriving" ecosystem. Amazon, Google, and so many other apps precede Node.js. I shipped JavaScript-enriched web applications at a few of those companies without having to use NPM as the package manager. Here is one of the most powerful text editors for the web (I've load tested that it can handle 80million+ line buffers, whereas VSCode edges out at <5million natively): https://github.com/ajaxorg/ace https://github.com/ajaxorg/ace. It's a pretty complex JavaScript application but you can develop without ever needing to "build". They use NPM to run tests and some devtools like Eslint, but we've still managed to minification/bundling in Go. I'm building a JavaScript-based text editor, too. Taking inspiration from Ace.js, it uses Makefile to "build". You can just run a static file server such as Python SimpleHTTPServer to host all the files in the directory. I still have and componentized HTML/CSS that are lazy-loaded, separated JS files, thanks to <500 bytes VanillaJS runtime based on HTMX. I do reach for libraries. For that, I look to https://js1k.com/ https://js1k.com/ for inspiration. The libraries there have zero-dependencies. Their source code all fit in screen and I can just copy the relevant bits. This is very similar to pulling in dependencies in Go in that it's humanly possible to do a supply chain security audit, unlike the nature of NPM packages. Currently the text editor with handwritten VanillaJS + copy-pasted libraries can handle 120+ million line buffers. Serious apps and businesses can be built without NPM. Inferring from HackerNews' JavaScript source, and the fact that it's written in Lisp, I doubt HN uses NPM. This doesn't stop HackerNews from being useful and valuable.

deleted 4y ago

[deleted]

Evidlo 4y ago

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.

Semaphor 4y ago
Frames work for that, but are obviously deprecated. Slightly more server dependent, but you could use SSIs [0] for that. [0]: https://en.wikipedia.org/wiki/Server_Side_Includes https://en.wikipedia.org/wiki/Server_Side_Includes
- Evidlo 4y ago
  The problem is that frames live in a separate DOM, so content inside them doesn't flow/resize with the page.
_han 4y ago
This is actually part of HTML, but the API is a bit clumsy: https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_templates_and_slots https://developer.mozilla.org/en-US/docs/Web/Web_Components/...
- Evidlo 4y ago
  If we're allowing Javascript in the picture, isn't this something that's always been possible?
tannhaeuser 4y ago
> 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. [1]: http://sgmljs.net/docs/templating.html http://sgmljs.net/docs/templating.html

int_19h 4y ago

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

config_yml 4y ago

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?

p4bl0 4y ago

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 :).

simonhamp 4y ago

If we're just returning HTML, why the need for the boilerplate in that .mjs file? 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 4y ago
Having a different way of doing things for static HTML doesn’t seem simpler than just writing a JS function with no arguments. I suppose it’s a matter of taste.
- pdimitar 4y ago
  "Just writing a JS function". You continue not getting it. That's an unnecessary overhead. Strictly speaking, you don't need it. If you can get away with not including it then you absolutely should skip it. You guys can take some lessons from the so called static site generators. They have the right idea. Also Svelte which kind of does something very similar (although it does compile things to more vanilla JS which I like because less frameworks and inclusions).

eterps 4y ago

So this is all SSR right? Where does persistence/database fit into this concept?