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.
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.
> 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.
The moment you need SSR, you'd be in a better place if you were using just plain old server rendered (componetized) views, such as the ones you can do with laravel's Blade system, and do your client side interactions with Alpine and your server interactions with unpoly/HTMX.
SSR per se is not a "big problem", specially if using something like Next. The problem comes when you have to mix in translations, i18n, data fetching from external sources, authentication, cookies forwarding, etc, etc, etc... in my opinion complexity grows so exponentially that I don't see the advantage anymore.
I'm working on a project built with Laravel + Tailwind + Unpoly + Alpine and it is such a walk in the park to implement anything thrown at us. Although it is not "cool" tech, so some people around here don't want to work on it because they only want React all the things :-s
Or they just got bored and wanted to try some shinier toy. I've seen this happen dozens of time, all the bullshit for justifying it is just that, bullshit.
Not saying this is the case here but highly likely.
Unless it is an offline-first web app, or something like Figma, I'd go for the TALL stack [1] and deploy to Heroku or App Engine (or Dokku [2] if it is just a side project). Specially if I'm building it myself, or with a small team.
Definitely wouldn't go the fancy SPA serverlerss lambda jamstack microservices route.
But I do agree they are the best option if you hate or can’t pay or aren’t allowed to use apple products.