rfcs VS solid

```

We started experimenting with this ling of thought almost 3 years ago:

- First take (ref sugar), Nov 2020: https://github.com/vuejs/rfcs/pull/228

- Take 2, Aug 2021: https://github.com/vuejs/rfcs/pull/368

- Take 3, Nov 2021: https://github.com/vuejs/rfcs/discussions/369

We provided it as an experimental feature and had a decent number of users trying it out in production. The feedback wasn't great and eventually decided to drop it. https://github.com/vuejs/rfcs/discussions/369#discussioncomm...

This is a personal preference, but I use ref almost all the time. Despite tediously writing the .value to access the ref’s value, the Vue team is aware of the problem, and the open RFC - Reactivity Transform, was aiming to solve this issue, however, seems like it was abandoned.

This was a good change. Evan has always been extremely good at putting his finger on the pulse of the frontend community. If there's a feature or paradigm that people love that would fit in Vue, Evan will incorporate it. Over the years, Vue has implemented (and sometimes later deprecated) dependency injection, JSX support, custom elements, Angular-style class components, Svelte-style ref sugar, and now Solid-inspired compiler optimizations. They even changed the order of a Vue file to match that of Svelte: first the script, then the template.

Here is the Current language: https://github.com/vuejs/rfcs/blob/function-apis/active-rfcs/0000-function-api.md

So here's the bottom line. You get RFCs looking like someone trying to land a man on the moon for things like generics in vue while the rest of the world gets work done. Eg https://github.com/vuejs/rfcs/discussions/436

Oh you meant that. Vue and Vite got amazing documentations and I recommend to read them through fully. One more thing i can also recommend is to read through Vue RFCs as well as they contain more extra info sometimes not covered in the docs: https://github.com/vuejs/rfcs Since Vite is based on Rollup, I'd additionally recommend to read Rollup docs, but I find it quite hard to read and navigate https://rollupjs.org/guide/en/#big-list-of-options

The Reactivity Transform, the way it is, is a fucking mess, and would introduce a lot of confusion into the already confused Vue 3 syntax.

https://github.com/vuejs/vue-router/issues/703 https://github.com/vuejs/rfcs/blob/master/active-rfcs/0036-router-view-route-prop.md https://github.com/vuejs/vue-router/issues/703#issuecomment-428123334

Not a "huge drawback", but the excess of .value is annoying. The Reactivity Transform RFC attempts to mitigate that, but IMO it's a footgun and will make things a lot more confusing, so I hope it's not merged.

For Vue 3, not so much. It not only introduced new different concepts, but also made a huge mess for newcomers with its variations (Options API, Composition API, Composition API with script setup), which are different but similar enough to be confused. And the upcoming Reactivity Transform will make it even more confusing by introducing new variations.

The reactivity core, which is in https://github.com/solidjs/solid This is where you'll see the reactivity runtime implementation. Take note that Solid's reactivity doesn't rely on compile-time magic

This is very true. I really hate svelte single file components. But then I tried JSX for breaking things down. I love solid but I don't feel really good about angle brackets within C style syntax. I saw this Scala library that stick with simple statically typed function syntax than html tags. I don't understand why people still wants to stick with xml like tags. In laminar markup is written like this scala div( h1("Hello world", color := "red"), inputCaption, input(inputMods, name := "fullName"), div( ">>", button("Submit"), "<<" ) ) I wish solid team makes their HyperScript syntax as performant as JSX.

What is Solid?

import logo from './logo.svg'; import styles from './App.module.css'; import 'flowbite'; function App() { return (

Edit src/App.jsx and save to reload.

Learn Solid, Tailwind CSS and Flowbite Toggle Flowbite modal

Terms of Service

svg> Close modal

With less than a month to go before the European Union enacts new consumer privacy laws for its citizens, companies around the world are updating their terms of service agreements to comply.

The European Union’s General Data Protection Regulation (G.D.P.R.) goes into effect on May 25 and is meant to ensure a common set of data rights in the European Union. It requires organizations to notify users as soon as possible of high-risk data breaches that could personally affect them.

I accept Decline

); } export default App;

There is example of each technique in Solid's main repo: https://github.com/solidjs/solid/tree/main/packages/solid-ssr/examples

Current reactivity benchmarks (Solid, CellX, Maverick) are focused on creation time, and update time for a static graph. Additionally, existing benchmarks aren't very configurable, and don't test for dynamic dependencies.

Before diving into SolidStart, it's worth taking a moment to outline the history and motivation behind the creation of Solid. Branded as "a reactive JavaScript library for building user interfaces," Ryan open sourced the framework on April 24, 2018. It was designed as a spiritual successor to the reactive programming model exemplified by KnockoutJS.

As always, less complexity and less expressive power at a given level go hand in hand: as far as I could understand, Deno as it exists right now can’t work with a relatively tame nonstandard approach to JSX such as that in Solid.js[1] (without essentially running a build step at startup), let alone a full language extension like Svelte[2] (there is a thing for that now[3], but I think it still squeezes in a build system somehow).

[1] https://github.com/solidjs/solid/discussions/332

[2] https://github.com/sveltejs/svelte/issues/4431

[3] https://github.com/crewdevio/Snel

This one hit late so I put it in July - SolidJS releases version 1.0.0. Never heard of it checkout the perf chart Ryan Carniato wroteup.