1,678 karma · joined November 29, 2016
I've seen this with my own eyes in the past.
Sorry for my dumbness, but not sure what a repost invite is. Something good I hope XD.
Thanks.
My best experience so far, has been to start services individually, and work with mocks and tests. And do integration on a shared staging environment or, even better, have a way to deploy multiple versions to the same env (like you can do with App Engine, Vercel, etc).
I hope I never ever again have to work at a place where I need to replicate the entire platform for my development environment.
If this guy were pragmatic, a Ruby on Rails/django app in heroku would do wonders. If he wants to promote React because that's what he sells, that's a different story.
The problem is the people taking what this guy says as "the modern way to do it" and then you find the messes you find at work.
80% of companies building on top of kubernetes should just pay some provider to do it for them, or use higher level tools. The crazyness going in the DevOps/Infrastructure world is as bad, or worse, as the one going on in the frontend space.
Nowadays I think that unless you have a team that only wants to work with JavaScript and nothing else, or you need an offline first application or something truly "single page" such as Google maps, it makes no sense. Adding a form validation library should be a red flag you're going out of the intended use case.
If what you meant by your question is if, once decided to use a frontend framework such as react, is it worth vs Vue, Svelte, vanilla, etc.... Then my answer is that it is better to use one of theses vs not using them, just because of the ecosystem, the docs and the libraries you will find. I think Vue is a LOT better than react, but that's just my preference due to it being less verbose, having official solutions for router, state, etc and the amazing reactivity system it has.
On a team of 4 or 5 people, where people go sick, take vacations, leave the company, new members join... each of these events has a big impact on those metrics. Which again, becomes a lot of work and effort wasted.
But yes, probably this is a viable option on larger teams.
Tests can be written properly and in a very reliable way in any platform, and a mess can be made in any platform too.
Being popular means you get a lot of criticism. Same happens to java, PHP, and any other popular language.
I still have nightmares.
What you're doing here is not much more than a backup.
I love it is asynchronous by default (and thus all its ecosystem is as well). As someone that had to deal a lot with thread pools, and semaphores and concurrency issues, this is invaluable to me.
I also like a lot the tooling. From VSCode support, to typescript, to eslint, prettier and despite people complain about large node_modules, I think NPM and the trade offs leading to that are very worth it.
I also really enjoy the availability of libraries... whatever you need, you'll find a popular package for it.
At a previous company I worked for, a decision was made to move to other platforms not because Elixir was bad, or LiveView was bad (it was good!) but because it was really difficult to hire for.
It is difficult to find people with elixir experience, and we didn't want to have production system built by just people learning a language, platform and architecture on the fly.
Also, that's considering "backend" developers. It was *TOTALLY* impossible to hire frontend developers wanting to work in this setup. No single frontend developer wanted to learn Elixir, and all the backend related stuff. This doesn't happen for example with Node... yes, it might be a terrible choice for the backend, but most frontend devs are happy to work with it.
Regarding to the solutions in other platforms not having the Erlang VM to power them, etc,etc.... not everyone is at google/twitter/facebook scale, 90% of companies out there can be run perfectly fine with run of the mill django/rails/laravel setup.
Premature optimization is as bad when doing an unnecessary SPA as it is using the Erlang VM when rails was enough.
All the Agile an scrum bullshit get introduced the moment the higher ups want to have exact estimates and deadlines and just shipping features is the only prioirity. Despite all the stupid effort to predict task sizes and times in the end they're always wrong, things take more time (or less) and we wasted a ton of time and mental energy on the shared taboo lie that we're estimating stuff.
What would you use to "simplify" things? Your own webpack config?
I can assure you those developers mocking frontend devs can't even do backend if taken outside their big ass framework (django, rails, symfony,etc etc), because they believe everyhing is as easy as those frameworks put it to them. Somebody that had to work outside of that where you have to take many decisions and make tons of trade offs and find how to organize code and manage dependencies, etc will understand better how difficult frontend is. True we sometimes overcomplicate things more than needed (redux, rxjs, etc...) but even when we do not, this is still freakin difficult to get right.
Compared to Hotwire:
I think hotwire is the best option if you're using Rails. From what I know, hotwire needs a lot more of backend "collaboration" than Unpoly, so you will need backend "hotwire" implementations. You can see these things are being built for django, etc.
Compared to Htmlx+ Alpine:
Let me start with the disclaimer that I think Alpine.js is an aberration. Writing code inside html attributes is a fantastic way to break every editor templating language plugin, syntax highlighting, etc.
Despite of me not liking Alpine, I think unpoly handles a lot more use cases, and it feels a lot more "declarative" to me.
Compared to both:
Unpoly is kind of the "django" or "rails" in this category of tools. It gives you a lot of stuff. From page transitions loading progress bar (a'la turbolinks) to ajax replacing links, to modals, to popups to sidebars, to automatic blocks replacement (up-hungry) to form posts, to handle error responses, layers, polling.... and it has an awesome way of writing your own "components" with the up.compiler api.
I honestly think the only reason Unpoly isn't the most popular solution in this space is because of bad marketing (well, no marketing at all...). I really think it is the best (if you're not using Rails, then I'd use Hotwire+Stimulus+etc...).
Otherwise, what you are describing isn't going to be "Just Go" or "Just the language"... you'll have again a ton of libraries/frameworks on top of it... the complexity is going to be there... one way or another.