midrus

There is no black or white here. 98% of every site is in between those things and you could consider them one way or the other. Is reddit a website or an application? is a backoffice dashboar a website or an application?.

The problem with SPAs is not the technology or the architecture itself. The problem is everyone thinks, by your own definitions, they are building an "app" by default.

I've already worked for several teams which struggle to get almost anything done and everything takes ages to ship because of the fanaticism of using React for everything. God, some didn't even know you could submit a form without building a json API endpoint.

The alternative to SPAs is not 90s pages reloads.

Nowadays you have livewire, hotwire, unpoly, htmx and several other modern solutions.

The alternative to SPAs is not 90s pages reloads.

Nowadays you have livewire, hotwire, unpoly, htmx and several other modern solutions.

The key here is that if we consider equivalent good and robust implementations, equivalent capable teams, same UX, etc of an SPA and a traditional full stack MVC application with a modern ajax tool such as livewire, hotwire, etc the latter takes a fraction of the time and cost to build and the result is far less complex and easier to maintain.

I've worked in both kinds of environments, and unless you're building an offline first app, dogma, or Google maps...SPAs make absolutely no sense from the engineering point of view.

It is rootkit free, they still haven't migrated it to work in ARM. Will come in a later automatic update.

I'd love to change, but I'm signed up everywhere with my gmail account. I feel kidnapped at this point.

And it is not as easy as just changing my login email everywhere.

1. Some system (such as government ones) make it very, very difficult to change, not even possible on some

2. How do I make sure I'm not forgetting some random site I don't frequently use

3. What about everyone's contacts where they have me saved with my @gmail account, I can't update their addressbooks

At this point I think the only think I do is pray for my gmail account not being blocked.

Don't try to force everyone to your preference and your thinking. Do you enjoy working at an office? Join a company which is office first. Want to work from home? join a remote first company. Market and time will decide which ones are more successful. Probably both will be in different ways.

I prefer remote, so I left my previous job and only applied to remote companies. Now I earn more than before and have 2 extra hours every day. I feel even more productive than before. And I feel a tiny small bit better with myself as I'm now contaminating less the environment. This multiplied by the total remote employees my company has, makes me feel still better about it.

The complexity is still there even with microservices or a Go or a Clojure codebase, it's just that either you've created a mess or you've created your own framework.

In my experience, you either use one of these big frameworks, or you end up building one. I've seen that happen more than once, and these "home made frameworks" are far worse, less documented, more buggy and have like 6 different patterns depending which generation of developers before me built it (and of course, I had left own opinions and mistakes too).

Writing microservices in Go or Flask or Sinatra won't make all the complexity related to the Web go away magically. The're still there. Now they're distributed across services and implemented mostly from scratch.

If you are not FAANG and don't use one of these big frameworks, you have only two options:

1. Create a distributed spaghetti mess of random libraries tied together 2. Build your own "big framework".

I've been many times in companies which were through the process of breaking up the monolith into separate services. It never finished, and every single service was just a proxy to the monolith, and everything took twice the time to implement, and now both all the services and the monolith have to be kept running and maintained. The only "positive" was the group of devs that wanted to play with new tech and somehow managed to become a team that only works on one of those services, so now they're "free" from the monolith hell. Business wise it was a disaster, would have been better to just let those engineers find another job with the tech stack they preferred and hire new ones willing to work on a single codebase and keep things simple. Again, this was not a Google scale company, these were 50 ~ 100 engineers organizations.

Yeah, this is the case I was talking about with the 90% of cases I was referring to.

At a previous job, we had a many, many thousand lines codebase of typescript, redux, observables, epics, thunks, custom server API libraries, websockets, Elixir backend, Kafka to communicate with other microservices, etc, etc..for...a frigging signup wizard.

Which then failed in so many stupid ways, had almost no server validation (everything unexpected was a 500) and it took days to do the smallest of the changes. But hey, don't dare to suggest doing this with Laravel would take 2% of the effort because you'd be crucified in the next frontend guild meeting.

While I do like static typing, I find more bugs because people have no clue about security and they think they can do it better by just tying together a few libraries and storing a jwt in local storage or they forget to handle Prisma exceptions or they didn't know what session fixation is or because they forgot to consider a corner case of foreign key exceptions from the database library, etc, etc than because somebody passed a string where an integer was needed.

Giving up frameworks with 10+ years of hardening and documentation and libraries and support etc just because of coroutines or static types or nice syntax or because that's what google does then I should do it too makes absolute no sense to me.

Yes, me too. But it makes absolutely no sense business wise. We like to play with tech, and learn and use the new shinny. While you're writing your frontend in elm and building your graphql API with Apollo and your serveless functions on kubernetes your causing a cost to your company which could have been avoided.

That's not engineering. That's playing with Legos just because we can.

I can't believe this madness. Is it worth? What if you just didn't build an SPA?

But pretty sure some engineers are having tons of fun building this stuff there. good for them and their CVs.

