Putting some files in dev dir.
Properly namespacing source files.
Naming of recursive helper functions.
Naming of functions that convert custom errors to string.
Structure of project that has both backend and frontend in gleam.
For me the problem is triggering effects implicitly by observing state changes. It makes the system unpredictable and hard to reason about. Effects should always be triggered explicitly.
I think Elm got this right. We use xstate/store which follows the Elm architecture making this much easier.
Reading about the new useEffectEvent in react.
This is throwing more stuff at trying to improve a bad fundamental pattern (reactive effects via useEffect).
If you use TEA (the Elm architecture) none of this is necessary.
stately.ai/docs/xstate-... in a great implementation for React.
Right now Gleam. Love Elm but not very active. I have also tried Haskell, OCaml F#, Unison and Clojure.
I like it but I cannot deal with not having an explicit step for staging changes.
I usually make changes that aren't meant to be committed.
At work I have to use TS ATM. Elm is much better here.
But I have found that there is a subset of TS that is quite decent. As long as we don't use certain things and set every setting to the max the type safety is good. It just needs a lot more diligence.
I find the Haskell style type signature easier to read, specially with lots of arguments. I wish more langs adopted this.
I find the automatic ghost text behaviour when using copilot very distracting.
So a couple of months ago I changed that to be an explicit shortcut.
But I noticed that since then, I hardly use it. Maybe it wasn't that useful.
Disillusioned on the new Fujifilm X-E5. Reading the specs the viewfinder is quite disappointing. As I only use the EVF this is really important to me. I was really hoping that they would make a small camera with a great EVF.
More specifically
- message based, no business logic or effects in the view
- effects and model updates must be in the same place
- local or global store
- great type safety
- avoid react useEffect as much as possible
I looked at xstate/store before for React state management. stately.ai/docs/xstate-...
But in V3 they added side effects handling. With this addition is mostly the perfect state management solution I want. Trying it in our app.
Pretty much what I'm looking for is Elm TEA in react.
The previous Mission impossible was pretty good, I really liked it. So I went with high expectations to the new one. Unfortunately it was quite mid. A lot of nonsense, completely unbelievable stunts, very brain dead.
Definitely some pros of the microservice architecture like
- Failure isolation
- Independent scaling, versioning and deploys
But there are huge tradeoffs for me:
- Lots of incidental complexity and repetition
- Weak contracts
- Very high maintenance burden
- Harder to work with and refactor
Geez, we have gone so far on the microservices path that a lot of our business logic is in freaking cloudformation yaml files.
Do we process x for a customer? Need to look at CF yaml. It is like a terrible and untested programming language. I hate it.
People keep repeating that React is "functional". Maybe at the beginning it was or I just don't understand their definition of functional.
Components can have lots of non explicit inputs with hooks. Which can get global mutable state from lots of spaces.
We use conventional commits everywhere.
www.conventionalcommits.org/en/v1.0.0/
However 'feat' is often used for user facing features and internal features. Gets confusing.
We need a distinction. I rather not use the scope for this.
Trying to find a good word for 'internal feature'.
I have been refactoring our React forms to use TanStack Form. Our current lib is poor at type safety.
I found it interesting that you need to explicitly subscribe to state all over the place (to avoid re-renders). Otherwise the view is stale.
One big promise of React was not having to do this.
I have been building an app with Datastar. I'm quite happy with it.
This is a great intro chrismalek.me/posts/data-s...
I still have one complex interaction in my app where a front-end framework like Elm is better.
But for the majority of interactions Datastar is excellent.
Having a go at building an app with data-star.dev
It is like htmx but can do more things.
It took me a while to understand how to send responses from the server.
So far I'm quite happy with this.
broot looks great, similar to yazi. It is just figuring out the configuration that puts me off.
I tried github.com/josephschmit...
Got a bunch of errors, and gave up.
Somedays, like today, I attempt to use Helix for editing. As Helix is great for navigation and many other things.
But the lack of a file tree is a huge downside. I don't want to figure out how to configure helix and zellij and yazi together in order to have a file tree.
What libs are people missing
Now I need to deal with Headless UI too which is also outdated. At some point someone decided to use a new component lib (headless UI) but they couldn't be bothered removing the old one (material UI).
Just finished a grueling two months of work removing Material UI from this app.
Leaning so heavily on a component lib like this was a huge liability. Made it impossible to upgrade other things.
Now it is mostly vanilla html and some Radix components for the hard stuff.
Text editor, browser, terminal, slack, discord, git UI, outlook, ms teams, email client, photo editors
Off for a holiday for three weeks. Don't need to look at Typescript for a while, win :).
100% Elm Is vastly superior.
But I cannot imagine maintaining our React apps without Typescript.
Each year the kids' school change the required books or editions. Making us buy new books. They just tell us to discard the books we already have from the older kids. Incredible waste (and spend), so annoying.
The user interactions, as what flows are possible. I make a state machine in my head. Then the data structure that support that.
blog.erodriguez.de/dependency-m...
I empathize a lot with this. But moving to a different stack is not an immediate possibility for us. So instead my strategy has been to replace libs with of our own implementations. E.g. our own router, query string parser, form lib, etc.
