4 ms·

The front end framework mess is just a symptom of the actual problem, which is that the building blocks provided by browsers are too crude/limited to allow for

The front end framework mess is just a symptom of the actual problem, which is that the building blocks provided by browsers are too crude/limited to allow for consistent quality, and so Rube Goldberg machine frameworks arise to try to paper it all over. I think browsers can be a good platform but for that to happen they need to be a bit more batteries-included, with built in APIs for UI and other essentials that rival those of desktop platforms so crazy frameworks are rendered unnecessary.

fidotron 3y ago
Honestly, I believe you have this backwards; the problem with browsers is they are too flexible and complicated. If you delivered a consistent MVC framework in the style of the classic NeXT APIs the major complaint would be the imposed look and feel, which from the point-of-view of a user is a feature, but for whatever reason people are drawn like moths to a flame towards that which is at the edge of reasonably possible and so devs and designers will forever be pushing at the limits until this state of chaos recurs.
- jwells89 3y ago
  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.

fidotron 3y ago

Honestly, I believe you have this backwards; the problem with browsers is they are too flexible and complicated. If you delivered a consistent MVC framework in the style of the classic NeXT APIs the major complaint would be the imposed look and feel, which from the point-of-view of a user is a feature, but for whatever reason people are drawn like moths to a flame towards that which is at the edge of reasonably possible and so devs and designers will forever be pushing at the limits until this state of chaos recurs.

jwells89 3y ago
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.