401–410 of 444 posts
Earlier quoted context omitted.
Well, you can be skeptical, and the enterprise front-end engineers are going to go right on using that stuff because it scales to large codebase.
Yes, right up until said startups and enterprises 1. cannot afford the outrageous cloud expense or 2. Need to scale to low-power devices (such as wearables) and to customers who are security conscious
I've been on this quest for a long time, because I like React model. So I had fun with putting observables in my app (kefir and karet from calm-js and my own thing with xstream), I tried custom selectors with redux and all 'like-redux-but-simpler' libraries, I also tried recoil. These solutions can work and worked for my apps, but it felt like I was fighting against React.
Solid was nice. It provided necessary tools to write interactive data visualisations with ease and in performant way. It has quirks but they are manageable - my team also learned and contributed to projects in Solid.
First, the concept of "component functions" that are more like factories. It is not groundbreaking (reagent had this idea long ago) but is quirky. Thankfully, half hour with Solid playground and everybody can see what code is generated and how it works under the hood. It is really predictable but also tangible - you can play with just part of your app in playground if something is unclear.
Second quirk is props object. I understand the trade-off but it trips users (me included) that you can't just treat it as regular object. Sadly, only solution for this is lint rule - yuck. But it is much simpler rule than hook rules - just don't destructure props.
In the end, Solid is great tool for "web apps". Think about dashboards or diagram editors. Cheap components, fine grained reactivity, focused updates yield great performance results without jumping through hoops.
Earlier quoted context omitted.
Zustand has solved the complexity of state management for me, although getting {employer} to adopt it is of course a different problem altogether. It's really bizarre to me how poorly useContext works, in contrast to how good everything else in React is for the most part. Having a good, "official" global state management solution that requires little boilerplate would be a huge benefit.
Wait till you realize Zustand does not work on React 18's Concurrent Mode and istead must use Jotai (same author) ?
Earlier quoted context omitted.
This is about "feels like" and me too--the little newsletter popup and lack of substance shows this. React became obsolete over the past few years as browsers increasingly adopted the mix of web components features (eg componentDidMount vs connectedCallback). Just using React, and the explanations for why a technology is and isn't used in an organization speaks to the level of practical knowledge and detritus in proj…
I've been maintaining a web component library with Lit for a while. Web components overall don't feel ready for primetime. Just making a custom input field and have it work with a is chore. Just look here at how much overall code is needed to do it right: https://github.com/ing-bank/lion/blob/master/packages/input/... After you get through all the inheritance and mixins it's thousands of lines
Earlier quoted context omitted.
That is a big call regarding web components. I did some looking into web components for a recent project and React is just way ahead in many areas. You could use a framework like Lit to help smooth things over, but that just speaks to the underlying standard being somewhat cumbersome to use. I totally want web components to succeed and be the new way of doing things, but I get the feeling that is still a while away.
I think calling web components "cumbersome" belies the intention of the APIs, which is to enable custom HTML elements, encapsulation, and interop - fairly low-level concerns. Lit takes care of templating and reactivity. Web components don't have those, it's expected that you use other methods, including what you already use, to create DOM and react to state changes. The DOM may eventually add templating and reactivit…
Earlier quoted context omitted.
Well 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…
Solid's 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 => {x} , }) ) It's just a function call, and it doesn't even need `React.createElement`. What's more pure than that?
Earlier quoted context omitted.
> For example a flurry of setStates could be wrapped up in one single state. If it gets too complex - into a reducer You've just deoptimized your app, and your whole component will re-render on every change. > Components that don’t benefit much from splitting up could have their business logic wrapped into a context You did it again. More unnecessary re-renders. > it’s still performant and works True that 'it works',…
Why is performance always argument No. 1? The true rule is, code must be readable and maintainable first. THEN, if there are performance issue with the code (no theoretical ones, you HAVE to have a real-world profiling report of YOUR code in your hands when you argue about performance), you can refactor for performance.
On top of that, profiling and optimizing a real world application with a dozen hooks in every component is pretty painful.
Earlier quoted context omitted.
It can't. Not in a consistent manner. When diffing user provided immutable data you need a user provided key. Otherwise it can't tell the difference between a new list entry and a nested update. You could treat every nested update as a new item but that is incredibly wasteful as it throws away all descendants. This is something all non-fine-grained rendering libraries have to deal with be it React, Vue, Svelte, or Li…
How does Solid avoid the need for user-provided keys? I thought it also had to diff the underlying array. Does it check object identity?
Now this does require special process for intaking immutable or big data snapshots where we can't do reference comparison. So we do have a data diffing capability in our nested reactive stores to propagate only what changes. But for the most part common actions like partial updates highly optimized. As well as simple list operations like sorting.
Earlier quoted context omitted.
> "I think this looks cooler." You're using this straw man to demean the author, but I think you miss an interesting point: it can be very hard in software developer to articulate the good and bad. "Uncle Bob" refers to this as "code smells", where you can't quite say immediately what's wrong here, just that you don't like it much. Something smells bad. And maybe the point of Solid is to point out a mistake React mad…
Super subjective. To people who know what they are doing more code than necessary to accomplish a task is the code smell. To people who are super insecure vanity code is required because patterns are memorized, so any deviation from the unnecessary boilerplate is the code smell.
While I agree, I think a lot of developers are oversensitive to boilerplate, sometimes to their own detriment. And the effort to shave off boilerplate quickly runs into diminishing returns. Beyond a certain point you end up with code that is harder to use because of the layers of abstraction you've added to avoid the last-mile developer writing unnecessary boilerplate.
But I am a touch typist, whereas I'm noticing more and more developers who are not, so maybe there's something there.
Can anyone explain the point of the virtual DOM and why it’s not a source of huge performance issues? What I mean as soon as you retain a reference to a DOM element, it’s lifetime becomes managed by the JavaScript gc - let’s say you build a paginated gallery app in pure HTML and an spa - in the first case, the browser knows that as soon as you navigate away from the page, all those image thumbnails are free real esta…
Knowing that your entire UI is running inside a function that gets re-executed with every render, gives a tremendous amount of safety and predictability to your application and makes testing a breeze. But you can't actually rerender the whole world every time because performance, so instead React relies on a JavaScript object to hold a representation of the UI, and then surgically updates only the pieces that need updating. This was React's big thing.
The reason people want to move away from virtual dom is because browsers have gotten faster and now the Dom updates aren't the biggest source of overhead.