I'd like to see as the first thing on the README.md why this is different and how it's better suited to the authors preferences.
8 years and haven't hit 1.0, that's a bit of torture, no?
Yes, it is a bit of torture :) however I'm getting there. Context (https://mint-lang.com/news/context) was the last bigger feature before 1.0 which I'm planning to release this year.
- TypeScript syntax comparison is here: https://mint-lang.com/from/typescript
- The feature matrix which compares languages features is here: https://mint-lang.com/feature-matrix
I hope you find those helpful :)
edit: by the way TypeScript supports both ADTs (through tagged unions) as well as exhausting pattern matching (on tagged unions, but an alternative can be using `instanceof`).
But you are right, I'll change TypeScript to say it's partially supported.
LLM all around, hail Skynet.
And yes, it's an LLM that pointed them out.
So, are you saying the security holes don't exist because an LLM found them?
Then ask it for more.
Then do the same this with Google AI studio - drop the zipfile in and ask it to analyse for security flaws.
Consider Claude Code's new /security-review prompt or just use the prompt starting from "Objective" after giving the context (see the Git shell commands) to Claude Opus 4.1.
https://raw.githubusercontent.com/anthropics/claude-code-sec...
Definitely Opus 4.1 though, not lesser.
- Remove curly braces from props and children
<MyComponent name="Joe" onClick=(() => canBeInParanthesis()) />
<div>userName</div>
<div>"Text contents"</div>
- Add punning (like how { age: age } becomes { age } in JS) const age = 40;
<MyComponent age />/
<MyComponent active=true /> // explicit boolean attributes const age = 40;
const children = [<div ~ "Moe" />, <div ~ "Larry"/>, <div ~ "Curly" />];
return <div age ~ children />;
Rationale: single child elements are ubiquitous in web dev, but most JSX formatters will require 3 lines of code even if there's a single child.This automatic reactivity thing is really what makes these frameworks more complex than they need to be.
I'd much rather handle all re-rendering calls manually. It's more work for me, but at least I don't work with a chain-reacting foot gun that's hidden in a black box.
> ...handle all re-rendering calls manually.
Have you considered writing web components? With them, you handle the rendering logic and lifecycle yourself.
JS framework creators are not trying to solve the problem of too many JS frameworks.
I want to render my view with instances of classes as a model.
OO conflates data and methods, which makes systems harder to test, reason about, and debug, because functions are less pure due to the “hidden” internal state of an object.
It also encourages heavy constructs that can often be replaced with trivial data structures that are much easier to work with.
Let’s not get started on inheritance.
I think OO is widely discredited now, although I do see a few experienced programmers still using it.
I wholeheartedly agree.
I liked React's support for function components and hooks are quite a treat, but still I think class components are a far better fit for complex components that have logic and state. I'm seeing all this complex logic being expressed as a convoluted mix of hooks and I can't help myself thinking it would be far cleaner to have a class where this logic was handled eith plan old inversion of control.
Tangentially Svelte also provides some reactive primitives, namely SvelteMap and SvelteSet [0]. But I've never had to use any of them.
Still, great he did it I just hope he'll be bolder next time! Of the 7 mentioned features 3-4 are not actually about the language but minor tooling hook ins (prettier, VSCode,) ... maybe that's the wrong focus.
Either way, the strong similarity with other JS/TS frameworks (semantics & syntax) suggests that for really new ideas the community should look elsewhere? Perhaps Clojurescript or Laravel (PhP) ...
What I like about JSX is that you can reuse all of the control flow primitives from JS. You have if, for, map, filter, flatMap, etc. if you want a new combinator, just write a function as you would for any other type of data transformation.
I consider this one of the biggest advantages of React compared to the approach of having separate templating and scripting languages.
If you have `{#if cond}`, that's imperative programming, not declarative, it's just imperative programming using a different syntax.
Using a different syntax for a conditional/loop depending on the type of the data is odd when you think about it. Why should vnodes use one syntax and every other data type use another syntax?
I will grant that the C ?: ternary operator syntax is ugly. If C had had expression based if/else like Rust then maybe people wouldn't mind JSX so much.
Kudos to the dev for working towards realizing their ideas, but Svelte and Solid have essentially solved front-end frameworks for the better part. People still hung up on React happily use Next in prod, people who want simple SSG go towards Astro or Hugo, people who use Svelte/Solid will not switch because this simply doesn't seem to improve upon anything that either do, so I really don't see what this solves in the slightest.
I very happily use Svelte for work, for my personal projects because of fine grained reactivity through signals, no bs syntax that feels like writing "just" HTML & Typescript, mature tooling and great performance. I have no interest switching to something that makes me feel like I'm stuck in the middle of a better React and a worse Svelte.
given how much code is being written in AI today (for better or for worse), something like this might not be the worst thing
const state = proxy({
dur: 1,
count: 141
});
const incDur = () => {++state.dur};
const decDur = () => {--state.dur};
const incCount = () => {
++state.count;
setTimeout(incCount, 100 \* state.dur);
};
return (
<div>{state.count}, {state.dur}</div>
);
Is it specifically proxies only work on objects, and in this approach you can have direct variables?[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2] https://valtio.dev
Components - https://next.semantic-ui.com/components
Templating - https://next.semantic-ui.com/templates
Signals - https://next.semantic-ui.com/reactivity
DOM - https://next.semantic-ui.com/query
API Refs - https://next.semantic-ui.com/api
If you don't mind me asking, why did you leave? What do you plan on working on going forward?
Best of luck! I'm curious to see what you come up with next.
viviansolide•5mo ago