Live data from Hacker News

Ripple: The Elegant TypeScript UI Framework

jsdev.space

21–28 of 28 posts

Re: Ripple: The Elegant TypeScript UI Framework

#21
post #17

I don't get how this would be more "ai friendly" than other frameworks, that kind of propositions should be backed by more concrete proof. I know that this is a kind of open problem but at least show me this can be easily generated with common models without an enormous reference prompt. Another thing is that this looks like any other framework out there. I think you can map every one of it's features mostly 1-1 to S…

>I don't get how this would be more "ai friendly" than other frameworks, that kind of propositions should be backed by more concrete proof. Most if not all llms are producing Markdown instead of HTML as the primary output. Markdown has a simpler syntax that basically uses fewer tokens compared to HTML Similarly, Ripple appears to express a complex structure in simple terms compared to React or HTML or whatever. No wo…

shorter syntax != higher level of abstraction

Re: Ripple: The Elegant TypeScript UI Framework

#22

And just like svelte this is elegant exactly until you realize that it is not possible to correctly track all the dependencies and just like svelte you realize that a mix of explicit and implicit reactivity is really hard to debug and then you seitch to explicit reactivity and then you are just as complex as any other reactivity based framework

With the introduction of proxy-based reactivity using runes, that is largely a solved problem in svelte.

Re: Ripple: The Elegant TypeScript UI Framework

#23

It's very similar to Mint ( https://mint-lang.com/ ) which I'm building for some time now. Looking at the samples, it seems Ripple is going the same direction as Mint: - explicit component definitions - inlined control flow in HTML tags - component based styling - explicit white space handling for element content - syntax for setting references I'm not sure why they based it on TypeScript instead of creating a new la…

Obvious reason would be that all major js libraries have ts definitions available now and if the language is TS based they can all be used without compromising with type-safety.

Re: Ripple: The Elegant TypeScript UI Framework

#25

It's very similar to Mint ( https://mint-lang.com/ ) which I'm building for some time now. Looking at the samples, it seems Ripple is going the same direction as Mint: - explicit component definitions - inlined control flow in HTML tags - component based styling - explicit white space handling for element content - syntax for setting references I'm not sure why they based it on TypeScript instead of creating a new la…

Would mint be a good fit if I want to make something like https://winxp.vercel.app/ ?

Re: Ripple: The Elegant TypeScript UI Framework

#26

It's very similar to Mint ( https://mint-lang.com/ ) which I'm building for some time now. Looking at the samples, it seems Ripple is going the same direction as Mint: - explicit component definitions - inlined control flow in HTML tags - component based styling - explicit white space handling for element content - syntax for setting references I'm not sure why they based it on TypeScript instead of creating a new la…

Would mint be a good fit if I want to make something like https://winxp.vercel.app/ ?

I think so, yes.

Re: Ripple: The Elegant TypeScript UI Framework

#27

And just like svelte this is elegant exactly until you realize that it is not possible to correctly track all the dependencies and just like svelte you realize that a mix of explicit and implicit reactivity is really hard to debug and then you seitch to explicit reactivity and then you are just as complex as any other reactivity based framework

I'd argue that it's easier to debug a few lines of magical code than 10x lines if non-magical code.

Re: Ripple: The Elegant TypeScript UI Framework

#28
post #9
post #6

Please.. no more UI frameworks. Can we just agree to make react native to the browser, get rid of redux, and simplify things?

erm, no? React has painted itself into a usability and optimisation nightmare corner by insisting that components are the most granular level of resctivity. That's why they need 20 different hooks to do anything. You want signals in the browser for granular reactivity, and they are making their way there: https://github.com/tc39/proposal-signals

I'm in full agreement here.

Thanks for the link, I didn't know about this initiative, I'd vote for signals with my eyes closed.

Post reply on HN