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.

A lot.

https://blog.jannikwempe.com/debunking-tailwind-counterargum...

https://www.swyx.io/why-tailwind

And many similar ones.

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

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

Err... We're literally this close to wipe out ourselves.

I'd still take the discovering of an advanced civilization any day.

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.

[1] https://tallstack.dev/

[2] https://dokku.com/

Wile E. Coyote will be so happy with this.

My cat is the smarter cat ever. It managed to train me very well.

This is so common, sadly. I've seen this happen a lot. And those geniuses advocating for these insane infrastructure usually leave the company after they scratched their itch with kubernetes or whatever they were interested in playing with I'm s strong believer that your first few engineers are very very, very important and you need to hire very experienced people.

In the cases I've seen this, honestly I think the ones to blame where the stakeholders, for hiring very young people, for the cheapest rate they could and giving them full responsibility and the Senior Architecure Something Something title when those people don't have more than a couple years experience and are just building what they read in a blog two weeks ago.

You are confusing parallelism with concurrency. It definitely can be a problem.

I love the simplicity and how clean it looks. There should be more websites like this. Congrats.

This guy maths

Maybe they couldn't agree on the frontend framework to use. Not entire companies, but I've seen projects fail because of this or some similar decision paralysis

Have you tried Unpoly? It's like htmx but more "high level". I've used it for several projects and it is one of the more underrated tools out there. On my latest project.im using it in combination with Alpine.js on a Laravel application and I'm loving it.

>If your other option is Django/Rails/etc: it is like Rails, but integrates better with the frontend.

And worse with the backend.

Let's not pretend running code in the server are issuing queries to a database is all you do in the backend.

This is why these new "Rails killers" are a huge risk. Unexpected U turns every now and then. I wouldn't trust any of them for a real life project at work.

Regarding to hidden complexity, the complexity is there. You either deal with it yourself or rely on the "magic" of the framework to do it for you. I prefer the latter.