4 ms·

It depends on what part of browsers are being spoken about. They’re plenty flexible and capable for the case of traditional pages and server-side apps, but it’s

It depends on what part of browsers are being spoken about. They’re plenty flexible and capable for the case of traditional pages and server-side apps, but it’s a totally different story for interactive widgets and especially full blown SPA’s. For example, browsers don’t furnish a tableview/datagrid or even a basic single column recycler view, meaning one has to find a third party library to do those things that’s still maintained, fits into your stack, and has holes in functionality that are tolerable for the use case in question, or if none meet those criteria write it themselves. The result is a million reimplementations of the same thing nearly all of which have major shortcomings (some of which are present only because they aren’t implemented as a native browser control). I totally get that styling is a pivotal part of web apps but I think that can be maintained without requiring devs to build castles from grains of sand instead of giving them more appropriate building materials to use.

DaiPlusPlus 3y ago
> For example, browsers don’t furnish a tableview/datagrid or even a basic single column recycler view <table> and <ol>? Or am I missing something?
- jwells89 3y ago
  Goes back to static vs. dynamic/interactive. That’s fine for static content but falls apart when you need a table view that can be edited, sorted, reordered, can have columns resized/rearranged, and can contain thousands of rows (necessitating recycling of table row DOM elements to maintain performance and efficiency). This sort of view has been table stakes for desktop UI frameworks for decades and is a common need.
- fidotron 3y ago
  The big question is how the table gets populated with the data and enables things like column based sorting all executed on the client side. (With the associated interactions with scrolling). The point of recycling views is as row UI elements scroll off the top they are reused for those appearing at the bottom (or vice versa) which reduces system resources for these things a lot. This way the data table can contain 20 million rows but if the user can only see 100 the UI only pays the cost for 100. This is standard practice in native app dev and I think is a good example for the case they are making. I would argue such a thing would be needed in the hypothetical NeXT type API of course.

DaiPlusPlus 3y ago

> For example, browsers don’t furnish a tableview/datagrid or even a basic single column recycler view <table> and <ol>? Or am I missing something?

jwells89 3y ago
Goes back to static vs. dynamic/interactive. That’s fine for static content but falls apart when you need a table view that can be edited, sorted, reordered, can have columns resized/rearranged, and can contain thousands of rows (necessitating recycling of table row DOM elements to maintain performance and efficiency). This sort of view has been table stakes for desktop UI frameworks for decades and is a common need.
fidotron 3y ago
The big question is how the table gets populated with the data and enables things like column based sorting all executed on the client side. (With the associated interactions with scrolling). The point of recycling views is as row UI elements scroll off the top they are reused for those appearing at the bottom (or vice versa) which reduces system resources for these things a lot. This way the data table can contain 20 million rows but if the user can only see 100 the UI only pays the cost for 100. This is standard practice in native app dev and I think is a good example for the case they are making. I would argue such a thing would be needed in the hypothetical NeXT type API of course.