Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Solid.js feels like what I always wanted React to be

typeofnan.dev

Post reply on HN
Print view View original

291–300 of 444 posts

Re: Solid.js feels like what I always wanted React to be

#291

Post by ramoz »

fuzzy2 wrote: post #282
ramoz wrote: post #276

Earlier quoted context omitted.

The whole "I hate angular" is a bit old at this point. The latest versions are really quite simple/powerful. We act like it's still 2015 and we're jumping from angularjs 1.x to React. The jump was nice, yet turns out production-grade engineering in React was not so nice.

I don’t like the separation between template and code, I don’t like the developer experience (slow and often malfunctioning VS Code extensions and slow builds, bad in-browser debug helpers), I don’t like how creating “ad-hoc” components is basically impossible. I think Zone.js is insane. I know Angular very well. That’s why I’m confident I can create high-performance applications using Angular. I firmly believe Angul…

`Angular Language Service` is the only domain specific extension I've ever needed and its never been an issue. The template separation, as well as (s)css, I like organizationally compared to the chaos you end up in with large jsx-styled applications.

Re: Solid.js feels like what I always wanted React to be

#292

Post by imtringued »

toomanydoubts wrote: post #148
rk06 wrote: post #120

Earlier quoted context omitted.

I mean side effects from a functional point of view. Let me explain in more details React’s philosophy is View = F(data) I.e. view is a pure function of data. By “pure”, we mean F() does not do console.log, ajax calls, date time and other stuff which is not consistent every where. This assumption is ingrained in React. You see it when you are told that react can overrender and your code should handle overrendering. A…

