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

431–440 of 444 posts

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

#431

Post by mlajtos »

Kuinox wrote: post #206
mlajtos wrote: post #196

Earlier quoted context omitted.

I also did sort-of Pokedex a long time ago [0], but haven't seen any performance issues. No virtualization whatsoever. Code [1] is rather simple. [0]: https://mlajtos.github.io/lb-pokedex/build/ [1]: https://github.com/mlajtos/lb-pokedex

I ran a profiling tool. I searched "zz" then deleted these. Deleting it caused a 120ms UI freeze (and I notice it :p): Profiling report: https://share.firefox.dev/3C3OhIq Given I had slightly more entries (a hundred more) and that I had way more node per entry, it led me with way worse performance. Instead of a plain list I have a little summary card per pokemon (which is why I have more node per entry). The naive im…

You can also preserve DOM and just hide non-matching elements, like here:

https://codesandbox.io/s/hidden-dawn-odm1m1?file=/src/App.ts...

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

#432

Post by toastal »

z5h wrote: post #332
toastal wrote: post #269

Earlier quoted context omitted.

Oh that's jumping the gun. TEA doesn’t compose and you can pretend you don't need components until you do and then you end up with big mess of hard-to-follow spaghetti code. It's not 'bad', and has good use cases but The Elm Architecture is not without flaws.

Elm composes just fine and you can get close to the semantics of components. I wrote this over 3 years ago, have been using it in many projects with no concerns. https://package.elm-lang.org/packages/z5h/component-result/l... There are other ways to achieve similar. You don't end up with "big mess of hard-to-follow spaghetti code", you might end up with a "large amount of unfamiliar-looking code". Getting better at r…

