midrus

I find Laravel (with something like livewire or Unpoly) quite easy, well documented and battle tested. Of everything I've tried in my life this is the best "one man army" stack I've seen.

The trick is to be able to route users traffic to different deployments. You can run two versions of your application concurrently, and have a dial to progressively shift traffic to the new version, as soon as you notice anything wrong you shift it back to the previous version which wasn't stopped at all.

After 100% of the traffic is in the new version, and no customer complaints for 1h then you can shut down the old version.

Google App Engine had all of this at least 5 or 6 years ago.

See my other comment [1], it might be hell because you're missing the right tooling. With the right tooling, it's heaven actually.

[1] https://news.ycombinator.com/reply?id=30900066&goto=item%3Fi...

> If you truly want to get rid of your a staging environment the minimum that you need to feature flagging of _everything_, and I do mean everything. That is honestly near impossible. You also need live preview environments for each PR/branch. This somewhat eliminates the need for a staging because reviewers can test the changes on a live environment. These two things still aren't good enough reason to get rid of your staging environment. There is still many things that can go wrong.

This can be done very easily with many modern PaaS services. I had this like 6 or 7 years ago with Google App Engine, and we didn't have staging environment as each branch would be deployed and tested as if it were its own environment.

And yes, you need blue/green deployments in addition to feature flags, as it is not easy to feature flag certain things, such as a language runtime version update or a third party library upgrade, among many other things.

Good monitoring, logs, metrics, feature flagging (allowing for opening a branch of code for a % of users), blue/green deployment (allowing a release to handle a % of the user's traffic) and good tooling for quick builds/releases/rollback, in my experience, are far better tools than intermediate staging environments.

I've had great success in the past with a custom feature flags system + Google's App Engine % based traffic shifting, where you can send just a small % of traffic to a new service, and rollback to your previous version quickly without even needing to redeploy.

Now, not having those tools as a minimum, and not having either staging environment is just reckless. No unit/integration/whatever tests are going to make me feel safe about a deploy.

You're probably not the target market. Not everyone knows how to setup a server by themselves and run a blog and keep backups and keep it running and update it, etc..

I've worked both on large Vue and react projects. Wouldn't pick myself Vue ever if I have the choice.

Vue is certainly easier to learn, and comes with a lot of oficial libraries such as vuex, Vue router etc. But that's all about it.

The Vue 2 to 3 transition is a big fuck up, python level. One of the companies I've worked for will never be able to migrate to Vue 3, because they cannot afford to stop product development and they also have a ton of external dependencies that are mostly abandoned.

The integration with typescript, even in Vue 3 is still not as good as it is for react. This is critical for large projects, and to have proper ide autocomopletion, etc.

Then the ecosystem....it is a lot smaller than the React ecosystem.

Then the "meta frameworks". Next.js is infinitely better and better managed than Nuxt, which went full rewrite and again, from my point of view that's a big fuck up.

And finally, I have absolutely nothing against other languages (even English is not my native language) but I got really tired of finding myself debugging problems and ending up in issues, forums or readmes in languages that are not English (mostly Chinese).

React has its drawbacks, but I prefer those by a far amount to the drawbacks of using Vue.

>As a user of service I want guarantee that my data will be processed as per my requirement and then it will be left alone.

This is totally orthogonal to self hosting. You can ask for a service to be operated for you and also ask for your data to not be processed in any way and be accessible only to you. Of course this is not free, which is what most people want and what you're mixing up here.

In my opinion, what makes a "language" the best for webdev is not its syntax. It is the ecosystem, the libraries, the amount of people that know it, the learning curve, the editor plugins available, the frameworks, etc.

Ocaml? Elm? Clojure? Haskell?. That's fun for side projects, not for real business.

As a user of a service, unless it is for learning or paranoia reasons it makes no sense to try to self host the same it doesn't make sense to have your own mechanic workshop in case your car breaks or your own hospital in case you need medical attention.

So much underestimation here regarding what it takes to have reliable, secure and resilient self hosted services. I've seen far too many disasters because somebody thought it was just easier/cheaper to self host.

Any runtime that has the concept of "thread locals" or "thread safety" have this sharing problem, no need to exploit y anything. Of those you mention I've worked with Python and java and their runtimes do have this problem (or feature, depending how you look at it). In python for example if you import a module level variable or instance and you modify it's value on a request, you can read it from another request that lands on the same thread. Same with java. I don't know the others you mention but probably are the same as that's how most runtimes work.

You can't do that in PHP, you need to explicitly write to redis/memcached/file/database to be able to read values from another request.

Honestly, I can't care less about "languages". To me they're just syntax. And for all the kind of web applications I've built, the performance has never been a big concern over other stuff such as building features, fixing bugs, development speed, etc.

What does matter A LOT for me is the ecosystem, the tools, the editor support, the libraries, the frameworks, the community, etc. And PHP does GREAT at this. I'm using Laravel nowadays and it feels like a better Rails, with better tooling, better editor integration, more people using it, more community, more libraries, etc. Is the language a bit uglier? yes, but I don't care about the syntax, everything else matters a lot more to me.

I think the opposite side of the spectrum in the sense we're talking about "stateless" here would be something like node.js, or Go, where a single "process" is kept alive at all times and responding to every request. In these non-stateless runtimes if you're not careful you could leak information from one request to another, or some unhandled errors or exception terminate not just the request that caused it, but all other request being concurrently handled at the moment the error happens.

Thanks for this. Helped me a lot to calm down a bit.

> "rerender previous form pages over and over again, except hidden"

There are modern ways to do this, see Unpoly, HTMX, livewire, hotwire, etc. You're comparing with an outdated view of what an MVC application looks like. It's like to complain about SPAs because of backbone.js

> "have some token to track partial form data"

This is called "sessions", the token you refer to can be a cookie, which is done by default for free on any MVC framework. Doing this in any other way lead to either losing authentication on page reload or security vulnerabilities (storing a token in localstorage, etc).

> "build up a DB to store a partially complete form"

Again, you can store partial data in a session, for free. As it comes by default with any MVC framework.

One of the key points here is that with any of the popular MVC frameworks you don't need to rebuild the wheel and the car from scratch as with SPA frameworks, most of these things come for free, specially anything related to forms. This is something we're not used to have in the SPA world and everyone has a different way to deal with it.

> Multi-page forms without some front end stuff

Nobody says there shouldn't be any frontend stuff, you still need it of course. If fields are static between steps you can just render every step and toggle between different set of fields using something like Alpine, no need to reload from the server. If fields are dynamic and need some kind of database lookup between steps, Unpoly or livewire/hotwire make this trivial.

Please, let's stop comparing Next.js/React top modern SPAs to 20 year's ago struts MVC, it has not been like that since many years ago already.

*figma, not dogma. Autocorrect messed up and just noticed.

This works great as long as it is not a first visitor though. For new visitors with a spotty connection this will be a nightmare. Also I assume any new update you release which might need to refresh the cache would also be a problem in this situation. I don't think it's that easy. Not saying that you're not doing it right, just that it is not a trivial thing and almost everyone else won't do this right.

> done correctly

Big assumption. This is what the whole discussion is about. Doing "correctly" an SPA is incredibly expensive.

I can also assure you that when an MVC application is done correctly you can have an equally good user experience.

> The server rendered app will ALWAYS have to wait at least 1xRTT for every new render. The SPA does not.

This is an outdated idea of how server rendered apps work. See Unpoly, HTMX, LiveWire, Hotwire, etc.

I'm personally using Livewire. I make server request in only 2 situations. 1) When going to different pages (I'd need that anyway with an SPA given I need "SSR") and 2) When I'd need to write or read data from the server, which with an SPA would mean I need an API call anyway. Every other interaction is done with Alpine, 100% client side.