I fail to see the purity in react with all that useState, which obviously by the name is tracking state outside the scope of the function(eg: it's actually View = F() and data is coming from outside when calling useState). It's not pure at all. I really would like to see something more akin to Elm, where all your state is explicitly passed into the component, and you have commands that update state and trigger the vi…

Yes it's var View = F() and var hidden_global_variables_for_hooks;

Re: Solid.js feels like what I always wanted React to be

#293

Post by pier25 »

thomascgalvin wrote: post #287
StevePerkins wrote: post #277

The author lost me in the introduction. > "Ohhh, an OO pattern with a couple of one-liner lifecycle methods is just WAY too much code! Higher likelihood for errors and worse developer experience." ... > "So instead, I'm going to replace this with a functional pattern, that crams a couple of lifecycle functions into a closure, and is riddled with edge cases and common developer mistakes." This article perfectly crysta…

UI development seems determined to repeat every mistake we've made on the backend over the past thirty years, while adamantly refusing to ask us about any of those mistakes.

Care to elaborate? What mistakes are you referring to?

Re: Solid.js feels like what I always wanted React to be

#294

Post by imtringued »

leonardopainter wrote: post #198
pjmlp wrote: post #184

Earlier quoted context omitted.

Easy, Java and .NET SSR frameworks (which support components for two decades now), + vanilaJS for Ajax like behaviours. Loads fast, easy to debug without tons of layers in the middle. And yes, I also do manually make use of script and vendor JS libraries. Naturally it only works when doing side gigs on my own, on big Web projects where my role is mostly BE/DevSecOps, I go with the flow.

That isn't a solution. Everybody moved away from this approach for web applications for good reasons.

I agree, I am writing some apps like that and we still want some minimal level of interactivity that is suited to react. E.g. a file uploader.

Re: Solid.js feels like what I always wanted React to be

#295

Post by imtringued »

lbj wrote: post #240

Almost every criticism of React that I've read, goes away when you drive it from Clojurescript. If you haven't had the pleasure I suggest you take it out for a spin. Example of a full blown React component in Clojurescript: (defn counter [] (let [state (r/atom 0)] (fn [] [:div {:onClick #(swap! state inc)} "The count is: " @state])))

Reminds me how vanilla hibernate is unusable but Grails'/Groovy's GORM (built on Hibernate) is absolutely fantastic.

Re: Solid.js feels like what I always wanted React to be

#296

Post by bstar77 »

Kuinox wrote: post #183
torginus wrote: post #182

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…

https://svelte.dev/blog/virtual-dom-is-pure-overhead It is a huge performance issue. I tried to do a pokedex in react, you have to use a virtual list, because react/virtual dom is too slow, doing any operation on a plain list with 1k element, like filtering lead to multiples seconds freeze. This also lead to a lot of issues, like not being able to ctrl+f text being out of screen in a virtual list.

I don't understand your issues here. I built a community app for a hockey league that manages around 120,000 players in the DB. I do tons of loading, sorting and various algorithms on the data. I've never once had React be my bottleneck.

Rendering a page server-side and delivering it to users is about as inefficient a process as you can get unless you have massive resources dedicated to an optimization almost no one needs anymore. The virtual DOM is extremely efficient, it just needs more memory and CPU cycles on the client which are resources readily available. Browsers are very good at managing this in 2022.

Btw, your code in that article is completely irrelevant... I would not be showing people that article in 2022.

Re: Solid.js feels like what I always wanted React to be

#297

Post by throwamon »

stocknoob wrote: post #67
valtism wrote: post #63

I've used React for ~3 years, primarily with function components and hooks. I think that hooks were a wonderful addition and I think the framework has made smart choices with checking object equality to decided if components re-render. That said, I think that easily the most difficult aspects of react revolve around how re-renders are triggered. Maintaining referential equality to stop unnecessary renders gets tricky…

For the other Americans, “used xyz in anger” means “used xyz in production”. https://english.stackexchange.com/questions/30939/is-used-in...

I always assumed it was something like "I got so angry with a certain solution that I gave in and tried this other one".

Re: Solid.js feels like what I always wanted React to be

#298

Post by prea »

StevePerkins wrote: post #277

The author lost me in the introduction. > "Ohhh, an OO pattern with a couple of one-liner lifecycle methods is just WAY too much code! Higher likelihood for errors and worse developer experience." ... > "So instead, I'm going to replace this with a functional pattern, that crams a couple of lifecycle functions into a closure, and is riddled with edge cases and common developer mistakes." This article perfectly crysta…

> All of the virtual ink in this article, and honestly most of the complexity in the field overall... and it seems to really all just boil down to, 'I think this looks cooler.'

IMO there's significant complexity in building a feature-rich frontend client. The "thicker" the client, the worse it gets. There's definitely a lot of 'I think this looks cooler' going around, but also we shouldn't forget that the need to come up with something better is partially a response to very real, very-not-imagined, frontend complexity.

Re: Solid.js feels like what I always wanted React to be

#299

Post by bstar77 »

torginus wrote: post #211
Kuinox wrote: post #183

Earlier quoted context omitted.

https://svelte.dev/blog/virtual-dom-is-pure-overhead It is a huge performance issue. I tried to do a pokedex in react, you have to use a virtual list, because react/virtual dom is too slow, doing any operation on a plain list with 1k element, like filtering lead to multiples seconds freeze. This also lead to a lot of issues, like not being able to ctrl+f text being out of screen in a virtual list.

Great article. The fact that Angular, the framework built by the company who also builds the world's most popular browser, does not have a virtual DOM, is very telling.

It's actually a terrible article that has no relevance in 2022, and it is even misleading for 2018 standards.

Re: Solid.js feels like what I always wanted React to be

#300

Post by kjleitz »

zero_shift wrote: post #272
alskdjflaskjdhf wrote: post #111

Earlier quoted context omitted.

>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 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 t…

> It does not make code any harder to understand or to write, Well, what can you tell me about TypeScript type inference for this custom DSL?

Have you used Vue 3? There is fantastic TypeScript support in templates, including comprehensive intellisense for the templates in VS Code with the Volar extension. Surprisingly, _refreshingly,_ good.
Post reply on HN