Live data from Hacker News

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

typeofnan.dev

311–320 of 444 posts

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

#311

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…

I've been in the industry since the days of VB6 (which I loved). I've never been more productive than I was with VB6 and WinForms. That said, UI has always been a mess, even then. The more feature-rich you want your UI, the gnarlier and messier it gets. Everyone always likes to blame the front-end engineers for being slovenly, but my experience is that; UI is just messy. It's just hard to program cleanly. Not to ment…

[deleted]

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

#312

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…

True but backends are not always refuge. The back end Java version at my company would have a DI container, a few interfaces, factories, configuration files, custom attributes and a few random library dependencies thrown in.

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

#313

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…

> "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 made in their implementation of hooks. Hooks were badly needed, no doubt, but often times an okay solution to a really serious problem can look like a great solution.

The back end went through a lot of this already. That's why the patterns are more stable there, and why you feel less churn. The front end is exciting precisely because there's so much to still figure out!

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

#314

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.

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.

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

#315
post #87

This article hits on something I've felt for a long time. The idea that "hooks are superior" to me is ridiculous. If a linter is required to tell me when I'm writing a bug that is not immediately obvious, that is a failing in the framework to round those edges. Lints are not rounded edges! Solid is nice and _seems_ to fix the issues with hooks, but as another comment mentioned, the challenge is with building at scale…

React would work well as a compiled to metal language. Instead we end up with React on Typescript on ES6 on ES5 on the browser that still only has one language targetable. We're shackled to a rocketship in motion desperately monkey patching the engines.

We can at least eliminate ES5 now that IE is dead.

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

#316
post #298

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

> IMO there's significant complexity in building a feature-rich frontend client.

Doing complex things is always complex, but when SIMPLE things are complex, then something is going very wrong.

And this is exactly where we are with most JS frameworks these days. Layer upon Layer of abstraction, and instead of the complexity the dev has to deal with decreasing as a result of it being abstracted into frameworks offering simple interfaces, complexity increases.

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

#317

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…

I've been in the industry since the days of VB6 (which I loved). I've never been more productive than I was with VB6 and WinForms. That said, UI has always been a mess, even then. The more feature-rich you want your UI, the gnarlier and messier it gets. Everyone always likes to blame the front-end engineers for being slovenly, but my experience is that; UI is just messy. It's just hard to program cleanly. Not to ment…

I have been in the industry since punch cards were a thing and servers took up multiple rooms. I've never been more productive. UI has gotten a lot better since those days and I have migrated my efforts to use frameworks such as Vue.js which is sofar the most elegant and modern approach for doing UI work. Creating a desktop app is very easy with electron js although beit a bit heavy and not the most effecient in terms of memory, cpu cycles, etc but it's easier than punch card days I used to enjoy.

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

#318

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…

Seems a bit odd to call the version that repeatedly calls the constructor an OO pattern.

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

#320

Earlier quoted context omitted.

Yes hooks are not great. They violate too many functional programming rules that the react team pretend to care about. I still like using them however. I had a few issues when trying to do more abstract code.

I don’t understand why people think react hooks are meant to be ‘functional’. They are highly , deliberately , emphatically procedural. The order they are called matters! The time of when they are called matters! The number of times they are called matters! You get a different result from calling the same hook with the same arguments at different times! You get different results if the call site for them is in differ…

> I don’t understand why people think react hooks are meant to be ‘functional’.

Because when function components first came along that's what the whole of React was supposed to be: "functional" UI, using things like redux or mobx for state. Plenty of guides still use that terminology even though React's homepage now uses "declarative".

That said I think they were always misusing the term, I remember this because I used to complain to people that react itself was declarative, not functional, and just gave the option of writing in a functional style.

Post reply on HN