I use Eleventy for nearly all of my static sites. Almost every project of mine has at least an 11ty internal docs site. I'm very happy that Eleventy has a home and Zach a job.
But my only thought on this is: Eleventy is an awesome name.
Agreed, it's not those, it's the fact that we went from JS being a little sprinkling of dynamism on a document to an entire build process with massive numbers of dependencies and browser shims. The web feels like a mistake as a platform...
Counterpoint: classes are a great way to bundle state and logic - which is exactly what UI components are - and components models should use classes more, not less.
React's "functional" components are simply poor approximations of classes. Instead of easy to read and reason about class fields, you put state in useState() function classes that are effectively named by their appearance order in source and who's current state you can't introspect with dev tools!
The component function mixes one-time setup (which should be a class constructor) with repeated render calls (which should be a method), so those of course have to be separated by putting the one-time work inside of a closure inside of the repeated should-have-been-a-callback function. Event listeners and other callbacks are another huge mess. Don't forget useMemo() or useCallback() (but which?).
It's actually quite mad.
And the differences between classical and prototypal inheritance basically don't even pop up under normal class usage in JS: just use class fields, don't mess with the prototype chain, and don't dynamically add or delete properties - all things that are how classical inheritance works - and things just work like you expect.
They're modeling reactivity, not classes. It's a well established pattern in functional programming
The one time setup mixed with repeated render calls is odd, but it's a design decision they made. It reduces boiler plate, though I don't necessarily agree with it because it is a leaky abstraction
It's a shame they don't seem to try to address the divide between CMS's and static sites.
Most WordPress sites could just be static, but WordPress has a nice editor interface, so they're not - unless you use a SSG plugin. Building that into the core workflow (which I believe Astro supports) and giving users a nice hosted editor that produces a static site would be welcome innovation.
I've been migrating a few Wordpress sites from Wordpress to Astro + Strapi recently, working in 'hybrid mode' so the entire site is static except for post previews in Strapi (only that one route is SSR).
Editing content in Strapi, once customized with CKEditor and such, is Wordpressy enough for the human Editors familiar with WP.
I don't even think the WordPress editor is very nice. It's completely separated from how the actual results look. There are CMSs which lets you edit directly in the web page exactly as it will look when published.
As do most productivity software, like MS Office, Photoshop, Apple's iWork, etc.
Imagine making a document in Word, and it looks completely different when published.
EmDash with some aggressive caching and SWR is effectively this, and we're getting closer to that every day. When the cost of maintaining the data part of the CMS is effectively free, you're basically working with a static site anyway.
I haven’t used Wordpress for a few years. But with WP Super Cache (1) we also always did pretty much that: On saving a post/page the static HTML would be written to a cache directory and be the default content served to visitors.
Depends what you would call that architecture then I guess!
I run my local theatre website by writing the posts in markdown, and then have some github actions which use Hugo to turn it in to a static site and then uploads the content to an S3 bucket. The site itself has dynamic content like within-website ticket buying from eventbrite and a contact form that sends email using an external service. It also calls in things like google analytics.
Does this still count as static? Personally I think so, Even though there are 'dynamic' elements.
IMO static refers more about how the content is served rather than saying that the content can’t be ‘dynamic’ as lots of Wordpress sites have static/non interactive content but still regenerate the html on each page load.
I love this, but I really wish it were structured as a "Hot or Not" type of round robin system rather than a bracket.
Some fonts are close enough that I don't know if I'd choose one over the other consistently, and I'd be curious to see a percentage score of how much I like a particular font.
Totally agreed -- there are so many different factors involved in each comparison, and I feel like I'm easily paying attention to different things on each comparison.
Unfortunately, I don't believe there's any established algorithm for how to repeatedly sample pairwise preferences to convert them into a strict ranking, which would ideally be with an active learning component to really drill down into the comparisons that are the closest. Would be a fascinating thing to try to develop, though.
I find this handy in Chrome occasionally. Just confirms that BeOS had the right windowing features all along.
Two more OS-level windowing features I'd like to see in browsers:
- OS X like Expose that shows a preview of all tabs for a window. That would help me find a tab visually.
- A command to override the meaning of fullscreen to take over the whole tab, rather than be truly fullscreen. That would let me use other window management features with maximum video size within the window.
I could've sworn firefox had an "all tabs" preview button that looked like 4 blocks in a grid, before the Australis era. Can't find any pictures/video footage of it in action however.
> Just confirms that BeOS had the right windowing features all along.
Which windowing features are you referring to? I recall with BeOS (and I assume Haiku) you could shift-click on the "yellow window tab" to move it along the top of windows, so you could have multiple windows stacked, but with their tabs visible on the top, but I don't recall a split-view.
- Windows like Snap Assist where you tile one browser tab to one half of the screen and then it shows a preview of all other tabs and you pick one to tile to the other half of the screen.
I did something a lot simpler than this to have some more control: I gave a Twilio number to the building manager for the door box, then had an app where I could give out codes to people. Valid codes responded with a "9" DTMF signal which opened the door, a "1" forwarded the call to my phone.
HTML simply can't represent the complex state of real apps. Moving state to HTML actually means keeping the state on the server and not representing it very well on the client.
That's an ok choice in some cases, but the web clearly moved on from that to be able to have richer interaction, and in a lot of cases, much easier development.
I'm sure you could find examples to prove me wrong here so I'm definitely not saying this is a hard line, but I've always found that if app state is too complex to represent in the UI or isn't needed in the UI at all, that's state that belongs on the back end rather than the frontend.
My usual go-to rule is that business logic belongs where the state lives - almost always on the back end for state of any real complexity.
With true web apps like Figma I consider those entirely different use cases. They're really building what amounts to a native app that leverage the web as a distribution platform, it has nothing to do with HTML at all really.
The point of Lit is not to compete with React itself, but to build interoperable web components. If your app (Hi Beaker!) is only using one library/framework, and will only ever one one in eternity, then interoperability might not be a big concern. But if you're building components for multiple teams, mixing components from multiple teams, or ever deal with migrations, then interoperability might be hugely important.
Even so, Lit is widely used to build very complex apps (Beaker, as you know, Photoshop, Reddit, Home Assistant, Microsoft App Store, SpaceX things, ...).
Property bindings are just as ergonomic as attributes with the .foo= syntax, and tag name declaration has rarely come up as a big friction point, especially with the declarative @customElement() decorator. The rest is indeed like a faster less proprietary React in many ways.
Kind of? Lit does add some of the types of patterns I'm talking about but they add a lot more as well. I always avoided it due to the heavy use of typescript decorators required to get a decent DX, the framework is pretty opinionated on your build system in my experience.
I also didn't often see Lit being used in a way that stuck to the idea that the DOM should be your state. That could very well be because most web devs are coming to it with a background in react or similar, but when I did see Lit used it often involved a heavy use of in-memory state tracked inside of components and never making it into the DOM.
Lit is not opinionated about your build system You can write Lit components in plain JS, going back to ES2015.
Our decorators aren't required - you can use the static properties block. If you think the DX is better with decorators... that's why we support them!
And we support TypeScript's "experimental" decorators and standard TC39 decorators, which are supported in TypeScript, Babel, esbuild, and recently SWC and probably more.
Regarding state: Lit makes it easier to write web components. How you architect those web components and where they store their state is up to you. You can stick to attributes and DOM if that's what you want. Some component sets out there make heavy use of data-only elements: something of a DSL in the DOM, like XML.
It just turns out that most developer and most apps have an easier time of presenting state in JS, since JS has much richer facilities for that.
Dont get me wrong, I'm a pretty big believer in interop, but in practice I've rarely run into a situation where I need to mix components from multiple frameworks. Especially because React is so dominant.
But my only thought on this is: Eleventy is an awesome name.
reply