3 ms·

Golden rule of UI development: do not block the UI thread with I/O. With ORM packages, the degree of I/O becomes proportional to the app's feature growth, and

by 762236 9y ago

Golden rule of UI development: do not block the UI thread with I/O. With ORM packages, the degree of I/O becomes proportional to the app's feature growth, and the UI eventually stutters. I've been on several successful app teams, and everyone that started with ORMs had to throw them away to solve stutter, and since the data and threading models of the apps were written around ORMs, they had to be mostly rewritten. Going through this, I also noticed that the before and after ORM code was about the same in line numbers, and it didn't save time to use the ORM (because ORMs have lots of negatives that required time to work around, e.g., distancing you from control over the use of indices). For a great example of successful UI code, see Chromium, which explicitly outlaws blocking I/O on the UI thread.

BoorishBears 9y ago
What aspect of an ORM encourages blocking the UI thread anymore than direct DB access? Most Android ORMs explicitly make it easier not to block the UI thread by offering callbacks and reactive streams. >For a great example of successful UI code, see Chromium, which explicitly outlaws blocking I/O on the UI thread. Android explicitly outlaws network I/O on the UI thread by default, and can be configured to block disk I/O too via StrictMode
lmm 9y ago
> Golden rule of UI development: do not block the UI thread with I/O. This doesn't have to mean avoiding ORMs; it means separating frontend from backend with an explicit, narrow interface between the two, but that's no reason not to use an ORM in the backend piece. > I've been on several successful app teams, and everyone that started with ORMs had to throw them away to solve stutter, and since the data and threading models of the apps were written around ORMs, they had to be mostly rewritten. Even in that kind of case (which doesn't match my experience) that doesn't mean the ORM was a mistake; 90% of apps fail, so if you can save time on getting to the point where you can verify product/market fit one way or another, that's well worth doing even if it leads to more work in the cases where you do want to develop the app further. > Going through this, I also noticed that the before and after ORM code was about the same in line numbers, and it didn't save time to use the ORM (because ORMs have lots of negatives that required time to work around, e.g., distancing you from control over the use of indices). Not my experience. Or rather, that matches my experience on teams that tried to maintain manual control over the database while using an ORM, but teams that were willing to embrace the ORM and use the database in an ORM-first way (i.e. the ORM is the source of truth about what the schema looks like, and the DDL is generated from that) have been able to save a significant amount of code and have a lower defect rate.
hota_mazi 9y ago
Getting rid of your ORM because you get stutters is silly: just find out where the stutters are and address these surgically, either by using more specialized features of your ORM or just dropping back to straight SQL. ORM's are still a great solution for a wide majority of scenarios.

by 762236 9y ago

BoorishBears 9y ago

What aspect of an ORM encourages blocking the UI thread anymore than direct DB access? Most Android ORMs explicitly make it easier not to block the UI thread by offering callbacks and reactive streams. >For a great example of successful UI code, see Chromium, which explicitly outlaws blocking I/O on the UI thread. Android explicitly outlaws network I/O on the UI thread by default, and can be configured to block disk I/O too via StrictMode

lmm 9y ago

> Golden rule of UI development: do not block the UI thread with I/O. This doesn't have to mean avoiding ORMs; it means separating frontend from backend with an explicit, narrow interface between the two, but that's no reason not to use an ORM in the backend piece. > I've been on several successful app teams, and everyone that started with ORMs had to throw them away to solve stutter, and since the data and threading models of the apps were written around ORMs, they had to be mostly rewritten. Even in that kind of case (which doesn't match my experience) that doesn't mean the ORM was a mistake; 90% of apps fail, so if you can save time on getting to the point where you can verify product/market fit one way or another, that's well worth doing even if it leads to more work in the cases where you do want to develop the app further. > Going through this, I also noticed that the before and after ORM code was about the same in line numbers, and it didn't save time to use the ORM (because ORMs have lots of negatives that required time to work around, e.g., distancing you from control over the use of indices). Not my experience. Or rather, that matches my experience on teams that tried to maintain manual control over the database while using an ORM, but teams that were willing to embrace the ORM and use the database in an ORM-first way (i.e. the ORM is the source of truth about what the schema looks like, and the DDL is generated from that) have been able to save a significant amount of code and have a lower defect rate.

hota_mazi 9y ago

Getting rid of your ORM because you get stutters is silly: just find out where the stutters are and address these surgically, either by using more specialized features of your ORM or just dropping back to straight SQL. ORM's are still a great solution for a wide majority of scenarios.