7 ms·
New JS frameworks always make for compelling hello world examples. Can you branch on state or use loops over data in Solid.js? The reason _why_ React has a vir
by lpghatguy 5y ago
New JS frameworks always make for compelling hello world examples.
Can you branch on state or use loops over data in Solid.js? The reason _why_ React has a virtual DOM is to enable more interesting relationships between your data and your presentation. Anyone can make a framework that makes the source code for an incrementing number look pretty!
As an example of this point, check out the "Simple Todos" example for Solid.js[1].
In React, we render lists by using regular JavaScript idioms like loops, arrays, and array methods like map. However in Solid.js, much like traditional templating languages, we get a construct like <For> that reinvents a concept that's already in the language.
I've been writing React and React-alike code for a long time. I think that fine-grained updates avoiding reconciliation are a good idea, especially for performance. At one point, I built a React-like library for Roblox and Lua whose most novel feature ended up being "Bindings"[2], which look sorta like Solid.js state containers. They create little hot-path data dependencies, but the bulk of your components still use normal React-like rendering.
[1]: https://www.solidjs.com/examples/todos
[2]: https://roblox.github.io/roact/advanced/bindings-and-refs/
- pier25 5y ago> we get a construct like <For> that reinvents a concept that's already in the language Isn't this optional? Can't Solid use regular JSX loops?
- latchkey 5y agohttps://www.solidjs.com/docs/latest/api#control-flow https://www.solidjs.com/docs/latest/api#control-flow For reactive control flow to be performant, we have to control how elements are created. For example, with lists, a simple map is inefficient as it always maps the entire array. This means helper functions.
- thatswrong0 5y agoThis feels like we're trading complexity here for complexity there, and it seems impossible to judge which way is actually "better". I use loops in React all the time but only have used `setInterval` in a component a handful of times..
- ctvo 5y agoMost of our jobs is determining the right trade offs. I don’t see the big deal here. Error boundaries, suspense, context, very popular routing libraries all have used components to encapsulate functionality. That’s to say first party and third party functionality in the React ecosystem have gone down this path.
- deleted 5y ago[deleted]
- orenelbaum 5y agoWe are not trading some complexity here for some complexity there. We are trading a huge amount of complexity for a framework that is simpler by an order of magnitude. Simplicity is one of the really undeniable benefits of Solid once you gain a decent understanding of the framework. React at times might appear simple on the surface but the overall complexity is pretty huge compared to Solid.
- thatswrong0 5y agoI feel like if it were actually an order of magnitude less complex, it would be eminently obvious from a blog post about it? Maybe I'm just tired and don't "see it" for whatever reason, or maybe I need to find some better examples. From the moment I saw a post about immer.js, I was sold because it seemed like an obviously better solution for the vast majority of cases where I would otherwise grab Immutable.js, a library that I wanted to like but inevitably struggled against. This.. isn't quite as revelatory. I'm not saying it's not all that you claim it is, it's just that from a glance, I don't see how this somewhat different approach addresses the problems I run into often with React in a major way (beyond the claimed performance boost).
- _0w8t 5y agoimmer.js can have terrible performance for data structures starting already with 100 of elements. Using JS proxies is not cheap. We have found that continuing to use immutable.js Map and List but using plain JS objects, not Records is sort-of a sweat spot. But one needs to enforce immutability with Flow/TypeScript read-only types and use the latest immutable.JS to make it work.
- AgentME 5y agoJSX doesn't have loops. When using React, you use regular not-React-specific Javascript tools to do loops and create lists of React elements.
- t_tsonev 5y agoIf this is true, why do you need unique item keys? React cares about loops a lot more than it may seem at a first look.
- sbergot 5y agokeys are not specific to loops. They are needed whenever you are returning a react document with a dynamic structure. They allow for more fine grain dom updates.
- chrismorgan 5y ago> In React, we render lists by using regular JavaScript idioms like loops, arrays, and array methods like map. However in Solid.js, much like traditional templating languages, we get a construct like <For> that reinvents a concept that's already in the language. Once you deal with larger amounts of data and need virtualised rather than fully-materialised lists, you start using different things in React as well. The fact of the matter is that if you care about performance at all, the simple ways are just insufficient, and the native language constructs were designed for procedural programming, not reactive interface rendering, which requires fundamentally incompatible semantics. It’s not even fair to claim that React uses regular JavaScript idioms—VDOM, hooks, the entire shebang is all about eschewing regular JavaScript idioms because they don’t scale. (OK, so there’s also the matter of transient state like scroll positions, element focus, and form field values; it’s not fair to say that React does all these things purely for performance’s sake, as the naive immediate mode approach would also break such functionality.)
- suction 5y agoWhat JS framework would you choose to work with big datasets like, e.g. a data grid with half a million rows that should have a "filter as you type" functionality?
- littlecranky67 5y agoDoesn't matter which framework if you implement it right. Filtering data from the dataset is plain js, and it will be slow. Rendering the data to screen requires a lot of work, such as using offscreen-buffers for smooth scrolling etc. Actually ag-grid does this pretty well, and I've used it for similar in a React app. Now hold your horses, ag-grid is angular 1.x, encapsulated as a component. Another proof that the framework is not important, you need to optimize hell out of it.
- PetahNZ 5y agoIsn't that what a backend is for?
- chrismorgan 5y ago
- alskdjflaskjdhf 5y ago>In React, we render lists by using regular JavaScript idioms like loops, arrays, and array methods like map. However in Solid.js, much like traditional templating languages, we get a construct like <For> that reinvents a concept that's already in the language. I find this a totally bizarre complaint. I've spent the past few months working on Svelte stuff and I've seen people on HN make this same complaint about Svelte's templating language with {#if} and {#each}. Who cares? What is so wrong, exactly, with "reinventing a concept that's already in the language"? It does not make code any harder to understand or to write, and it does not harm performance (in this case, quite the opposite). I would much rather have a reactivity model where I plug in completely standard concepts and patterns (a for loop) than one where I have to deal with a bunch of framework-specific, complicated ones (hooks). That Solid's reactivity primitives are familiar is an advantage, not a disadvantage.
- nicoburns 5y agoI've not used Svelte, but when I've used such DSLs the problem tends to be that they're not very flexible, and as soon as you step outside of the provided helpers you're stuck and you just can't do the thing.
- pier25 5y agoIt's true, but the counterpoint is that DSLs make your life much easier in 90% of the cases (if not more). Personally I've never found a problem I wasn't able to solve in Svelte.
- shrew 5y agoDo you have an example you've run into where a DSL such as Svelte's or Vue's has actually stopped you from doing something? Would be genuinely interested to see it as I've never run into such a situation myself.
- sbergot 5y agoBecause you sometimes want to filter, sort or project your data. Then you have to handle this in viewmodels or invent more and more features for the templating language. Then you want to refactor into components. So you need facilities for invoking subcomponents. Maybe you want something recursive to display tree-like data. So you end up with a secondary full featured language usually with worse IDE support, worse error messages, more surprising issues, etc. You need to understand the scoping mecanisms and if things go wrong hope there is a debug tool available. And in the end those templating languages do not prevent you from mixing UI responsibilities from the rest of your code. If you want a reactive model you can have one. I personally prefer explicit messages like calling setState.
- leonardopainter 5y ago>The reason _why_ React has a virtual DOM is to enable more interesting relationships between your data and your presentation. Anyone can make a framework that makes the source code for an incrementing number look pretty! Actually, that is only half the reason. You can do whatever you want in my library (github.com/thebinarysearchtree/artwork) and it doesn't have any kind of virtual DOM or whatever Lit does, because you just create elements with JavaScript. The second reason, that everyone just assumes is the default, is that React has to use HTML-like templates and not just JavaScript.
- Kaze404 5y agoJSX is a purely optional part of React. You can use it with just Javascript and no bundlers just fine.
- tambourine_man 5y ago>…much like traditional templating languages, we get a construct like <For> that reinvents a concept that's already in the language. I'm right there with you, but when React invents a whole markup language inside of JavaScript, it's not in much of a standing to make purity criticisms.
- masklinn 5y agoThat is an utterly bizarre rejoinder. JSX has always been (and afaik still is) optional and extremely thin syntactic sugar. It’s little more than a convenience macro (so that views can look a little more like the markup equivalent). It has no intrinsic semantics, and maps pretty much directly to actual javascript (which you can write directly or use an alternative helper for — hyperscript being a common one).
- BigJono 5y agoWell you've obviously completely missed the point of JSX then. The "whole markup language" that they invented is literally a line for line transform. Optimisation aside, there's no reason why line 58 of a file with JSX in it won't be line 58 of the transpiled JS file, and read exactly the same. All JSX is is a custom function call syntax. It's about as pure as you can get while having any sort of html-ish 'templating' whatsoever. So, I'd say it's exactly in the right place to be making purity criticisms. They've taken the only approach that preserves the integrity of the code and doesn't involve build time magic.
- tambourine_man 5y agoOh I missed the point on React altogether. After 10 years, I still fail to see why anyone would use it voluntarily. But coming back to JSX, a custom function call syntax is OK and pure because it has a one to one mapping on line number? I don't know if there's much point in discussing purity since it's badly defined and mostly in the eyes of the beholder, but it always smelled like one hacky syntactic sugar to me.
- ______-_-______ 5y agoSolid's <For> doesn't rely on any build-time magic, other than the JSX custom function call syntax that is also present in React. If you want, you can even call it like an ordinary function: function MyComponent() { return For({ each: [1,2,3,4], children: x => <div>{x}</div>, }) ) It's just a function call, and it doesn't even need `React.createElement`. What's more pure than that?
- zero_shift 5y agoLikewise I simply don't empathise with the author's complaints. Hooks make sense if you think in closures. Hooks are isolated so you can think about them in isolation. What I like about the React monoculture is that it's one less thing I have to care about. I can focus on the other aspects of my programs, beyond turning JSON into HTML. I haven't used SolidJS so I'm not going to put it on blast. However, hearing people compare its reactivity model to Knockout JS gives me the heebie-jeebies, because Knockout projects were horrific to reason about (and test) beyond a certain scale.
- toastercat 5y ago> In React, we render lists by using regular JavaScript idioms like loops, arrays, and array methods like map. However in Solid.js, much like traditional templating languages, we get a construct like <For> that reinvents a concept that's already in the language. This argument is silly because it inevitably becomes a pissing contest of who can be most like vanilla JavaScript. In that case, why use JSX? Just write hyperscript calls instead. Why use React Router/React Context helpers? Just wrap your components using vanilla function providers instead. Why use React Hooks, which inevitably look like magic to a JavaScript veteran because the library inherently hides away some global state? I hope you can see what I'm getting at here.
- iyc_ 5y ago> In React, we render lists by using regular JavaScript idioms like loops, arrays, and array methods like map. However in Solid.js, much like traditional templating languages, we get a construct like <For> that reinvents a concept that's already in the language. I had/have your bias, but from playing with it I found a couple things: 1) Like React, you can swap out the template feature for a function call (or subcomponent). e.g. instead of return ( <button...> ... </button> <For each={state.todos}> ... ); you can use functions and loops: function displayTODOs<T>(todos: T[]): any { let arr: any[] = []; for(let [i, todo] of todos.entries()) { const { done, title } = todo; let elem = (/\* JSX \*/); arr.push(elem); } return arr; } ... return ( <button ...> </button> {displayTODOs(state.todos)} ); 2) Even with my bias, I must admit I found the `<For...` syntax to be surprisingly easy to read and fast to eye-parse; much more so than other 'templating' (using your term) languages/macros/syntax I've used over the years.