edemaine

Do blocks in Civet are mainly to provide shielded scopes (with local declarations). They're currently also necessary to handle declarations (const/let) in the middle of expressions, but hopefully they won't be necessary eventually - only when the user wants to shield scopes. They also have useful forms like `async do` that let you build Promises using await-style code.

Thanks for the report! This was tricky to track down, but I've got a fix: https://github.com/DanielXMoore/Civet/pull/1501

As an example, Solid's JSX compiler changes multiple times in a year. It's better to target JSX than the compiled form. There are also many JSX compilers. (Even React ships with at least two.)

Yes, Civet has taken a lot of syntactic inspiration from LiveScript. At this point, I think we have most of the good features, but we might be missing some. Let us know what you think!

The big difference, of course, is that Civet fully supports TypeScript, and is up-to-date with the latest JavaScript and TypeScript features.

The JSX spec hasn't changed for almost 10 years, and I'd guess there will never be a JSX 2.0. On the other hand, ideas for a better JSX are plentiful (check out the issues on the JSX repo, for example). If the spec never changes, how can we improve the JSX experience? Transpilation!

Civet's futuristic JSX compiles to actual spec-compliant JSX, to it's compatible with all forms of JSX, including React, Solid, etc. We'd like to support other DSLs like Astro and Svelte as well.

Good question! I don't have hard numbers, but for larger files, I find that it can take on the order of a second to compile. It's still fast enough to get real-time feedback from TypeScript in VSCode, but it could definitely be faster. There's lots of optimization left to do; for now, we're focusing on features over speed, but we'll get to speed as well. (I am an algorithms guy after all!)

You can also turn off implicit returns in Civet if you don't like them. They also work well with TypeScript annotations: if you annotate a return value of `void`, then there's no implicit return.

I agree it can be easy to make and throw away big arrays if you're not aware of what's going on. But it can also save a lot of time. For loops as arrays are super useful, integrating the equivalent of "map" into the language itself. We also recently added generator versions (for*). JSX is a nice example where for loops as expressions and implicit return are powerful; see e.g. https://civet.dev/reference#code-children

In case you wondered how Civet compared to CoffeeScript in these regards:

* `is not` is the textual equivalent of `!==`. You can use `isnt` if you turn on the feature explicitly (or even the weird CoffeeScript `is not` behavior if you want it, mainly for legacy code)

* Implicit returns are turned on by default. They are really useful, most of the time, and don't get in the way much if you use `void` return annotations (which turns them off). But if you don't like them, you can turn them off globally with a compiler flag.

* Civet's compiler is built on very different technology from CoffeeScript's (PEG parsing, similar to Python), and it is much more strict about indentation. None of those weird bugs anymore.

* We do have implicit parentheses and braces and such, but you're free to use explicit parentheses and braces as you like. We encourage people to rename their .ts files into .civet (which mostly just works without any converison) and just embrace the features/syntax they like.

It's doing a few things at once:

First line:

* `{min, max} := Math` is a destructuring declaration. It's similar to the destructuring assignment `{min, max} = Math` (i.e., `min = Math.min; max = Math.max`), but also declares min and max as const.

* The `operator` prefix means to treat min and max as new infix operators in the rest of the program.

Second line:

Given that min and max are infix operators, `value min ceiling max floor` is equivalent to `max(min(value, ceiling), floor)`. Yes, the latter is gross. That's why we like to write `value min ceiling max floor` instead. Think of it as "value minned with ceilling (i.e. capped at ceiling), then maxed with floor (i.e. prevented from going below floor)".

But we are using indentation style; that's one of the major design principles. In Civet, the body of an "if" can be multiple lines, and it's clear (from indentation) what they're nested under. Also, the body of an "if" statement can be empty, so if you comment out the body, the "if" doesn't apply to anything else. (This is an improvement over Python, which requires non-empty bodies, even if just to say "pass".)