Also, note that when not going the microservices/spa/kubernetes route, the alternative is not "old style reloads on every click and jQuery spaghetti", I'd say that's equally as bad.

Nowadays there are alternative middle ground solutions such as Livewire, Hotwire, LiveView, Unpoly, Htmx, etc which provide a great way to organize the code and keep it maintainable.

THIS

I think that if we were more pragmatic and less about following the current fashion or trying to do what FANG does (which probably is just the opposite of what everyone else needs) we wouldn't be in such a high need of developers... which... I shouldn't be saying out loud probably :-)

> I ran Rails in production years back and swore it off then. We had constant memory leaks that seemingly came from Rails itself, and the only solution we had was "just restart the server."

Nothing is perfect. In my book restarting a server because of memory leaks is an acceptable trade off versus all the crazynes of having to decide and maintain on how to tie together a database, error validation, background jobs, translations, react, redux, an API to interface with the backend, logging, etc, etc, etc. Also, Go is just part of your system, I'm pretty sure you also have a frontend stack, and complexity increases a lot as I explained here. Compare that to Laravel+Livewire or Rails+ Hotwire. Night and day. I'm pretty sure any serious business will take the restarts any day vs the increased complexity and developer time.

> I've been happily running Go backends for the past 7 years now, and they're stable and fast and easy to refactor.

Yes, and I bet something built in 7 years with Go would have taken 7 months with Rails or Laravel.

On the static typing stuff, I'm with you on that. PHP (and Laravel) are a bit closer to that, but nothing is perfect. And for Web Development using Laravel or Rails is a good trade off.

I really hope some sanity comes back to this industry. Rails and Laravel are the best tools by far to build like... 90% of what we build on the internet (Other 10% being offline first apps and stuff like figma, etc).

It just hurts to see how my team, and previous teams I worked with struggle with all the SPAs and microservices, and Go backends and GraphQL nonsense when what we're doing are just fancy crud forms with maybe one or two really interactive widgets overall.

So much time and money wasted just for following fashion.

Any alternatives? What would you recommend instead? I'm under the suspicion that every single Smart TV vendor has the same problems.

Why would you use another ORM?

I've worked once in a project where a very opinionated dev lead "decided" SQLAlchemy was better than the django ORM, so he replaced it. The mess he created was unbelievable, we spent years cleaning things up and some part we even couldn't.

> have to choose to either do things the Laravel way to take advantage of the community, or write everything on your own

Of course! that's the whole point of a framework, to put some guardrails on how to do things.

If you think you can do things better, more performant, more tested, and more documented, good for you, go ahead and just write raw PHP or tie together your own libraries. You can't blame an opinionated framework because bastardising it is not easy. That's a feature in my book.

Agree, used it for about half a year at a previous job. It tries to copy everything from everywhere and creates too many ways to do the same thing. The ecosystem is a lot smaller and many times I ended up on issue comments or readmes in chinese, which din't make it any easier. Also I got pretty pissed off with the 2 -> 3 transition, not as easy as they claim on big projects with real business pressure like to stop development for weeks during migration. Also Next.js is incredibly better (and better managed) than Nuxt. I'm never using it again.

You could say this of absolutely anything. Let's use assembler then so we know what we're doing. Oh no, wait, let's write the 0s and the 1s ourselves so we understand what the processor is doing. Even better, let's just put some voltage on some transistors so we understand the flow of the electricity.

At some point you need to accept the underlying stuff just works and build on top of existing layers. That's what DHH calls "conceptual compression" I think, and that's also how science works. Building everything from scratch so that you understand it doesn't work, specially in a business context and usually ends up in worse home-made frameworks.

You're wasting your time.

Honest question: Why browser's integrated password managers (such as chrome's) are not considered an option for most companies which ask you to use 1password, etc?

Taking out of the equation that maybe google can read your passwords... from the endpoint/laptop point of view itself, is it any less secure than those 3rd party password managers? My understanding is that, for example on OSX, they store them in the OS keychain anyway, right? What's so wrong with that?

The problem with pair programming, as with any other tool is when people read about it in a book and try to apply to 100% of the situations and the people as pure dogma.

Several years ago I worked for a company where the "effective CTO" (he was not the CTO but given the CTO was remote (WTF!!) this guy acted as the intermediary) used to read TONS of books about XP, agile, scrum, team dynamics, programming paradigms, SOLID, design patterns, etc, etc and he *forced* every single f*ng thing he read about to everyone because "that's the professional way to do it".

On the methodology front, pair programming was the worst part, as we were basically forbidden to work alone. He used to say stupid things (half kidding, half serious) such as "we should have one laptop every two developers". It was terrible. On the technical flank we ended up with a CQRS system passing messages between microservices on kubernetes and decoupled SPAs and a bastardised Python codebase that looked like Java and was the most unidiomatic python I've seen in my life, because hey, I've read the book of design patterns and object oriented programing 3rd edition. We were 5 devs. F*ng insane.

