I have occasionally been asked why Preact's string renderer doesn't do scheduling and defaults to synchronous. Here's your reason (it's so fast that doing so is generally net-negative for both response time and throughput, making it undesirable by any metric) #preact
Has anyone here got opinions about Preact vs React?
Specifically, I'm weighing up migrating a large-ish codebase to Preact instead of upgrading React, and I'd be interested to hear from anyone who a) has done this, b) has decided not to do this, c) can think of solid reasons to stick with React.
I can't see much benefit to choosing React over Preact, but is there anything I'm overlooking?
I built this POC to demonstrate how I'd use CustomEvents to implement Signals. Please criticize my approach and tell me why I need a native browser API for this.
Oh yeah, I'm doing it this week: I'm refactoring #Preact signals to a highly complex #React component.
The starting point is a component that currently takes in 26 props, and some of those props can be very complex.
And yes, that is somewhat poor original design considerations combined with 5 years of feature development on top of it. I already refactored lots of the internals 3 years ago for better functionality and performance.
Dear Dev Mastodon, I'm torn between Solid.js and Svelte for a small SPA project. I've done a lot of React dev so Solid seems familiar but I quite like the apparent simplicity of Svelte. Any opinions, advice, gotchas I should be aware of?
@prophyt If you know #react, you might want to try #preact, a lightweight, low-drama version of react. Jason Miller (@developit) - the creator of Preact -- is also active on Mastodon.
Is there an html tagged template library to render html on the server? I'm currently exploring @ lit-labs/ssr but I'd like to be aware of alternatives
Note: I don't need hydrate or client stuff, just a plain html string to string/stream/etc templating library
Non so perché, avevo voglia di provare #Preact, allora l’ho provato, ma dopo un po’ ho iniziato a rendermi conto che stava uscendo lo spaghetto… ho continuato fin quando non sono usciti addirittura bug di cui non avevo la minima idea, e allora #pazienza. Meglio fare come ho sempre fatto. 😩️
Nel #2024 le tecnologie #web#vanilla sono così buone, non c’è bisogno di usare #paradigmi strani (tutti nati quando le tecnologie web #standard non erano così buone, infatti) per #programmare… che non nego siano bellini, ma nella pratica non so perché non mi ci trovo, la mia mente sa riconoscere i pregi della #programmazione non-imperativa, ma poi nella pratica se mi cimento fo il macello… 😶🌫️️
Has anyone here switched a codebase from React to Preact?
I found switching the libraries themselves straightforward, but updating the test suite from React Testing Library to Preact Testing Library has me stumped - tests failing for reasons that are mysterious to me. At this point I'm keen to find anyone else who's attempted the same thing to compare notes...
Playing a bit with #Preact / #JSX today and am feeling the pain of not having host elements. I've realized that because a "component" is really just a #VDOM template, there is no implicit contract around what it actually rendered.
As an arbitrary example, what if I want to set a style on a <Foo /> component? What selector should I use for that style? I have no idea what <Foo /> will actually generate, or even how many top-level elements it will output. The Foo component must expose some kind of className or other API to provide this behavior, it's not implicit at all.
Maybe this is good because it provides stronger encapsulation. But it can also lead to bugs. If I render <Header /> a header CSS selector is probably right. But what if <Header /> actually renders:
<div>
<header>...</header>
</div>
Then a header selector isn't actually the top-level element and my style could easily be wrong.
Just some idle thoughts about the lack of host elements.
@jaredwhite’s personal thoughts on a great entry by @collinsworth into the growing body of work which details why greenfield #WebDev projects are better served by other frameworks…or none at all.
The most tiresome thing in #webdev is picking the techstack. So many choices to make: plain #javascipt or a more restricive language like #typescript , which ofc is often depending on the overall frontend framework to use: #svelte , #react , #preact , #solidjs ?
Or do one completly deviate from the classical way and use rather a techstack via #wasm , such as #rust with #dioxus ?
So many questions to answer and that still is only the js side of things, you then have to think about your css framework (if you want to use something like #tailwindcss ), your font choices, and ofc if and what styling library you actually use ontop of our frontend framework; e.g. #bootstrap , #blueprintjs , #tabler.io and so on.... which also often depends on your framework of choice!
I just learned Signals in Preact recently. It's so convenient to use that I'm thrilled to try it immediately. It greatly reduces the mental burden when writing code in React/Preact and usually has better performance.
Is it because code written in CSS-in-JS don't allow you to take advantage of the "cascading" nature of CSS?
Is it because you can't take advantage of selectors?
Is it because there might be some compilation steps required when employing CSS-in-JS? And if compilation isn't used, there might be some render-time slowdown?