> they work if your connection is flaky,

Not saying it can't be done, but I haven't seen many SPAs that handles well flaky connections. Most stall with no indication to the end user, endless spinners or just broken in some random way.

> Put the user first, consider the trade-offs that work towards that goal, and see what shakes out.

In my experience, every single team I've been part of that was building an SPA was because they put the developer experience and desires first, even if in the mid/long term the dev experience ends up being worse as the project grows.

Then you can use Livewire, Unpoly, or HTMX. MVC doesn't mean 90s style reloads anymore.

I'd say it is very practical for hiring, as you will need just 1 or 2 developers that knows JavaScript and (Rails|Laravel|etc..) for every 4 or 5 you'd need otherwise (some that know JS, some that know backend, and some to coordinate/manage them).

You're describing an actual client side (mobile or desktop) application made with web technology, not a web application. That's a fair use of SPA tech.

As soon as you need authentication, showing data across users, allowing visitors to see shared data, perform validation of inputs, send notifications when other user action happens, etc you're back in SPA hell.

The alternative to SPAs is not 90s pages reloads. Nowadays you have livewire, hotwire, unpoly, htmx and several other modern solutions.

As an ex-member of a team who used react, redux, typescript, observables, epics, thunks, custom hoome-grown validation libraries, websockets and elixir deployed in two different microservices to build a... signup wizard... I can confirm this.

I proposed to build it in Rails (which we already had, but was the "old monolith we're migrating away from") and I almost get crucified.

Same experience here, in our case with Laravel. The project started as a Next.js SPA and after we needed to add authentication, translations and background jobs things became so crazy and so "custom" that we ditched it and in almost 2 weeks had everything built in a much more robust way with Laravel and Livewire + Alpine.

GraphQL is just another artificial solution to a problem created by SPAs themselves. Same as SSR, hydration, server components, client side routers, dynamic bundles loading, dynamic translations loading, etc, etc, etc. A whole industry of workarounds for a broken idea. Now 10 years after SPAs became popular we starting to approach a point were we almost have what we already had.

> but most of the SPAs I have to use are garbage

As an example, look at reddit. I'm still using old.reddit.com because I can't stand their fancy SPA UI. It is so bad to the point, as a user, I enjoy a lot more HN's interface than reddit's one.