So yes, a wrench can be an awesome tool to fix you car's motor, or could also be a weapon to hit somebody in the head and kill him. It's understanding the use cases and the situations what matters, not applying everything you read about as the definitive way to do it.

I also work for a company where everyone writes and reads and we have almost no meetings at all, no scrum, etc, and I didn't notice any of these problems. It's the best place I've worked at and I'm already > 20 years into this.

To me the problem you describe is orthogonal to the fact you have a writing culture or not. I bet if you didn't have that writing culture you would still have all those problems and just a ton more meetings and conversations with managers. I've been at places like that in the past and the best solution for me was to quit, I just couldn't stand it.

For example, promotions: I've been in that hunger games you mention where you have to promote yourself to death to have a promotion, and I hated it. Agree with you it was a real problem, specially for people that don't like to do marketing of themselves. At my current company your team lead is ultimately responsible of the output of the team, so with consideration of the team's opinions, he ultimately decides if you get a raise each year or not. If he wants you in the team you get a raise, if he doesn't you get a lower one or none at all. You can look for another team within the company or you can leave, up to you. Leads are professional enough like to not promote just friends, because they're also accountable in the same way up the chain. And that's it. At the end of the day your team, the 6 or 10 people you work with every day, they know very clearly if they want you or not, no need for 100 page essays about your awesomeness.

I've been using Macs (both desktop and laptops) since I have memory. I've had the M1 since launch day, and I use it all day, both for work and personal use.

Why this never happened to me? Why I don't know anyone which had this problem? Why nobody is complaining as it happened with the previous gen keyboards?

I think we might be missing something in this analysis. I don't think Apple engineers are idiots.

> If they substituted javaScript with any of the other popular general purpose languages no one would be any worse off for it

This is what I'm talking about. This is not going to happen any time soon. And all attempts to do this only lead to more confusion. It is easier to just learn it and help making it better. The language improved a lot over the last few years so I don't see why replacing an entire ecosystem, browser implementation, libraries, writing transpilers, etc, etc, etc can be any better than just learning to love it as the tool it is.

And let's say in some parallel universe it could be replaced. What is it going to be replaced with? Go? Python? Rust? Everyone has a different opinion so there is no agreement possible. And having any and every language available in the browser is just a wild dream.

So, yes, JavaScript is not perfect. And probably there are a ton of better languages but trying to avoid it and write everything in Go/Clojure/Python/Whatever is ridiculous. That won't happen any time soon. Not using JavaScript is just self inflicting limitations oneself.

The sooner JavaScript haters assume there is no way around it, the better we'll all be.

I do like a lot Livewire, Hotwire, Unpoly, HTMX, etc... but using these tools (or any backend language compiled to wasm, etc,etc) as a way to try to avoid JavaScript is never going to work and will only cause pain and terrible applications.

Even with those HTML first technologies (which I like a lot) you need to learn to accept JavaScript is just another tool and one that you will definitely need to learn and use to make anything decent.

It is great to have a framework such as livewire that when you click a button to "load more" will render the new items in the backend and just swap out a placeholder and done. No JavaScript, no API, etc. Amazing.

It is just *terrible*, flaky, unresponsive, overkill and absurd to reach for the backend to re render a bunch of html because you needed to toggle a class or hide a box.

Use the right tool for the job.

I'm really tired of backend developers hating on JavaScript the same I'm tired of JavaScript developers hating on PHP, etc, etc.

Different tools. Different tasks. Let's not try to be purists and "JavaScript all the things" or "I'm not touching JavaScript because it sucks".

I loved Twitter when it was about reading tweets and retweets from people I followed. I don't follow many people/companies, just around 30 or so in total, most of them are either people I know in person or popular companies or products.

Nowadays my feed is a total mess of ads, things somebody liked, things some others follow, uninteresting recommendations, random topics and a lot of bullshit I don't care and are just noise to me.

I already deleted facebook several years ago and not missing it any single bit. I think my twitter account is following the same destiny pretty soon.

I've worked 8+ years with Django and the last 2~3 years with Laravel. Other than the admin, I don't miss anything from Django. Laravel is so much better in almost every other aspect.

You still can write client side only JavaSCript with Unpoly compilers, alpine.js, and probably htmx also has a way to add custom javascript without making jquery spaghetti.

A tool like this that rely on server rendering (or livewire, hotwire, etc) is a perfect replacement for when your user interaction will need to reach to the server anyway (to save data or fetch something, etc).

For example, you're not forced to go back to the server to display a modal. You can have it already rendered on beforehand and when clicking a given button just toggle its visibility.

Or if you want to mark a todo item as "done" you can just apply the "done" styles with alpine.js or similar and make an async call to the backend that will persist the state, etc.

Going full "SPA" just because this is less ideal than state based react, etc does not compensate the overhead of everything else involved in any web application (SEO support, translations, security, authentication, etc) which are incredibly complicated to get right with SPAs.