midrus

Unpoly rocks. Far better and more conplete than Htmx. Sadly not as good at marketing.

I think the idea is to avoid to write the JavaScript yourself, not that you don't use it under the hood.

I'm curious about this. Can you share any specific problem you had and couldn't find a solution for?

Sure, you can do this for a couple weeks. Do this as the normal way of working and you'll end up alone. Burnout is a thing despite we agree or not on the reasons.

I think livewire works better with Alpine. Also, I think Livewire is great for interactions that require a backend request (such as posting a comment, refreshing some data, etc). If an interaction can be performed without reaching for the server, then Alpine is a better option.

In my opinion, when everything breaks down (and not saying this is your case, just what I think) is if you try to do every interaction with Livewire (thus reaching for the server when you shouldn't) or when trying to mix in SPA tools (such as Vue, React, etc...) with it. I suppose you'll end up with the worst parts of every solution.

I've found Unpoly to be a nice middleground between those framework specific solutions and htmx

Do not choose a programming language, choose the framework. Choose the libraries, the availability of devs for hire, the documentation. Choose the approaches and the patterns. The language is totally irrelevant compared to those things.

For example, let's say you choose Go, or JavaScript/node. Now what? You're now lost and need to take thousands of decisions for building anything web related, from ORMs to how to do validations to how to do translations to background jobs, etc,etc.

You won't have those problems of you choose Laravel or Rails for example.

Now that's my "business" answer assuming you want to build and ship something on your own money/time.

If you only want to learn to get hired, then yes, any of the popular languages will do it.

Also, https://tallstack.dev/

Well, probably you are right, but for me ecosystem, libraries, tooling, editor support, performance, etc is far more important than language syntax. But we all have our preferences and that's ok.

One of the companies I worked for used Elixir/Phoenix. It is an extremely cool piece of tech but it is nowhere near as productive as Laravel, Rails, etc. Missing libraries, difficult to hire for, bad editor support, and overall feels very niche which such a small community. That company eventually moved out of it.

I did use Rails for several months while helping a friend with his business/sideproject/startup kick-off and despite I really liked it, I much prefer Laravel + Livewire and PHP (https://tallstack.dev/) over Rails + Hotwire + Ruby, but it's up to personal preferences:

- I prefer things to be more explicit than implicit and lean more towards configuration over convention.

- I lean more towards having types/typing information than not having it

- PHP is way, way, way more used than Ruby

- Performance (just talking about development environment performance) is a lot better in PHP (no server restarts, etc)

- Availability of third party libraries is a lot stronger on the PHP side, probably due to it being more popular

- Tooling and editor support. This is a big one for me, and I've found out things to work a lot better with VSCode for PHP than for Ruby. Probably related to it being both, more popular and more explicit.

- Overall, Laravel feels even more complete than Rails and just fits better my brain.

But, I think Rails is still great, and I would use it over building a microservices mesh of Go servers on kubernetes with React frontends, etc, etc.

I'm one of those web devs that tries everything under the sun, and I also happen to have worked for a lot of companies (more than a dozen already, I'm on my 40s).

Laravel is such a *joy*. I've never had this feeling of using something so easy and productive. I've been recently building a side project with LiveWire and oh-my-god. I really wish I had discovered it before. From the templating system (you get components out of the box! no more "includes" if you don't want to) to the validations, to the queues system... everything is so well integrated and so easy to use.

For the last decade I've worked mostly with Django and SPAs, I'm not going back to that any time soon. Django templates are extremely limited for nowadays requirements, and SPAs are 1000x more complex to build and maintain so in my opinion they're not worth the price/effort. I think Livewire, Hotwire, Unpoly, Htmx, etc are what 90% of web apps need.

I had a coworker which was the most useless developer ever, not able to do absolutely anything by himself and totally unsure about everything. But given it was a big company it was easy for him to "hide" and rely on just showing up for meetings, talking to everyone, etc.

Then he was the first one to ask for raises, despite he was earning way, way, way more than he should already.

Then one day he came complaining that the mechanic wanted to charge him X for fixing his car and that it was too much and how could that be possible, etc, etc.....I just couldn't believe it.

Hahaha, you sound like my standup meetings XDD

They measured it by the number of Jira tasks moved to "done".

The problem is, nobody is asking if those Jira tasks could have been avoided, or be a lot smaller if we were working on a more productive stack.

At the end of the day product managers get used to everything taking a lot of time and assume that's the only way (which, to be honest, in this context it is... as reached this point it is very difficult to go back).

And also, when productivity was discussed... there was always someone suggesting the problem was the current "legacy" stack (i.e. React, Elixir) and that we should instead move to this other new stack to be more productive (Go, Svelte) and there we go again...

I'd also add Laravel here.

Regarding Django, my problem with it is that it is not a "full stack" framework anymore. Both Rails and Laravel provide a very good frontend solution. Rails with hotwire, etc and Laravel with livewire. Just the fact that django has no official way to compile/build assets, and the templating language is really arcane and limited for today's needs. Just compare that with Blade (Laravel's templates) which allow you to build components out of the box.

I'm having a blast nowadays with Laravel. After many years of building microservices and SPAs, I just can't believe how easy and refreshing everything is coming back to a "monolith". Yes, there's some spaghetti some times on certains parts, but I can just refactor stuff, create a PR, and easily improve the situation for me and my coworkers.

At my previous company you could only "touch" your own service, so once there was any kind of "architecture spaghetti"... good luck fixing that across 3 ~ 4 different services... and good luck aligning 3 ~ 4 teams priorities to fix it.

I've already have had a good bunch of similar experiences at previous companies, where you hear all the time "we're moving away from the monolith". Problem is after you've been hearing for 5+ years, it probably means it will never go away. This particular company ended up with 100s of "microservices" around it, first in Elixir, then Elixir went out of favor so they started rewriting in Go, then came GraphQL so some microservices were serving GraphQL while others stuck with REST, then different frontends in React, some with Redux, then redux was not the current trend so MobX, then MobX was not cool because now it was all hooks, then some moved to Next.js because of course nobody understood our custom in house webpack setup. Now I've heard they're moving to Svelte.

I honestly don't see how that can be better than sticking to Rails/Laravel/Django and embrace the monolith. All this madness of building things at every single company as if it were Netflix or Amazon is an insane waste of resources. Some days I feel like we (engineers) are like kids playing with the toys we want to play with rather than be solving real business problems and maintaining our projects in good shape technically speaking.

Well, nowadays I know (because I worked for) so many SF companies with people that would create an scandal in HR just because the catered food had too much salt or there wasn't a vegan alternative. I can't even imagine anyone doing this nowadays

As much as I don't like React, it is here to stay. But even if it weren't, it would still be a better idea to use something existing than writing your own framework. It is documented, well tested, easy to integrate with other tools, has devtools, and lot of developers already know it (and will still know it several decades from now).

Writing your own framework is almost never a good idea. It is only a good idea for the one writing it because we like tech and we like to show how good we're at building things ourselves. Business wise is the worst mistake ever... unless you're Figma or something like that building something radically special, I don't see how this is a good idea.

You have the first example of this problem in the post itself:

"...We did lost something with this choice. First, we lost compatibility with a couple of tools that we really wanted to use. One of them was storybook, that is a super-nice preview system. We had to develop our own frankenstein to do the same...."

The more your project grows, the more of that you will get. Then one day the people that took this decision leaves the company. And then the new joiners are stuck with an undocumented, failing, spaghetti frankestein mess they have to work on day to day.

And finally...those "few simple" components, will evolve...and sooner than later they won't be neither few neither simple anymore.

Convention is what you have in rails. Configuration is what you have in Django. What you have when you need to take 1k decisions per second and tie things together to kind of reproduce something usable as a whole is something totally different.

Language does not matter. What matters are frameworks, tools, ecosystem, libraries and developers availability. All langues are good enough and shit at different things.

Yes, precisely because I've been involved in maintaining codebases built without real full stack frameworks is why I say what I said.

The problem we have in this industry, is that somebody reads these blog posts, and the next day at work they ditch the "legacy rails" and starts rewriting the monolith in sveltekit/nextjs/whatever because that's what he/she has been told is the modern way to do full stack.

No need to say those engineers will quit 1 year later after they realize the mess they've created with their lightweight and simple modern framework.

I've seen this too many times already.

It is not about gatekeeping. It is about engineers being humble and assume it is very likely that their code is very unlikely to be better tested, documented, cohesive and maintained than what you're given in the real full stack frameworks.

Of course you can build anything even in assembler if you want. The question is if that's the most useful thing to do with your company's money.

Because for some folks being able to execute JavaScript in the backend is enough to consider it a backend framework.

That gives you an idea of how deep the backend knowledge is some times. Scary.

I'm really surprised at how easy anything is considered "full stack". Where is the ORM/data access library? The validation framework? The background jobs? The caching system? The translations/i18n system? And the other 1000 things you do need for a full stack real life application? I definitely do have those things in Laravel, Django and rails. Next.js, nuxt.js, sveltekit etc are far, far from full stack. They can certainly run js in the backend, but that's not full stack, you still need 10s of other packages.

They look so desperate, it is even painful to see.

I've solved all these problems for myself already: I won't join any company/team were scrum is mentioned in the interviews when you ask how do they work/organize. I'm just not compatible with so much bullshit.

Nah. I like being told what the mid/long term end result should look like and let me figure out the details and find the best way to that to me and my other engineering team mates. I like to be judged by what we achieved last month, last three months, last 6 months and last year. Not by what I reported in the "daily" what did yesterday because otherwise everyone thinks I've been slacking instead of moving mi Jira tickets.

I worked this way I like with just a kan ban board at previous jobs, and at my current one. It works, and everyone is happy. But it requires people with experience and trust at all levels, from engineers to PMs to CTOs to CEOs.

All this scrum bullshit is so fucked up. I've left a company just after a couple months because of 1) A terrible product manager and 2) A blindly by-the-book scrum process which led the project to a terrible state, worsening every day.

I've always said that frameworks, tools, ecosystem, libraries, community, etc are far, far, far more important than the programming language.

Also, nowadays PHP is not 10 year's ago PHP, same as nowadays's JavaScript is not 10 year's ago JavaScript. They're both "ok" languages to me.

And yes, having used for many years Django, some playing with Rails on the side, and then everything under the sun for Node, I 100% agree Laravel is freaking awesome and I really wish I had discovered it earlier.