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

Solidjs – JavaScript UI Library

solidjs.com

Post reply on HN
Print view View original

81–90 of 92 posts

Re: Solidjs – JavaScript UI Library

#81

Post by eyelidlessness »

ryansolid wrote: post #76
mikevm wrote: post #54

Earlier quoted context omitted.

Yes, any idea why that is?

More than likely it's the lazy loading of the REPL. Those code editors are heavy and when they scroll into view they need to load. If we load up front it would drastically tank the load performance for people just visiting the site. It's possible on mobile we should opt for a click to load strategy. There is very little we can do about this once we do go to load, it's just the nature a heavy fully featured editor lik…

I wonder if you could share a single Monaco instance across multiple editors with some kind of twoslash chicanery behind the scenes. The TypeScript Playground recently got support for “multiple files” via twoslash comments; it’s kind of buggy but may work with some finesse.

Re: Solidjs – JavaScript UI Library

#82

Post by pier25 »

lhorie wrote: post #67
pier25 wrote: post #55

Earlier quoted context omitted.

Mithril is reasonably fast, but there are plenty of faster options like Solid, Inferno, Preact, or Svelte. https://krausest.github.io/js-framework-benchmark/current.ht... IMO the best thing about Mithril is that it doesn't have reactivity, much like Imba. This allows you to define state with pure vanilla objects and classes. Also that it includes an HTTP client and router in just 10kB. It's really verbose though comp…

