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.
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.
Isn't that the part where you as a developer step in? Most of these things are solved problems with mature libraries to integrate. I much rather mix and match then fight some all-in-one super framework that doesn't do quite what you need.
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.
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.
But I do agree they are the best option if you hate or can’t pay or aren’t allowed to use apple products.