1,678 karma · joined November 29, 2016
Nowadays we have *awesome* ways to do frontend in these full stack frameworks, such as Hotwire/Turbo, Livewire, HTMX, Unpoly, Alpine.js, etc.
The same JavaScript is not your grandpa's JavaScript anymore, traditional MVC apps is not your grandpa's MVC apps either.
And no, Next.js + Prisma, Remix, etc... ARE NOT full stack frameworks despite their claims. They're cobbled together third party libraries all around which just allow you to submit a form to a database. That's not full stack. You need a way to do authentication, authorization, sending emails, translations, command line tasks, background jobs, input validation, caching (and many, many more things).
Why do we do SPAs? Because we as developers want to have the only one "true way" of doing things, so given you can build almost anything with JavaScript, then we want to use JavaScript for everything even if it is not the best tool. It's like when Redux showed up: suddenly *everything* had to go into redux, because that's "the way".
I've been a professional developer for about 18 years, I worked a lot with python (django), java (dropwizard) and the last 8 years or so mostly focused on frontend with JavaScript, last few years doing a lot of React (Next.js) and Vue (Nuxt.js). Playing with Sveltekit.
I love JavaScript and it is what pays my bills nowadays, but we need to realize that the tools and ecosystem (frameworks, libraries, editors, etc) are WAY more important than a language itself.
Nowadays I'm doing a side-project with Laravel, and learning PHP (as a consequence of wanting to use Laravel) and I'm finding it incredible powerful and productive. I like it a lot more than Rails, and certainly much, much more than Django. I can do html components in the server, I can add behavior with Alpine, if it is a complex one with LiveWire, and if I want to do SPA like page transitions across pages I can use Unpoly. And I can trust the next person picking up the project will have a decent documentation (Laravel's official docs) which is something you don't have when you cobble together your own library salad.
HTMX, in my opinion, has a smaller scope. Of course you can do everything, but you'll have to do more yourself.
Alpine seems to be even more low level, kind of a lightweight Vue. I don't like it, it really turns me off adding code in html attributes.
But I insist, they have almost nothing in common other than maybe the end user result. The approaches they take are architecturally very different and with very different trade offs.
Backend:
- Huey for background jobs
- Whitenoise for statics handling
- Gunicorn for running the application
- Honcho for process management (also for development, for spawning js and css bundling)
- Slippers for django template components
- django-all-auth for signup/password recovery/etc.
- django-rest-framework if you need an API
- Unpoly for ajaxy SPAish feel (just the good parts of that feeling)
- Tailwind for styling
- esbuild (CLI) for bundling js
- npm for frontend dependencies
- postcss (CLI) for building/packaging css
- Dokku for hobbie or side projects
- Heroku for getting started with production apps, AppEngine if shit gets real.
- No need for Websockets, polling is good enough most of the time.
- Sqlite for side projects
- PostgresQL for serios stuff
- Maybe redisYou just need to build it from scratch, document it and ensure it is well tried and tested.
"mega frameworks" are there for a reason. Rails, Django, Laravel, etc have everything they have because almost any web application you build (except if it is just a minimalist micro-service) will need routing, authentication, i18n, ORM or similar, migrations, caching, e2e testing, validation, background job processing (the one that works after a deploy or restart), and a thousand more other things.
Of course you don't need it to "get started", but 1 week after getting started you'll find yourself rebuilding the wheel yourself or tying together 10k dependencies (something doable if you have enough experience and know what to pick and what to not pick, but risky).
> And it's not uncommon in Go codebases to repeat yourself.
The fact that it is not uncommon doesn't make it any better. Rewriting the universe from scratch in every single project is the worst idea ever.
I don't think that because we like a programming language which happens to have no popular web framework we need to negate all the problems of not having one, or say it is in benefit of simplicity. It is not.
I'm very sorry for my rant, but I've already faced too many disasters in work environment were people thought that "just flask" would be enough, and years later we're still fighting the fire and trying to understand why this custom ORM validation integration doesn't work.
It is not. From the outside the end result for the user might be similar, but that's where the similarities end. Elixir's LiveView what I assume you're talking about keeps state on the server, in memory, and sychronizes changes back to the client over a websocket. Hotwire is "stateless" in the sense that no end user state is kept in memory on the server across requests. You can also use most of Hotwire without websockets.
My previous company was using Elixir, and they moved away from it because everything took longer to develop, the ecosystem of libraries was very lacking, the tooling (such as editor support) was terrible, and it was very difficult to hire experienced developers.
Performance wise, I agree, it is faster and you will use less servers. A nice problem to have to be honest.
This might work for q blog post example, but imagine doing a full reload just because you liked a post or a comment.
You've got to be kidding me.
I used to work for a company where it was ok (managers won't say anything, even if explicitly pointed at the situation) to remove company company code, create your own NPM package (on your own private NPM account) and add it as a dependency of the company codebase(s).
This and some other similar behaviours were the reason I left that company. But I'm the loser of the story here, as those guys are now working for even bigger companies with bigger salaries than me.
Complaining just because of the syntax is just trying to convince yourself you don't like it.
It's like when people just discard tailwind because they don't like how ugly many classes together look on the html, ignoring everything behind it which is what really matters (and that you can still like or dislike).
My gripes with Vue are:
- Despite they say it is not a "Python 2 to 3 like" situation, it is. Every library you find specifies if it is for Vue 2 or 3, some have versions for both, some are only for 2 and will never be upgraded to 3, others are just for 3.
- Vue doesn't have any spirit or ideas of its own. It just copies over every feature from every framework trying to be all to everyone, which leads to too many different ways of doing the same thing.
- There is a horrible culture of auto importing things (components, functions, ref sugar, etc) . This breaks tooling and editors, then they patch those to auto detect these tricks, then introduce a new one and everything breaks, then again..
- Many, many times I was trying to investigate a problem and you end up in a Github Issue which has part of the discussion in Chinese. Doesn't happen as much in official repos, but it happens in many of the third party libraries you end up needing anyway. Some libraries don't even have a readme in English.
- In the part of Europe I'm in, nobody wants to use Vue, so it is difficult to hire.
- Nuxt.js is terrible compared to Next.js. They're also in this "2 to 3" rewrite, and have been terrible at communicating. Probably our project at work will never move to Vue 3 and/or Nuxt.
- Community feels an order of magnitude smaller than react.
On the good site:
- It has a far, far, far better reactivity system than React. No need to manually track dependencies, memoize callbacks and components, etc.
- It is a lot more easy and intuitive, a lot less foot guns.
- It is a real framework, as you have an official router, state management solution, styling approach, etc. I love this.
Did you build it yourself? Because it honestly looks like a full blown company had built it by how good it looks from the outside. If so, you're a f**g machine!! Congrats.
I just don't agree all that complexity is worth when you need to ship things fast with a decent robustness and performance. Specially when you don't have 100s of devs in the project.
I'm just saying that given React vs Rails, for 80% of projects I'd pick Rails+hotwire+etc... But given Svelte vs Rails, I'm more inclined to pick Svelte now, because it is not so complex, for now at least.
Things such as redux, rxjs, observables, thunks, etc really put me off when you compare that to just MVC with Rails for example, plus most applications I worked with React were just forms anyway, with some fancy controls/widgets on top.
Not having a clear way, even today with Next, to load data (client side, without doing SSR) before a route transition happens (which leads to spinners everywhere), and now the solution seems to be all the server components, concurrent mode, suspense, etc, etc which to me is just mind blowing how complex things became.
Also hooks which conceptually they make a lot of sense and I like them, but then you have to do all the dependencies tracking manually, they have a lot of gotchas (async in useEffect, ordering, etc).
The "rerendering of everything" and the need for manual memo, useMemo, useCallback, etc and the whole "don't optimize it until you need it" (guess what, a my company as in many others it never was a product priority to make it fast).
Now, take the good parts of the approach, remove all these complications, and you have a very nice and clean approach to do web apps. To me that is what Svelte brings back.