501–510 of 533 posts
Earlier quoted context omitted.
It's been widely understood in the Ruby community for some time now that metaprogramming—like in the example above—should generally be limited to framework or library code, and avoided in regular application code. Dynamically generated methods can provide amazing DX when used appropriately. A classic example from Rails is belongs_to, which dynamically defines methods based on the arguments provided: class Post This g…
Aren’t all these enhancement methods that are added dynamically to every ActiveRecord a major reason why regular AR calls are painfully slow and it’s better to use .pluck() instead? One builds a whole object from pieces, the other vomits put an array?
Customer.limit(1000).to_a
completes in about 10ms, whereas:
Customer.last(1000).pluck(:id, :name, :tenant_id, :owner_id, :created_at, :updated_at)
runs in around 7ms.
Active Record methods are defined at application boot time as part of the class, they're not rebuilt each time an instance is created. So in a typical web app, there's virtually no performance penalty for working with Active Record objects.
And when you do need raw data without object overhead, .pluck and similar methods are available. It’s just a matter of understanding your use case and choosing the right tool for the job.
Earlier quoted context omitted.
The JS processing and rendering time on an underpowered CPU is the issue, not the payload size. It’s difficult to describe how excruciatingly slow some seemingly simple e-commerce and content sites are to render on my 2019 laptop or how slowly they react to something as simple as a mouseover or how they peg the CPU - while absolutely massively complex and large server-rendered HTML loads and renders in an eyeblink.
Which sites are you thinking off? I can't really speak for those sites anyway, or why they are so slow doing things on the client, but like I said, I've written client-side processing and used my 2011 desktop, and there has been no pegging of the CPU or large latencies when filtering/sorting data client-side. > while absolutely massively complex and large server-rendered HTML loads and renders in an eyeblink. I've no…
Earlier quoted context omitted.
Aren’t all these enhancement methods that are added dynamically to every ActiveRecord a major reason why regular AR calls are painfully slow and it’s better to use .pluck() instead? One builds a whole object from pieces, the other vomits put an array?
It's simply not true that "regular AR calls are painfully slow." In the context of a web request, the time spent instantiating Active Record objects is negligible. For example, on my laptop: Customer.limit(1000).to_a completes in about 10ms, whereas: Customer.last(1000).pluck(:id, :name, :tenant_id, :owner_id, :created_at, :updated_at) runs in around 7ms. Active Record methods are defined at application boot time as…
Earlier quoted context omitted.
Do you understand that decompilers and reverse engineering are a thing? Adversaries are not restricted to using your system the way you designed your system. GraphQL queries are trivial to pull out of Wireshark and other sniffers. If you deliver it to the browser, any determined-enough adversary will have it, period. I wouldn't be surprised in the least if it is already a thing for LLM models to sniff GraphQL endpoin…
> Do you understand that decompilers and reverse engineering are a thing? Do you understand how compiled queries in GraphQL (or even an old-school RDBMS) work? All that gets sent over the wire is the query id. There's physically no way to make the server execute a query the author didn't write.
Earlier quoted context omitted.
> Do you understand that decompilers and reverse engineering are a thing? Do you understand how compiled queries in GraphQL (or even an old-school RDBMS) work? All that gets sent over the wire is the query id. There's physically no way to make the server execute a query the author didn't write.
So you threw out all the benefits of GraphQL. Instead of allowing the frontend to determine what it needs, you need to write a new backend endpoint that will return what's needed for that page. This is no different from writing some /rpc/bffe/get-profile-page call, which is much simpler to write and has much better tooling.
Earlier quoted context omitted.
> What if you have a modal opened with some state? Stimulus controllers can store state. > Or a form filled with data? Again, you can either use a Stimulus controller, or you can just render the data into the form response, depending on the situation. > Or some multi-selection in a list of items that triggers a menu of actions on those items? So, submenus? Again, you can either do it in a Stimulus controller (you can…
> Stimulus controllers can store state. Yes, obviously, but do these maintain state after hot reload?
If you change the JS or the controller itself, obviously, state stored in JS would be lost unless you persisted it locally somehow.
Earlier quoted context omitted.
Which sites are you thinking off? I can't really speak for those sites anyway, or why they are so slow doing things on the client, but like I said, I've written client-side processing and used my 2011 desktop, and there has been no pegging of the CPU or large latencies when filtering/sorting data client-side. > while absolutely massively complex and large server-rendered HTML loads and renders in an eyeblink. I've no…
For sorting the table, perhaps. But for displaying the table in the first place? Static HTML is invariably faster in my experience. IMO there is just no excuse for placeholder elements with loading animations on a content or e-commerce site where it should be possible to provide all the content up front and add some very light JS on top to handle things like image carousels.
Okay, lets assume it is faster by whatever the latency is for a network request.
What sort of use-case are we talking about where a table is displayed on a content or e-commerce side and the user is not allowed to re-sort it?
It's all about the user's experience, not the developer's, and I can't see how a UX that prevents sorting is a better UX. Ditto for a sortable table that refreshes the page each time the user sorts it.
Earlier quoted context omitted.
So you threw out all the benefits of GraphQL. Instead of allowing the frontend to determine what it needs, you need to write a new backend endpoint that will return what's needed for that page. This is no different from writing some /rpc/bffe/get-profile-page call, which is much simpler to write and has much better tooling.
No, our backend serves all the queries that the frontend uses, but (in prod) only the queries that the frontend uses - we compile the queries at build time. When we want to add a new query we figure it out in dev (which allows non-compiled queries, but is not accessible for people outside the company), write it in the frontend, and it will be included in the next build of the backend. This is all pretty basic off the…