DEV Community

Discussion on: Of Chickens and Pigs - The Dilemma of Creator Self Promotion

 
dasdaniel profile image
Daniel P πŸ‡¨πŸ‡¦

I also wonder if this just a matter of survivorship bias. There are likely many other devs that have read your articles and have found them interesting and see the benefit of SolidJS, but don't communicate that and don't contribute to the library. Yet the critics are the ones that are heard, whether their criticism is valid or purely opinion/perception based, such as the comment in the video.

On a side note, I did try to implement solidjs in a project where I needed some minimal reactive and templating functionality. But found the behaviour of one of the hooks was not doing what I expected (that's 100% on me though) and ended up using Preact instead, which got me to the goal faster. I don't regret the decision, since performance there is not a concern, but it makes me wonder if there are others that have had a similar experience, essentially weighing the tradeoffs of implementation time vs performance and chose to go with a familiar framework, especially one that is better supported.

Thread Thread
 
ryansolid profile image
Ryan Carniato • Edited

I talk about the criticism a bunch in the article but generally not phased by it. Comes with the territory. I have felt no shortage of support from those interested in the projects. And I'm perfectly content with the rate of adoption to date. I did not write this to draw attention to the haters, but to express my challenges with finding the balance with self-promotion.

Solid is still pre-1.0 (but not for much longer). Big gaps still on documentation/onboarding. I haven't been going around saying hey you should be using Solid in your project. So good on you for finding a good solution with Preact. I've only been pointing people to the ideas thinking that it might be something of interest.

That's why the self promotion thing just felt really off to me. I mean it is I guess since my libraries handle stuff the way I'm promoting. But it isn't an active consideration.

I want to see the best technologies win. But it definitely aggravates some people. I do have an issue though and this probably the point of the friction. Misinformation really sets me off, especially when repeated back almost as a religious mantra in support of technology decisions. Obviously I build technology that reflects my understanding, but I'm not playing an angle, which I think is hard for an influencer appreciate.

I think it is about time to write an article about how the VDOM isn't Pure Overhead. Or maybe better Components are Pure Overhead. I'm sure that will go over well...

Thread Thread
 
brucou profile image
brucou

My issue with all this is that I don't see it as being so practical. At the end of the day, folks are trying to write web apps. vDom is an implementation detail and I have little interest in it. I have even less interest in vDom battles. Performance on microbenchmarks, unless we are talking about an order a magnitude is mostly irrelevant to me. I dont care if the best technology wins (whatever best means, and whoever makes the jury that declares the winner). I just want to write a web app and not die in the process. Of course that is me, and I can't speak for all the developers. So your mileage may vary.

You have other things to think about besides making things performant when you haven't wrote the thing in the first place. You haven't even defined what that thing is that you have to write. That is where you want to spend the time. And you want the shortest distance between what you figured out that should do, and the implementation. That's where the quality is. That is where the value is.

I found Solid's version of reactivity great, not for the performance, but for the equational thinking (I'll have to expand on that one day - the long story is here infoq.com/articles/functional-ui-s...) it enables. I was thinking to write a DSL that would take those equations but I met some issues with both Solid and S.js that I believe revolve around concurrent access of both present and past values (another long story - I was unsuccessful in implementing the chess game in the linked article by directly translating the equations). If I solve that one day, I'll be using Solid or whichever solves it forever.

Long story short, let's focus our energy on the things that make a sizeable difference.

Thread Thread
 
ryansolid profile image
Ryan Carniato • Edited

Technology is definitely secondary, but there are still benefits to having the best solutions rise to the top. And it can open up limitations, things we considered not possible previously. It also can serve as an excuse for not exploring new possibilities, so it can cut both ways.

I'm glad you pointed out the model with Solid made a lot of sense since my work often just gets associated with performance. I wouldn't have explored it in the first place if I didn't believe in the model. But to be fair if the results weren't so good I might have moved on and looked at other options.

It all adds up. Progress isn't always in huge strides. Granular approaches lead me to understand a way to escape the component model. This frees us from tying our performance to the way we structure our components. This in turn impacted research into reducing shipped JavaScript. More so that the language of reactivity is the benefit more than the runtime model. This has implications on how we view compilation output and how we look at our languages. Which opens up the question of the patterns we use for writing and maintaining code. It's all related.