thewix

That's the point. They are by far the largest player in the game, and can ( and do) use their size to squash competition. You don't have to use their marketplace but as a small business you don't have many options that can compete.

Hell, they're even extremely anti-competitive with their employees. Their NDAs are very restrictive and have threatened non-senior employees with them, even ones that they let go.

Got anything to back that up? Businesses managed to thrive before when taxes were considerably higher. How do you account for the Gilded Age? How were those monopolies different than today and how did taxes and bureaucracy exacerbate issues then? Because there are many parallels between them and now.

Cept the part about Amazon not letting you sell your goods cheaper elsewhere. That keeps the price inflated and is anti-competitive since it squashes competition from other marketplaces, not because their platform is better, mind you, but because they have all the power.

This would be my preference. I like `Either`or some other container type, but a simple union that makes exceptions explicit works also.

Though not JSX, with TSX you get type checking with your markup.

When I was trying to learn monads no one ever gave me an example of mapping a list-returning function to a list. Everyone went on about 'effects', monad laws, etc. For some of us it's best to work backwards from something concrete and then show why the laws are important.

I love how simple most things are in FP compared to OO. I also hate how poorly FP concepts are explained.

I'm not saying you're wrong about people learning terminology. However, you definitely get more strange looks from FP terms than OO terms. Class, interface and object are common terms. When I mention a word like 'monad', 'monoid', 'magma', or 'functor' people look at me like I'm nuts. It's not logical. A new word is a new word. It's just FP words sound almost alien and trigger extra confusion in people.

I prefer functional. Procedural is not restrained enough and allows for mutable global state. This can go off the rails when multiple people are in the code.

Functional stresses composition so functions should stay small, and ADTs allow for all effects (errors!) to be represented. Strong typing helps reduce the number of tests I need to write, as well.

This is why I use codec libraries like zod or io-ts (purify has them built in also) at my boundaries.

Sorry, I should have said JSONB. Do you still consider a table with a single JSONB column SQL or NoSQL? Sure, it may be contained within a RDBMS but you are treating it more like a document store than a relationship database.

You get JSON types with postgres. If you aren't sharing data between tables then json is fine

Common in the States too. I'm from Eastern MA and work in Boston. If I order a "vodka, soda" it sounds normal, but if I say "vodka AND soda" then "vodka" becomes "vodkar". My accent is a pretty standard Eastern New England accent.

Gotcha. I may have to give HTMX a try again. Though, I worked on a HAL-based, full RESTful service back in 2016 and I'm not sure how eager I am to go back.

REST was ok for the read-side of things, but for writing I find RPC/commands to be better than PUT/PATCH. Combine that with the lack of framework for HATEOAS made full REST APIs cumbersome at the time, though things may be different now.

Doesn't HTMX work via HATEOAS so would require a full RESTful backend?

It should be: start with a well architected monolith, and then slice things into microservices when you need to. Fowler and many Microservice evangelists even say to start with a monolith first, because you don't know the correct slices at the beginning.

EDIT: I suck at writing coherent messages on my phone.