Yeah and this isn't exclusive to dev tools. Shit like that is why I run umatrix in strict mode with JS disabled by default.

Well, nice to have validation of my feeling that what passes for "developers" nowadays are clueless idiots far more often than it used to be.

although I’m a little bit skeptical about having to integrate additional extensions and workflows

Just to allay your fears, it's not a mishmash of random extensions and brittle workflows.

11ty was originally built in a more all-in-one box style, but it was kind of annoying to have 10+ templating languages to choose from (and all the dependencies that came along with them), when you only wanted one.

Every update, the author does two things:

1. Splits more functionality into first party plugins
2. Removes, or forks and takes over third party dependencies.

You can see that here: (data taken from here: https://www.11ty.dev/blog/dependency-watch/#full-history)

The first-party plugins are all compatible with each other and all use the same 11ty config with the same sensible defaults, and 11ty is built with all of the first-party plugins in mind.

You can add them all in if you still want the all-in-one-box approach, but this way lets your environments be smaller.

It's basically pre-computed tree shaking.

There's also a security argument for it. By splitting everything apart, you isolate security issues. If one of the random 10+ templating languages got a security issue (e.g. supply-chain attack, redos, misglobbing, etc...), it will only affect the projects that decided to use that templating language.

Good article but whoever created these examples must have a plinko board containing ['arrow function', 'function', 'inline arrow function', 'inline function'] to decide when to use each. Scope be damned! Also, awaiting whenever! Wooo

I totally get the focus on avoiding "layers", it's something I'm very mindful of too.

Thank you for the insight, I'll have a closer look into it, although I'm a little bit skeptical about having to integrate additional extensions and workflows, which is it's own bag of worms for maintainability, longevity, and complexity in general.

I haven't used Hugo.

I went with 11ty a few years ago because I wanted to stay as close to the actual web standards as possible (so, HTML/CSS/JS).

The main reason why is that every additional abstraction layer and every invocation of "magic", is just extra hidden complexity which makes things harder to debug, extend, and maintain.

Having a SSG in go/python/rust would have been an extra layer.

The "maintain" point above is something most others don't think about until it comes back to bite them. Nothing is more frustrating than reopening a project that worked fine a few years ago, and even though you haven't changed anything, nothing works, and when trying to update it you end up with Frankenstein's monster.

11ty went out of it's way to remain as simple as possible. Here's your input directory, and here's your output directory. That makes the maintenance and backwards compatibility really easy.

Then you can add the minimum required complexity/abstraction layers only when you need them.

In my case, I use:

• liquid template language, so I only have to write a layout once (header, footer, accessibility landmarks) and every page uses it by default.
• my own custom extension that adds the build time in a html comment for debugging purposes
• markdown (so content creator coworkers can create pages)
  • The project is set up in such a way where coworkers can write markdown in vscode, and see a live preview within vscode (using it's own markdown renderer)

I'll say the one thing I don't like about 11ty is that it's written in js, not ts. The author is all about simplicity and reducing layers of complexity. But now typescript has a typescript-lite version with the erasableSyntaxOnly flag, which basically allows it to run on node (deno and bun already ran typescript), so the next version (or one after), may be migrated to typescript.

11ty = Eleventy? Are you familiar with Hugo? Do you have an opinion or experience between the two systems?

I'm somewhat dissatisfied with Hugo, which I have used for many years, but whenever I checked alternatives, nothing really spoke to me as a clear improvement worth the learning barrier and migration investment If I can use deno, a js static site generator could be viable too - something I traditionally avoided 🤔

Glad to see them mention dialog is in proposal for improvements. If popover covers more accessibility than dialog, that seems like a significant, surprising, and obvious shortcoming. Surely there's technical and/or historical reasons for that, but still.

The --self-extracting flag in deno compile --self-extracting looks awesome.

I could compile my 11ty stack into a single executable that I could send anywhere, but it would still be able to read external markdowns so semi-technical coworkers can make content changes without the maintenance overhead of a CMS and without the coworkers needing to learn modern web dev.

It would also be super awesome for all the internal tools I've built that need to run offline.

Reminded me of motherfuckingwebsite.com

Be aware that a site shouldn't look too barebones. Users will think something is broken and won't even bother reading it.

Never mind the accessibility benefits - not only those braille devices mentioned, but for other disability needs as well.

Well, you could presumably at least use web-sys for interacting with the DOM and wasm-bindgen in general for generating the boilerplate.

But yeah, there might not be a pre-made library for interacting with the extension API, so might need to write your own JS←→WASM bindings.

You could write something in rust for WASM and have minimal JavaScript. Looks like there are no frameworks around this concept as far as I'm aware, but I don't see why it wouldn't work in Firefox.

Deno is great. The best way to write web site and static sites IMO. I really hope they survive.

Awesome! It was totally the colour scheme that was stopping me using SO. Absolutely nothing to do with mods calling me stupid for asking a question, marking it duplicate of a question it's absolutely not a duplicate of, then insisting the Only True Answer is the one from 2003.

Like RAM, CSS color prices have gone through the roof.

What is it, react with the default tailwind style? It's not terrible, just really boring. Looks like fucking Jira.

piefed can mark comments as answers and doesn't have ai :)

Damn, did they run out of color ink?

Seems like json would be more efficient.

Markdown can't execute JavaScript -> pretend to be a bot to get actually usable pages without tracking scripts

they look like they’re gearing up to sloppily it if the UI is an indication

I really don't understand why they even did that? Guess the web devs got too bored while the current one worked too well, but that should have maybe been a sign to keep your hands from it.

You don't even need to be a designer to see how it looks worse even if you are not able to point out what exactly is wrong.

Especially do not get why they got rid of the borders for the sake of minimalism. It adds so much unnecessary mental overhead.

Screenshots of both:

| "Classic" | "New" | |

|

| | | |

Well, you can see I use dark color scheme, which apparently got lost. Make a guess how much better I like that.

It's not my full monitor width because of vertical browser tabs, but even then the horizontal distance between left nav bar and top right nav toolbar is horrendous.

The spacing is wasteful, the sizing is unnecessarily big.

It's worse in every way. Less accessible, less readable, less scannable, less overview.

I wish they would simply drop their new design draft completely.

For anyone visiting the site thinking "looks like before for me" like I did, at the top there's a link to "try out the new site".

Their blog post, research blog post, previous community feedback, feedback form.