3 ms·

> I don't know what meredydd talks about, there's no mismatch with regards to data. He's talking about different services each having their own preferred way t

> I don't know what meredydd talks about, there's no mismatch with regards to data. He's talking about different services each having their own preferred way to structure the data. When the layout differs, it cannot simply be a memcpy, and so you get tools to try to ease the tedium of translating one structure's layout into to another. They get the job done most of the time, but run into edge cases that return the developer back to manual tedium. Since developers do not like tedious work, some set out to find a new solution that solves for those edge cases, but they end up leaving many more on the table for the next intrepid developer.

pas 8y ago
> own preferred way to structure the data. Absolutely. But user/business data? That doesn't matter. When you design the system/stack you pick the right components/tools (right data structures) that can losslessly represent the input/output of the neighboring/adjacent layers. If you want to store 500 byte long fields, then make your DB column 500 byte wide, make sure the backend accepts 500 byte long input, but rejects longer ones, make sure your HTML input has a maxlen=500 (and account for Unicode code point surrogate / multibyte fuckery if applicable) There's mismatch, of course, but as I've detailed in a sibling comment [0], it's because of difference in purpose and function. A DB is different from a HTML/CSS layout rendering engine, because they have a very (set) of purpose(s), hence different interfaces, and so on. And frameworks are glue between these functions (and the layers as we allocate them to). > Since developers do not like tedious work, some set out to find a new solution that solves for those edge cases [...] Yes, perfectly agreed. And since we concentrate on different edge-cases each time, we move from trade-off to trade-off with each new framework, and browsing trend/fad (mobile, tablet, SSR, ultra-tree-shakable-gzip-able, "native" [mobile] compilable, etc). [0] https://news.ycombinator.com/item?id=17209305 https://news.ycombinator.com/item?id=17209305

pas 8y ago

> own preferred way to structure the data. Absolutely. But user/business data? That doesn't matter. When you design the system/stack you pick the right components/tools (right data structures) that can losslessly represent the input/output of the neighboring/adjacent layers. If you want to store 500 byte long fields, then make your DB column 500 byte wide, make sure the backend accepts 500 byte long input, but rejects longer ones, make sure your HTML input has a maxlen=500 (and account for Unicode code point surrogate / multibyte fuckery if applicable) There's mismatch, of course, but as I've detailed in a sibling comment [0], it's because of difference in purpose and function. A DB is different from a HTML/CSS layout rendering engine, because they have a very (set) of purpose(s), hence different interfaces, and so on. And frameworks are glue between these functions (and the layers as we allocate them to). > Since developers do not like tedious work, some set out to find a new solution that solves for those edge cases [...] Yes, perfectly agreed. And since we concentrate on different edge-cases each time, we move from trade-off to trade-off with each new framework, and browsing trend/fad (mobile, tablet, SSR, ultra-tree-shakable-gzip-able, "native" [mobile] compilable, etc). [0] https://news.ycombinator.com/item?id=17209305 https://news.ycombinator.com/item?id=17209305