midrus

I’ve used thinkpads (and the X1 in particular) for many years. And I do think they’re the best option you have outside of the apple ecosystem. But they are far, far, far of being an excellent replacement for MacBooks. Specially after the new Apple silicon has shown up. The deep OS integration, power saving, performance, seamless upgrades of OS, build materials quality, trackpad, audio quality, etc, etc is far ahead on MacBooks.

But I do agree they are the best option if you hate or can’t pay or aren’t allowed to use apple products.

What an awesome metaphor, 100% agree with this. That's why I've always said that the SPA architecture with a separate backend is a way to increase the amount of work so that it can be distributed to more people/teams.

It baffles me when I see single developer or small team projects going for this.

I think my job is to ship useful, secure and robust features to my company's customers. Dealing with technology is a consequence of that, not the end goal itself, which seems to be what's most wrong about this industry.

Certainly tying together libraries (or writing your own framework) is a valid approach, it's just a lot more expensive to reach the same quality level. That's why usually you end up with half assed solutions or never ending projects.

It's mind boggling some people don't know you can render plain html on the server, or even submit forms without javascript.

Such a basic building block seems to be fading away nowadays, even some times presented as a "novel" thing or a "feature" (eg: remix)

Say you're travelling back from 2099 and your comment still applies :-)

In my opinion (and experience, this architecture is great as a way to scale teams, having a clear interface between them.

As soon as you have to work on both sides of the API, it is not and advantage anymore.

I think separating the backend from the frontend is a way to increase the amount of work required in order to gain a saner way to split it into chunks for different teams.

As a single person, or a small team, doing an SPA and an API only backend, if not done for learning purposes then it is just either madness or CV padding, or something else....makes no sense at all to me.

Not my experience. Most Laravel projects I've seen are in a much much better shape than even the most minimal "microservices" I've seen around. You get so much done for you with Laravel that it makes it a bit more difficult to mess up.

I've seen microservices that had absolutely no guardrais going off the hill too many times. At my previous job "migrations" where bash scripts with SQL in them because they "didn't like ORMs and they were slow". LOL. They were handling signup form POSTs and profile updates.

Already mentioned in other replies, but as a long time node/react developer, for the last year or so I've been working on a project built with Laravel (blade components) + Unpoly (for server interactions) + Alpine (client side only interactions) and it feels like a real "cheat code". Everything is super easy, although some people think the way we do it is pretty "uncool" so they look down at you.

Next.js is easy peasy and lovely and wonderful until you need to mix in validations + translations + authentication + authorisation + calling upstream APIs with user's credentials + ...

That's when you realise using what would be a perfect framework for building landing pages might not be the best one to build a full web application.

I use Unpoly (equivalent to HTMX for your question) + Alpine and they complement each other very well.

Unpoly handles everything that requires what in SPA world would be an "API call", the difference is that the response I get is just the HTML with the data already rendered and which is dynamically updated in the DOM. Also Modals and page transitions Turbolinks style are handled by Unpoly.

Alpine handles everything that doesn't require a server API call, such as form wizards steps, dropdowns, tables filtering, sidebars, buttons loading/disabled states, etc.

The end result, the application "feels" like Github.

Don't forget Unpoly! A bit more opinionated and "batteries included" than HTMX, still same ideology. I use it every day and I love it.

> I make a difference between website and webapp.

Everyone says this, which doesn't solve anything. 99,9% of what we build is just something in between. It is not as easy as you make it look like.

> Isomorphic codebase, you can share the majority of your code with the client/server since it's Node on the backend and ES2015 on the frontend

I've been working for 20 years on this, last 8 ~ 9 only with node and React and not a single time, other than sharing some validation rules and/or for SSR, got anything useful out of having the possibility of running the same code in the browser and on the server... totally different responsibilities, libraries, requirements and environments.

But it is trendy and fashion, so we still do it

/s