I think there's a reason that Python is among the most popular programming languages, and part of it is the indentation-based syntax and lack of brackets. The core of Civet's syntax (originally inspired by CoffeeScript) is like a combination of JavaScript/TypeScript and Python, the two/three most popular programming languages.

But also, if you like brackets, you can include them! Most JavaScript/TypeScript code is also valid Civet. Just use the features you like.

We're definitely looking for ways to improve ways to specify types! I think destructured typing [https://civet.dev/reference#destructured-typing] is already quite useful, especially for React. On the readability side, if/then/else [https://civet.dev/reference#conditional-types] seems easier to read than ?: ternaries, and "Partial Record Name, Info" seems easier to read than "Partial<Record<Name, Info>>" (implicit type arguments — https://civet.dev/reference#implicit-type-arguments). But we'd love to hear more ideas for features like branded types. Join us in Discord if you're interested!

One of the Civet devs here. To me, the main benefit of Civet is the ability to rapidly add useful features to the language, while preserving all the benefits of TS (tooling, etc.). We're constantly coming up with ideas — from TC39 proposals, other languages, or general brainstorming — and implementing them quickly. For example, we recently added pattern matching when catching exceptions, which took just a couple of hours of development; or Python-style from ... import ... for better autocompletion of imports. All of these features are optional; you can write well-formed TypeScript as usual, and just choose to use the features you think are worth the learning curve for readers. The plugins for VSCode, Vite, esbuild, Webpack, eslint, etc. aren't perfect, but they let Civet code enjoy most of the tooling out there.

I personally use Civet for all my coding projects, as I'm devoted to it continuing to flourish. But if you ever don't like what Civet is offering you, you can eject at any time by replacing your code with the TypeScript compilation, which we make as close as we can to your input.

What happens if a TC39 proposal is rejected? That's actually the good case for us, because it means we can keep the feature as is. Civet already transpiles all features to TypeScript, so they can live here forever if we think they're good. The trickier part is when Java/TypeScript changes in a way that's incompatible with Civet. Then we plan to change Civet to match Java/TypeScript, so that we don't diverge (though compiler flags allow us to also support the older form with explicit opt-in if we think it's worth doing so).

JavaScript and TypeScript move slow. Largely that's a good thing; they're a stable foundation, and we don't want to mess them up. But it's also exciting to be on the bleeding edge, explore new ideas, and obtain new features as quickly as we can design them, instead of waiting a decade. Many features are also too niche / add to much complexity for the general JavaScript language, but they're still fair game for languages that transpile to JavaScript. See also the recent JS0 vs. JSSugar discussion.

Regarding the first question, I've gone ahead and implemented random build orders, so at least the two Ls in HELLO will usually produce different animations (depending on random choices). Designing completely different glyphs for the same letter is quite challenging (finding these already took a lot of work).

Regarding the second question, there's already a 2-second delay. I wonder if there should be a slider to specify the delay?

I find the back/forward buttons useful for undoing/redoing changes, so that I don't lose past cool designs / settings, though I can see it being a controversial approach.

That said, there were definitely way too much history generated when typing into a text field. I just implemented a planned compromise, where you only get a history event when changing a "committed" text field (meaning you previously defocused the field). Hopefully this is the best of both worlds!

Good idea! I've gone ahead and implemented this feature: if "obscure in URL" is turned on, the text won't be visible unless you focus on the textbox (e.g. to edit it).

I couldn't reproduce this bug. Perhaps the program you're using to display the GIF doesn't support the GIF frame delay feature? (E.g., Chrome seems to display them fine.) Feel free to open an issue on the repo if I'm missing something: https://github.com/edemaine/font-tetris

Thanks for the feature suggestion! I've gone ahead and implemented random valid stacking order. So if you reload the page, and enter text that repeats the same letter more than once, you will hopefully get different build orders (depending on random choices). For example: https://erikdemaine.org/fonts/tetris/?text=aaaaa&rotate=0&sp...