Value proposition is “components for server”. But it’s worth to take a step back first.
What is value proposition of react component in comparison to older “mvc-inspired” frameworks? That you can drop a component in your code and call it a day. Don’t need to wire up separate controllers, models and views. Just one thing.
Now, if you want to add “auth” to your app (in react meta framework like next) you need to add component and probably add some routes and inject some middleware. With server components, you just add one component somewhere in the root of your app. Just one thing.
All that over the wire format, suspended data fetching etc, are a result of solving that problem and keeping in mind that those components are slightly different. It takes more work, but in return we can interleave both types of components nearly freely.
Sorry, having trouble understanding the nuance of the auth example (FYI in react I have experience only in small scale projects).
What’s the difference in classic client components having a root component validation auth?
Sure! In some methods of authentication, like OpenID, not only your client need to present some UI, but also you need to prepare some endpoints on the backend to handle full flow of authentication. You probably also need to provide some parameters to those endpoints and methods inside.
So again, you want to add one thing “auth”, but need to add code in multiple places in your app. Server components promise to encapsulate that. Idea is that you can grab a component from npm, and it will handle all of that orchestration for you, and component will be your only one interface, so all configuration can be passed as props (of course it will be taken from your env/secret).
The promise is that you can encapsulate inside a components both client and server code.
Ok I probably need to read deeper into server components and look at specific implementation.
Your saying that the same component, in the client makes sure that you have a live session (a la JWT in local storage), but in the backend checks that the client requests arrived with the correct credentials?
Kinda? I’m starting to regret using auth as an example! Dan recommended Sam’s talk to you. He explains that with better examples and more clarity than me.
Reminds me of karet [0]. I used it with great success for making interactive visualizations. This duality of passing a value or passing a stream of values was great.
Over the years I took part in few similar discussions. Almost every time argument against regulations was “but alcohol prohibition in USA made things worse”. I don’t have knowledge, but intuitively I’m not sure if it’s really that bulletproof argument. Have someone any thoughts? How to approach that critically?
I had a lot of fun using squint with solidjs. It pairs so well with minimal, focused libraries. Maybe it doesn’t give you any superpowers but make code a little cleaner and steer you away from few traps.
On my “nerd snipes” list I have project that merges squint and hwy framework. It sounds like bleeding edge for the sake of bleeding edge, but on the other hand sounds so compelling!
Don’t you mix up „Almost Lost” with „Lost World”? qztourney6 is kinda linear and rail heavy. And wasn’t in standard map pool too long. But I admit, I had a lot of fun playing 2v2 there!
What’s your experience with StarLite IV? I’m thinking about buying it for heavy note taking - neovim/obsidian/browser (Google docs and excalidraw). What battery life I can expect? Is keyboard nice to type? Is stuff like sleep, Wi-Fi auto connect and bluetooth headphones really solved?
The keyboard is very nice. Short travel for keys but pleasant to use. I use iwd as the wireless deamon and wifi autoconnect works just fine. I do not have bluetooth headphones so cannot comment on that, but my bluetooth mouse works as expected.
Battery life depends largely on how you use it. I have a minimal setup with alpine linux/i3 and just typing in a terminal with screen at 33% brightness results in battery-reported power consumption of just under 2W which is great. Obviously a browser like firefox will impact it quite a bit. Hardware-accelerated video playback works fine.
There are a few minor downsides: the built-in speaker is quite awful (not a consideration for me), the webcam is not great and the microsd card reader is usb 2.0. UEFI secure boot is currently not supported on the coreboot fw. The documentation is sparse.
One weird gotcha is that the power button is one of the keys on the keyboard, so to avoid suspending your device accidentally it will only fire an interrupt after you hold it for a couple seconds. Took me a while to figure out.
That's basically my use case, and I'm quite happy. Battery life for me usually is somewhere between 6-7 hours. The keyboard is pretty decent - not quite as good as a Macbook keyboard or similar low-profile keyboards (e.g. Logitech MX Keys line), but good enough, though the oddball arrow key configuration and sizing for the right-hand Shift and Fn keys is a frequent annoyance. Sleep and wifi auto-connect work well for me on Ubuntu 22.04 w/ KDE Plasma. Can't vouch for bluetooth headphone usage, because I don't really use bluetooth with this device.
I was helping with an application that used htmx and had two issues. I’m wondering if anybody had similar experience and if these issues are from misusing technology or maybe there’s some ongoing work to address them.
1. A lot of custom middleware in controllers to decide if endpoint should return HTML for whole page or only fragment that htmx needs. On the side of htmx that sounds simple but it is something that probably every project using htmx have to reinvent.
2. Bookkeeping around `hx-trigger`. If UI is getting complicated, many elements need to react to external changes. Instead of reading some state and hope that framework will schedule updates, I have to manage a list of events to react by hand.
What is value proposition of react component in comparison to older “mvc-inspired” frameworks? That you can drop a component in your code and call it a day. Don’t need to wire up separate controllers, models and views. Just one thing.
Now, if you want to add “auth” to your app (in react meta framework like next) you need to add component and probably add some routes and inject some middleware. With server components, you just add one component somewhere in the root of your app. Just one thing.
All that over the wire format, suspended data fetching etc, are a result of solving that problem and keeping in mind that those components are slightly different. It takes more work, but in return we can interleave both types of components nearly freely.