131–140 of 533 posts
Earlier quoted context omitted.
I disagree, the problem with an SPA is that now you have two places where you manage state (the backend and the frontend). That gives you much more opportunity for the two places to disagree, and now you have bugs.
Who says your backend needs to manage state?
I keep hearing good things about Rails. What are the downsides, other than learning a new language and framework?
Did you miscalibrate your time machine and just make it back?
Not everyone has looked into or tried everything.
Earlier quoted context omitted.
But on the flip side, you can program the backend in anything you like, instead of being bound to javascript.
JS/TS is fine. Why switch back and forth between languages and frameworks and data models and…
Earlier quoted context omitted.
Rails has ActiveRecord, which has an extremely elegant REPL. It's a delight to use.
ActiveRecord may be both the best and worst part of Rails. Currently the largest scaling problem that I'm facing is with all the before_* and after_* callbacks which run per model record rather than a batch of changed records. This is an N+1 query landmine field for which ActiveRecord offers no solutions.
upsert_all[1] is available to update a batch of records in a single write that does not invoke model callbacks.
activerecord-import[2] is also very nice gem that provides a great api for working with batches of records.
It can be as simple as extracting your callback logic and a method (def self.batch_update) and running your callback logic after the upsert.
[1] https://api.rubyonrails.org/classes/ActiveRecord/Relation.ht... [2] https://github.com/zdennis/activerecord-import
Earlier quoted context omitted.
As somebody with an expert level knowledge with MVC frameworks like Ruby on Rails and Phoenix Framework, etc., and an experience building large-scale enterprise-grade apps using simpler technologies like jQuery, StimulusJS and plain old JavaScript on the front end with a little bit of React thrown in here and there, I found Development cycles to be much faster with these simpler stacks overall. The complexity of the…
What would you say the good and bad of GraphQL are? Like, when it is a value-add, and when should it be avoided?
For the disadvantages, I cannot think of any. It is a bit slower than hand rolling your own REST API, but the difference is not severe enough to make you give up on it.
I keep hearing good things about Rails. What are the downsides, other than learning a new language and framework?
All that being said I still use (and like) Rails, currently comparing Phoenix/Elixir to Rails 8 in a side project. But I use typescript w/ Node and Bun in my day job.
When I see articles and discussions about web + stack I can’t but ask “What problem are they actually solving” ? The answer is always: put text on screen . When your business goal is put text on screen the next logical step is to ask how much time and money does the tech stack really save? I have never found a developer that answer that question with a number. That’s a really big problem.
Earlier quoted context omitted.
The obsession with DX tooling is exactly why JS is such an awful developer experience. They always chase something slightly better and constantly change things. Maybe the answer was never in JS eating the entire frontend, and changing the tooling won’t make it better, as it’s always skirting what’s actually good for the web.
> The obsession with DX tooling is exactly why JS is such an awful developer experience. I used to agree but these days with Vite things are a lot smoother. To the point that I wouldn't want to work on UI without fine-grained hot reloads. Even with auto reload in PHP, .NET, etc you will be wasting so much time. Especially if you're working on something that requires interaction with the page that you will be repeatin…
Earlier quoted context omitted.
You absolutely did. It was common practice to stuff things in cookies or query strings to retain state between trips to the server so that some JS could do its job. Every form also normally ends up duplicating validation logic both in JS for client-side pre-submit UX and server-side with whatever errors it returns for the JS to then also need to support and show to the user.
Right, but validation logic and state transferred by the server isn't in-memory state. The fact that the pages completely reload on each request clears a lot of cruft that doesn't get cleared on pages whose lifetime is tens or hundreds of views.
I truly wonder what people do when they want JS full stack both frontend an backend especially with a DB involved. ORM situation looks pretty fragmented or you write pure sql. And then you still have to decide on the backend. Going raw with express? Next.js, well known, but with a questionable agenda (, Remix, Astro, TanStack, and so on. It's a mess, because you always have to recalibrate and re-evaluate what to use.…
I'm personally an elixir Phoenix Fanboy now, so I don't choose rails as my first choice for personal projects, but I think it is an excellent choice for a company. In fact, I would probably recommend it the most over any framework if you need to hire for it.