Yeah? I wrote something to deal with it too (https://github.com/toastal/return-optics) 5.5 years ago. You arguably chose the wrong data as `(model, Cmd msg, Maybe extMsg)` instead of `(model, Cmd msg, List extMsg)` which would give you more flexibility and still functions as a monoid on [] instead of Nothing, but allows multiple messages shrug. I tried this approach more recently and it involved me having to encode all of actions in a massive tree and then I still had issues with certain messages including now having to UUID all elements that that previously I didn't need to think about. It was a mess, but the best I could do with the tools at hand.

If you compare this to Halogen (https://github.com/purescript-halogen/purescript-halogen/blo...) where you still have purity but can set up subscribers and listeners from any component. It's much easier to use and for some components like dialogs, it's much simpler. And this actually isn't the best example because with the latest Halogen, Portals (https://github.com/purescript-halogen/purescript-halogen/pul...) was introduced so you can launch a dialog on the spot instead of even needing to communicate between them at all.

This is my anecdote though. And I've been away from Elm long enough now (around 1.5 years) that I've forgotten all the specifics.

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

#433

Post by z5h »

toastal wrote: post #432
z5h wrote: post #332

Earlier quoted context omitted.

Elm composes just fine and you can get close to the semantics of components. I wrote this over 3 years ago, have been using it in many projects with no concerns. https://package.elm-lang.org/packages/z5h/component-result/l... There are other ways to achieve similar. You don't end up with "big mess of hard-to-follow spaghetti code", you might end up with a "large amount of unfamiliar-looking code". Getting better at r…

Yeah? I wrote something to deal with it too ( https://github.com/toastal/return-optics ) 5.5 years ago. You arguably chose the wrong data as `(model, Cmd msg, Maybe extMsg)` instead of `(model, Cmd msg, List extMsg)` which would give you more flexibility and still functions as a monoid on [] instead of Nothing, but allows multiple messages shrug . I tried this approach more recently and it involved me having to encod…

Thanks for qualifying wrong with "arguably". I did explain in the docs that it was a design choice, but I see your valid point. My motive was to simplify calling code and require dealing with the external message. It's had the intended effect so far. I'll read over the halogen stuff.

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

#434

Post by robertlagrant »

mst wrote: post #378
ricardobeat wrote: post #146

Earlier quoted context omitted.

We also had ractive.js, we had mithril, intercooler.js (now htmx), we even had (fab).js as far back as 2010 with functional rendering. A 'breath of fresh air' pretty much depends on what you had been breathing.

React wasn't exactly innovative as such so much as it was a very carefully designed (I don't mean they didn't make mistakes, mind, only that they clearly put effort into making new and exciting mistakes) implementation of the model that successfully broke into the mainstream. The phrase "an idea whose time had come" springs to mind. (this comment is intended to read as professional respect, not fanboying - the extent…

> they clearly put effort into making new and exciting mistakes

Very good.

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

#435

Post by antihero »

torginus wrote: post #236
antihero wrote: post #219

Earlier quoted context omitted.

This seems like a huge step back from declarative UIs, any reason why you would say it’s preferable?

Performance, for one. This method can easily avoid allocating an object for every div (since it turns into a method call, not something that needs to return an object), compared to React's render() method. Another scenario outlined in the article of rendering a row of buttons, each with it's own click handler, that needs to allocate a lambda for each button every render. Alternatively, using map() and filter() also a…

Everyone goes on about performance but unless you are doing something extremely complicated or you have fucked stuff up in an extremely bad way, the actual part of React apps which is rendering to vdom and diffing to dom, in my quite long experience with it, is very rarely a problem, and not enough to warrant a stateful imperative approach.

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

#436

Post by toqy »

jimmont wrote: post #415
toqy wrote: post #412

Earlier quoted context omitted.

That's just one example, and the issues with form associated components are not limited to ING. The Microsoft FAST form components also have a fuck ton of code to achieve what + can do in any non-webcomponent framework. There are proposals for this and most of the other issues I have with web components. But they all feel like issues that could have been covered from the beginning. Also if you go all Lit on an app wi…

What is your point--or question? Form elements are complex. I'm not familiar with cypress. Puppeteer has worked fine for my needs. If the thesis is simply that using web components is a chore, well, welcome to frontend work. It has always been a chore in one way or another. Web components are the first time I can say--for my own professional experience--it was less so than previously. Generally a superior experience…

> That products survive this long with React illuminates how resistant the community is to... reading and doing work in the easiest, pragmatic way possible.

My point is that you were entirely wrong. Web Components are not ready for primetime, they are half baked. If they were the easiest and most pragmatic way possible to build web applications people would do so.

The only thing they are the easiest and most pragmatic for is to build a simple non-form associated component that can be used across frameworks. Like a card.

> It has always been a chore in one way or another.

It's actually never been a chore to make an behave properly. Something that literally every component library needs to do.

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

#437

Post by iyc_ »

lpghatguy wrote: post #13

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

> 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 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 (
    
    ... 
    
    
    ... 
  );
you can use functions and loops:

  function displayTODOs(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 (
    
    
    {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.

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

#438

Post by mst »

asselinpaul wrote: post #417
mst wrote: post #390

Earlier quoted context omitted.

I have hit a point where I've moved my browser from running locally on my laptop to running on a hetzner dedicated server over VNC because it performs ridiculously better so "readily available" is apparently an unfortunately variable claim. I would note however that my laptop is not entirely recent and I'm using firefox and my big pain point has been React Native Web apps like web twitter. So you're likely still most…

what are you using for VNC with hetzner? interested in trying this out

https://tigervnc.org

Does some impressive compression tricks that results in it being remarkably snappy.

You may prefer to run Xvnc directly rather than use the wrapper script, depends how you want to set everything up.

I will be honest here that my setup is not properly automated yet because it's inside a jail on a FreeBSD install and the underlying box gets good enough uptime that my current half-assed approach hasn't yet annoyed me into finishing it.

There weren't any interesting gotchas though.

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

#439

Post by depressedpanda »

LAC-Tech wrote: post #175
stocknoob wrote: post #67

Earlier quoted context omitted.

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

Weird. I'm not British by I say "used xyz in anger" because I read lots of other programmers saying it. Had no idea it was regional, thought it was hacker lingo like "grok".

> thought it was hacker lingo like "grok".

How is grok considered hacker lingo? I would think other people than hackers have read Stranger in a Strange Land.

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

#440

Post by zbentley »

mst wrote: post #374
stocknoob wrote: post #67

Earlier quoted context omitted.

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

Speaking as a british programmer, if a given piece of software hasn't made me yell expletives at the screen at least once, I probably haven't done something sufficiently non-trivial with it to count as "used in production" yet. But then again even by british standards I am unusually sweary when writing code.

Nope, you get it. Both you and GP are saying the same thing, I think.
Post reply on HN