Keats

Tree-sitter is going to be a lot slower to load: https://github.com/tree-sitter/tree-sitter/issues/1942.

It's ok for things like editor but using it in a SSG for example is hard when just loading the syntaxes will take multiple times the time it takes to render the whole thing with a regex based highlighter.

Companies can require a force re-auth on blind so laid off don't have access to it anymore.

> Copilot for Visual Studio (i.e. not VS Code)

Maybe it's better now with Go modules but the last couple of repos I wanted to contribute a few years back just didn't build. They both were relying on the master branch of some other projects that had breaking changes.

> I've found myself struggling to decide on what do I want to see in the final app and what I do not; what features might be needed by other users and what features might be an overkill.

It's tricky. You can't accept all the features otherwise you just have a mess. At the same time you need to also add/supports features that a lot of people want but _you_ personally don't need if you want the tool to be used by more than 1 person. For example with SSG I don't use themes, I just write my own templates for every site. Despite that I still added it to Zola because most people want themes. Some people will not be happy when you say no to some features they want but hey, it's open-source they can always fork it.

I wrote Zola because at that time I was using Hugo + Pygments and while Hugo was fast, Pygments was the opposite. I'm pretty sure Zola can build a 1k page website with syntax highlighting faster than Pygments can highlight 20 pages.

Clevo is very common, it's just that it's always sold via resellers so you might not realise it. Eg system76 also sells Clevo laptops afaik

The best interview we've used was sharing a simple but very not idiomatic Python file with working (but slow) code and tests at the bottom. The task was to refactor and speed it up. This allows seeing the actual thought process and some basic skills, while at the same time being something any good dev could do in 20min without much pressure.

> Why would prices be cheaper?

In the emails linked, even Apple acknowledges that the 30% will be passed to the customers.

> Svelte doesn't support JSX/TSX though =(

You have https://www.solidjs.com/ that does

Are we talking about the major company that is happy to give access to all of their users content if the country (eg China) asks? If they were really serious about privacy they would not operate under those conditions.

I still don't get Tailwind either but I found https://github.com/seek-oss/vanilla-extract recently which solves the TS/CSS modules nicely. All the styles are extracted at compile time so no overhead like most CSS-in-JS.

Which one do you recommend for Korean?

Point 2 is solved if you add TS to the css modules.

I wrote https://www.vincentprouillet.com/blog/using-sass-modules-typ... and a commit example: https://github.com/Keats/webpack-react-typescript/commit/978...

Any plans to help Syntect (https://github.com/trishume/syntect) work with the latest sublime-syntax format (https://github.com/trishume/syntect/issues/271 and https://github.com/trishume/syntect/issues/323)? There is a big overlap in contributors for syntect users and syntect can be used by syntax writers to debug syntaxes so it would be a win-win.

I've made a few things:

- Zola (https://github.com/getzola/zola) a SSG that works like I wanted and had a template engine close to Jinja2. I was using Hugo at the time but can't stand Golang template engine (imagine my sadness recently when I realised what Helm Charts are using...)

- Tera (https://github.com/keats/tera): a template engine pretty close to Jinja2/Django templates - at the time it was made only Handlebars existed in Rust and it was not enough for what I needed in Zola

- kickstart (https://github.com/Keats/kickstart): an equivalent of cookiecutter from Python but trying to be more interactive/powerful as a simple binary, see the GIF in the repo for an example

- validator (https://github.com/Keats/validator): my take on Python marshmallow validations, nothing existed at the time.

So yeah, most of my open-source is re-creating libraries I use with Python in Rust.

> much of the most expensive stuff in the process isn’t parallelised

Are you sure? Markdown and template rendering of all pages/sections and image processing is done in parallel. I expect those to be the most expensive stuff. The things that are currently done sequentially are taxonomies (an oversight, the pages in them are rendered in parallel) and the search index generation (oversight as well).

French always use before taxes numbers ("brut"). €62k is about 41k after taxes.

You can compile Tera to WASM if you want but that's the only solution if you want to use Tera templates outside of Rust.

As mentioned, it is _extremely_ similar to Jinja2 in Python, a good number of Jinja2 templates should be valid Tera and vice-versa.

> What Hugo does have, and for which I couldn't find an alternative for in Zola, is something akin to `esbuild` that can build and bundle JavaScript and TypeScript. Is there some way to do this with Zola or does one need to setup a separate build step for that with e.g. `swc`?

Not right no. My issue with that is usually people that want a JS build system will want webpack, loaders and other JS dependencies to also work. You end up just executing webpack command from the SSG while the user could just run it themselves, without a layer.

> That's precisely why I am keeping silent.

(Author of Zola here)

I don't mind feature requests at all! The only thing I mind is people getting angry if I close a feature request as too niche or out of scope for Zola.

But for example, the big focus for the next version is better i18n support so feedback/opinions are very welcome: https://zola.discourse.group/t/rfc-internationalization-syst... but it is a big chunk of work so it will take some time.

For the revisions, I don't think it would work right now the way you want. I have thought about something similar before but couldn't figure out a satisfying way to do it (or even whether it was common enough for the work to be worth it).

> I though this was about the wedding registry site at first.

I didn't even know what a wedding registry was until after the rename. It is named after https://fr.wikipedia.org/wiki/%C3%89mile_Zola

> I did this exact thing when I got frustrated with Hugo. I made my own custom SSG in order to create my blog. > The other thing that tends to happen with SSGs is that it can be a lot more fun to play around with the tech than actually writing blog posts!

Exactly that. A great way to learn a language too.

I've made https://github.com/Keats/kickstart which is roughly the same thing (and improved some bits) without the need to install a python package.

Some Garmin watches can play music too. Garmin 245 Music for example.

Has anyone used Svelte and https://github.com/ryansolid/solid ?

There is i18n support already, just not as good as it would be with this PR (Fluent support etc).

Maybe. I don't think I've ever seen a hanged TV in Europe or Japan.

> One example is requests to support PostCSS instead of SASS

In practice to use PostCSS, you need npm to install plugins, and maybe a `postcss.config.js`, so there are no advantages of having that PostCSS call in Zola's `config.toml` or as a script in `package.json`.

I don't really see how others SSG would handle that. Hugo just shells out a command to `postcss-cli` that needs to be installed (https://gohugo.io/hugo-pipes/postcss/), along with whatever plugins you are using. It's not really something "built-in".

Author of Zola, who used to have sites in Pelican, here.

Pelican is way more customisable, you can write Python scripts to do whatever you want. The downsides: you need to have a virtualenv and that it is pretty slow (especially syntax highlighting). It is awesome overall though, my favourite after Zola ;)