[Mithril.js author here] FYI, the krausest benchmark is known among framework authors to be not very good (it weighs some aspects much more heavily than others and has been gamed by various toy-ish "frameworks" that aren't all that practical in real life). With that said, people obviously use React and even Ember (which are on the slower side of the krausest rankings) out in the wild and they're generally fine framew…

Hey Leo

I agree with all your points, of course. I don't think I ever stated that Mithril was slow or verbose in an absolute sense.

Re: Solidjs – JavaScript UI Library

#83

Post by nawgz »

eatonphil wrote: post #51
nawgz wrote: post #8

Earlier quoted context omitted.

> I've been getting more and more scared of destructuring and ... copying recently Well, certainly it should be clear that `obj !== {...obj}`, and you have to behave accordingly. In reality though, assuming you are destructuring to pass it down a tree (and not around the app), this usually just means that you lose the optimizations of only rendering some part of the subtree and render your whole subtree more often, w…

> Well, certainly it should be clear that `obj !== {...obj}`, and you have to behave accordingly Sure but that's not my issue. I'm saying that when you copy an object like you just did, the latter object looses its prototype. So any prototype methods I try to call on a copy/de structured object like that will crash in my app without a prior TypeScript warning. I want to be able to copy objects with a nice syntax but…

> > Well, certainly it should be clear that `obj !== {...obj}`, and you have to behave accordingly

> Sure but that's not my issue

I think you misunderstand what I'm saying. I know you know `obj !== {...obj}`, but it's important to understand exactly what that means, and one of those things to understand is

> when you copy an object [via destructuring], the latter object looses its prototype

For example, any class instance should most certainly not be used in that way, as it moves away from a true "object" paradigm (keys and values baby) into an inheritance paradigm, and as you observed inheritance is lost in destructuring.

> TypeScript doesn't warn you

I find this hard to believe. If you are passing TypeScript some interface T, and the object {...tInstance} doesn't have the keys of T, you should get an error. If you are passing TypeScript some class X, and you try to claim `typeof {...(xInstance)} === X` you would also surely see errors.

Please link an example so I can understand what I mean, I would guess you didn't type the destination very stringently so the loss of the class type was unobserved

Re: Solidjs – JavaScript UI Library

#84

Post by eatonphil »

nawgz wrote: post #83
eatonphil wrote: post #51

Earlier quoted context omitted.

> Well, certainly it should be clear that `obj !== {...obj}`, and you have to behave accordingly Sure but that's not my issue. I'm saying that when you copy an object like you just did, the latter object looses its prototype. So any prototype methods I try to call on a copy/de structured object like that will crash in my app without a prior TypeScript warning. I want to be able to copy objects with a nice syntax but…

> > Well, certainly it should be clear that `obj !== {...obj}`, and you have to behave accordingly > Sure but that's not my issue I think you misunderstand what I'm saying. I know you know `obj !== {...obj}`, but it's important to understand exactly what that means, and one of those things to understand is > when you copy an object [via destructuring], the latter object looses its prototype For example, any class ins…

I can't reproduce what I'm saying! Well that's interesting. Thanks for pushing me.

I wonder what I was seeing in my code...

Re: Solidjs – JavaScript UI Library

#85

Post by nawgz »

eatonphil wrote: post #84
nawgz wrote: post #83

Earlier quoted context omitted.

> > Well, certainly it should be clear that `obj !== {...obj}`, and you have to behave accordingly > Sure but that's not my issue I think you misunderstand what I'm saying. I know you know `obj !== {...obj}`, but it's important to understand exactly what that means, and one of those things to understand is > when you copy an object [via destructuring], the latter object looses its prototype For example, any class ins…

I can't reproduce what I'm saying! Well that's interesting. Thanks for pushing me. I wonder what I was seeing in my code...

Cheers, good luck to figure it out.

Re: Solidjs – JavaScript UI Library

#86

Post by alserio »

richeyryan wrote: post #57
dzonga wrote: post #47

ryan, is a cool guy. but I feel like a lot of work they're doing on marko, will be much better than solidjs. solidjs api is non-intuitive, same as the reactive system say compared to svelte. Hooks are already a bad idea in react, for reasons I will not expand on. And having the same concept in solidjs isn't progress at all. Svelte nails reactivity, it's something you don't think about.

I think you need to take a second look at Solid. It isn't subject to the same "rules of hooks" as React so hooks are really just functions that return reactive units. You could argue writable and readable are just hooks for creating stores. It's reactivity is fairly similar to Svelte from there. There are stylistic choices with Solid choosing a function style and Svelte abstracting that with proxies and allowing a mu…

Svelte doesn't really use any kind of proxy. It instruments its code with explicit invalidations and scheduled updates. Mutations are tracked "lexically" intra-component with static analysis or with explicit functions when using stores

Re: Solidjs – JavaScript UI Library

#87

Post by filoeleven »

I read this article[0] which was written by the framework’s author. It looks like it gets closer to “reagent in plain Javascript,” which is pretty great.

JS development would benefit greatly from a native “immutable, nestable, performant, deep-compare-by-value” data type that supported something like these operations:

  atom.get(path) 
  atom.set(newValue) // returns new atom
  atom.set(path, newValue) // returns new atom
By handling this type in the JS engine, you can take advantage of HAMT to make this quite performant[1]. The “single-global-state atom” pattern is a point of convergence, and it would be nice to have native speed instead of relying on one of the many libraries that reach for it, each with their own trade offs. (SolidJS uses proxies for this.)

It should be a language-level abstraction. I suspect it would be rapidly adopted by a lot of frameworks, and we’d all benefit from it.

[0] https://javascript.plainenglish.io/designing-solidjs-immutab...

[1] https://en.m.wikipedia.org/wiki/Hash_array_mapped_trie

Re: Solidjs – JavaScript UI Library

#88

Post by richeyryan »

alserio wrote: post #86
richeyryan wrote: post #57

Earlier quoted context omitted.

I think you need to take a second look at Solid. It isn't subject to the same "rules of hooks" as React so hooks are really just functions that return reactive units. You could argue writable and readable are just hooks for creating stores. It's reactivity is fairly similar to Svelte from there. There are stylistic choices with Solid choosing a function style and Svelte abstracting that with proxies and allowing a mu…

Svelte doesn't really use any kind of proxy. It instruments its code with explicit invalidations and scheduled updates. Mutations are tracked "lexically" intra-component with static analysis or with explicit functions when using stores

You're right, I think I meant something more like proxy style mutation. It does of course compile down to functions operating on stores which is even more like Solid

Re: Solidjs – JavaScript UI Library

#89

Post by deepstack »

lhorie wrote: post #67
pier25 wrote: post #55

Earlier quoted context omitted.

Mithril is reasonably fast, but there are plenty of faster options like Solid, Inferno, Preact, or Svelte. https://krausest.github.io/js-framework-benchmark/current.ht... IMO the best thing about Mithril is that it doesn't have reactivity, much like Imba. This allows you to define state with pure vanilla objects and classes. Also that it includes an HTTP client and router in just 10kB. It's really verbose though comp…

[Mithril.js author here] FYI, the krausest benchmark is known among framework authors to be not very good (it weighs some aspects much more heavily than others and has been gamed by various toy-ish "frameworks" that aren't all that practical in real life). With that said, people obviously use React and even Ember (which are on the slower side of the krausest rankings) out in the wild and they're generally fine framew…

> run into cognitive dissonance about the semantics of your primitives

Thank you for stating that. Seems like Mithril isn't just fast for processor, rather it is a fast for mental processing.

Re: Solidjs – JavaScript UI Library

#90

Post by pier25 »

deepstack wrote: post #89
lhorie wrote: post #67

Earlier quoted context omitted.

[Mithril.js author here] FYI, the krausest benchmark is known among framework authors to be not very good (it weighs some aspects much more heavily than others and has been gamed by various toy-ish "frameworks" that aren't all that practical in real life). With that said, people obviously use React and even Ember (which are on the slower side of the krausest rankings) out in the wild and they're generally fine framew…

> run into cognitive dissonance about the semantics of your primitives Thank you for stating that. Seems like Mithril isn't just fast for processor, rather it is a fast for mental processing.

I always say Mithril is a sushi chef knife. It's wonderful if you know what you're doing, but you can cut yourself badly if you don't.

In more popular frameworks like React, Vue, and Angular, there are multiple tools that give you a structure. In Mithril you're free to do whatever you want.

Personally, I love that freedom. It's also one of the reasons I love Svelte, since it tends to get out of the way.

Post reply on HN