dhucerbin

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.

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.

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.

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.

[0] https://github.com/calmm-js/karet

May I interest you in hwy.dev?

That's the moment where you wipe your hands and compose yourself after restart because of failed canonless!

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?

What do you use now, on iPad for drawing?

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?

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.

Anybody had similar impression?

I was growing up in Poland in the height of John Paul II cult. I was raised in atheist family and I was getting some tidbits about my grandfathers brother who was sexually assaulted by a priest.

Today it sounds a little bit silly but that SNL performance was the validation I needed to navigate my environment outside my home.

Now I learned a lot about issues in Catholic Church and I understand this stuff better but I’ll be forever grateful for this small gesture of solidarity. Even if it wasn’t directed at me.

Is it possible to get on Phoenix nested controllers? Like in remix.run, where for each route segment we get one controller/view. It’s really generalised version of layouts.

When I was looking into Phoenix all routes, no matter how nested, had to resolve to single controller. That meant that controller for path `/user/settings/privacy` was also responsible for getting data to display users sidebar.

If I wanted to build a single page application, I would absolutely, 100%, write it in Elm.

I find this interesting, because SPAs in Elm are more like exercise for the reader. If you look how NoRedInk uses Elm you will see that’s more like one “app” per REST controller [1]. Do you have some experience with specific solutions that you could share?

[1] https://juliu.is/elm-at-noredink/#rails-conventions

But React doesn’t prohibit calling Intl API in your code.

Quintessential experience of talking to Elm core team: https://github.com/elm/compiler/issues/1773#issuecomment-418...

What's funny, rtfeldman uses case expression with numbers in his (in OP's blogpost) praised library elm-hex, so it's not the problem of numbers vs variants. Only negative numbers are the problem.

There’s still https://www.lenstip.com/. English version of Polish site optyczne.pl. What’s funny, team from this site criticized dpreview for being not scientific enough.

Not if your goal is correctness.

Could you define correctness in this context? I'm asking because I don't believe that you can achieve correctness using Elm type system. I don't see how you can encapsulate i18n rules inside Elm type definitions. Maybe something like Coq could do this ...

You can't express something like "if passed 3 as group size, integer part of the number should be represented as string with separators between three digits". Even in Elm that's something that you need to handle not in type system but in runtime code.

What is more - many core packages are just this - typed layer over browser API. elm/regex introduce barely any type safety. It assumes that browser API is "correct".

Again, it is completely OK that Elm is not your choice if it does not align with your values, which appears to be the case.

I often see this response from Elmers but really I don't understand the point of it. I responded to claim that Ports solve all problems. I provided good, real example where Ports are a bad solution. In return I was scolded that I don't understand software engineering.

I don't jump into elmconf and complain or demand changes. I just provide my take on the discussed issue. And to be frank, I think that's very valuable take for someone who decides if Elm is good for them. That kind of information is not present on elm homepage and is not obvious for new users.

but it also seems to be a natural consequence of "up-typing" an entire eco system.

Reimplementation of i18n API in Elm would make sense only if benefits from types could outweigh robustness of browser implementation. Due to not very expressive Elm type system I really doubt that. You can’t capture intricacies of i18n in Elm type system.

I have more confidence in already tested and used by millions API in the browser than in reimplementation in niche language.

Elegant solution would be if I could write well typed layer that calls browser API. Low bar of entry would drive adoption and in effect real world test. But that’s not possible anymore.

Actually both.

Let's say that on desired page, you have three components with dates somewhere - date of article, dates of comments below and date of last login in the header.

After some user action, you navigate to this page. In Elm terms that mean your Model updates and then your rendering functions will run.

Only then you can see that you need to format dates - your rendering function should be responsible for formatting.

Rendering function should be synchronous - so you need to return some string for date - "loading state" or default format. So user gets "flash of unformatted date".

Now, you should somehow communicate with Port - that mean, send asynchronous message "format this date for me". (And sending messages in render function is not something really supported out of the box in Elm)

Then Port comes back with response, you need to put this formatted value in your global Model (some kind of Dict from unformatted to formatted dates?) and that triggers another render with formatted value.

In summary: - you have multiple render loops where one would be enough - you pollute your global Model with junk that could be easily derived - you introduce latency in rendering because Ports are asynchronous

Ports are great for interaction - user clicks something, you can send command and wait for response and update your model. But there are a lot of cases where you want use synchronous, pure function from Javascript like Intl API.

Ports are not really a solution for rendering code. Obvious example is internationalization API. It’s not feasible to communicate back and forth through port every time you want to format a date.

Some folks propose web components but that’s another can of worms. Increase in complexity and still no help from compiler.

I want to pivot my career to teaching. I get a lot of satisfaction (and ego boost!) from it but language was a big obstacle for me. I was very aware of my English and it was very frustrating how I can express myself in native language but I mumble in English. Last year I switched my surroundings from native speakers to people like me - with English as second language. It was a great confidence boost. I was mentoring people in DataViz Society and have two lectures about visualization. Now I’m preparing my course about creating data visualization on the web. I can do this on my company time so I’m free from thinking about profits and marketing - I want to run this for free. In the end it is aimed mostly at folks who change careers to programming without company learning budgets.

Fantastic news! Although I loathe writing libraries [1] in Svelte, I love writing apps and kit is great extension to server side. I like similar to Remix push for Web APIs, like forms for mutations etc. I like nested layouts with data endpoints. I like that most of the internal state is visible as reactive store.

[1] Creating complex type definitions for more generic components is hard and require knowledge about internals.

It’s https://solid-movies.app/

I'd consider myself part of the community. I advocated for Svelte and lead two projects in my company, I spoke about Svelte at meet-ups and I did some mentoring around svelte and data visualisation.

And I agree with you. Rich has strong opinions and he likes to stir some discussion. And that's fine, he always responds with nuance and mutual respect. Problem is when community parrots his one liners. If I had a nickel for everytime I got yelled with "vdom is pure overhead!" or "jsx is an abomination, my templates are pure html".

In the end I'm not even sure if it is something specific about Svelte, or just any non-react solution has to bash React loudly.

There is Gren, but I didn’t use it.

https://gren-lang.org/

Listing template dependencies as event names that can change underlying data seems very brittle (hx-trigger for favorite articles). You would need at least integration tests to get some confidence! Can’t we infer used state in template and setup triggers for developer? LiveView gives better DX in this case.

I have to disagree. Elm especially needs to be updated. That’s because Elm limits your interactions with browser. You can’t use browser APIs in Elm. (We can nitpick that ports and web components are some form of an escape hatch)

Internationalization API is a great example. We should leverage the platform but we can’t.

Yes and no.

We found that rx.js is bad for coordination. I think coordination is a big part of services in angular UI's. You need to fetch some data, wait for it, ask for different thing, maybe change some state. Promises and await are great for this and especially await syntax is readable (go channels could be even better). In rx.js you had to nest multiple switchMaps for dependant queries and for state - you either produce state as a stream result or you put some `tap` or `subscribe` with `takeUntil`.

But rx.js shines with more complex user interactions - drag and drops, brushes, interactive forms (angular has nice, reactive form api). We even put some state machines inside streams, so input signals produced events. and we had `scan` operator that manipulated machine.

My personal issue with rx.js is that BehaviourSubject is leaky - you can do anything to it, and break it's property of 'always has a value'. It is nice if your service is a reactive value that you can inject and transform or render using async pipe. But you need to be careful what operators are you using on it.