24 ms·

I've been doing web development for 20 years now. I don't know if it's strictly endemic to web or frontend, but I feel like we're solving the same problems over

by lxe 5y ago

I've been doing web development for 20 years now. I don't know if it's strictly endemic to web or frontend, but I feel like we're solving the same problems over and over again, using the same low levels of abstraction. There's no reason for lists to scroll slowly after so many years of scrolling lists. There should just be one way to do a scrolling list, implemented natively and left alone. Yet, in web development, there's always a new and different way to do a thing, with either new, or pretty much the same ways for things to be broken. Grumble grumble

pojzon 5y ago
Its not only in web development but software development as a whole. Very smart ppl very easly fall for “not invented here” way of thinking and pretty much solve the problems that were solved already like hundred times. It’s hard to fight that, seems to be our nature. But this is something that probably diffrentiates “great” devs from “just” devs.
- notreallyserio 5y ago
  I’ve been “burned” many times by using standard off the shelf solutions to problems. Not because they didn’t work or had security issues but because they didn’t do precisely what a stakeholder expected, down to the pixel. No amount of me saying “nobody will notice if our app works the same as everyone else’s” worked.
taneq 5y ago
> I don't know if it's strictly endemic to web or frontend, but I feel like we're solving the same problems over and over again, using the same low levels of abstraction. We've been solving the same problems over and over again ever since someone had the bright idea of putting a display on a computer.
agumonkey 5y ago
There are just a few too many forces at play, the quest for dynamic easy to start rules (css) and immense flexibility while never having to dig into lower layers causes that. Wait another 10 years, and even then..
jaywalk 5y ago
> There should just be one way to do a scrolling list, implemented natively and left alone. I can't even imagine how that would work without turning into something like <select> that can only be minimally styled and has to be (usually poorly) re-implemented to get it to look the way you want it to.
- agent327 5y ago
  Maybe webdevelopers should stop trying to make everything look different from its defaults. It used to be that you could reliably predict what clicking the mouse in a region of the screen would do. It wasn't progress, when webdevelopers threw that out...
  - jaywalk 5y ago
    I understand what you're getting at, but that ship has long since sailed. It's also important to note that changing the look of elements doesn't necessarily mean making their functionality indecipherable. Bad design will always be possible, restrictions to try and stop it are pointless.
  - sabellito 5y ago
    What do you mean "look different from its defaults" in regards to scrolling lists of things? I'm not sure what you meant with the second and third phrases, do they relate to the first point?
  - bryanrasmussen 5y ago
    entertainment media will always develop the ability to arbitrarily control every part of the media presentation, and the web has developed into an entertainment medium. This is why load time is so important, people will wait long times for something they need to do, but will not wait to be entertained.
  - xboxnolifes 5y ago
    Unless browser defaults happen to be the optimal expected behavior for the majority of users, sites will always have an edge by changing them.
arendtio 5y ago
> There should just be one way to do a scrolling list, implemented natively and left alone. Maybe this one implementation should not be implemented natively? (otherwise you would need a new implementation for every platform) However, I agree with you, that in the web development we are missing a mature component library. Everybody seems to build his own library when he needs one. In addition, the libraries to connect components to applications (react, vue, etc.) have their own component formats and logic, so that building components that can be used with different libraries is difficult. Furthermore, building a good component library is in itself a pretty daunting task.
- thrashh 5y ago
  I think it’s a funding issue. A lot of desktop GUI toolkits were funded by the people who created the platform themselves so they had every incentive to make it both flexible and consistent. When I look for a web component, the few component libraries that cover several different components are often extremely incomplete. Often they’re just side projects of a company or even an individual. No one is putting in the money to create something fleshed out. On the other hand, when I look for just a specific component (like a drop down or autocomplete textbox), there are sometimes very complete but because they are a single component, it has its own usage and styling conventions that are going to be completely different from some other component in my app. No one has the funding incentive of building a complete component toolkit for the web.
  - irrational 5y ago
    I was going to suggest Google, except... they really don't, do they? They want everyone to use their own tools/sites/etc. Hmm, maybe Mozilla? But they've been firing all of their staff and cutting way back, so they won't do it. Microsoft? Save reasoning as Google. So... yeah, there probably is nobody that has the incentive to do this.
    - jitl 5y ago
      Microsoft is building a web component framework: https://developer.microsoft.com/en-us/fluentui#/get-started/web https://developer.microsoft.com/en-us/fluentui#/get-started/...
sdfaksdfjalj 5y ago
There page in question is simply a paginated list. There is one way to do it: Render an html list and style it with CSS. Then fucking leave it alone.
zz865 5y ago
If only web front ends worked as well as Visual Basic in 1996.
- starik36 5y ago
  1991
madrox 5y ago
If you think that’s bad, let me talk to you about backend development and the reinvention of CRUD over the same time period…
sergiotapia 5y ago
If you don't invent new ways to render a list how else will you be able to give a talk and get 500 twitter likes?
- lxe 5y ago
  You're right... I'm undermining my own job security here.
vaughan 5y ago
There is not one set of static requirements for lists. New UX paradigms are being invented all the time, which actually make things more usable. E.g. Think about Airtable vs Google Sheets. Also consider data sources and data binding. Do you bind a cell, a row, the entire table? How do you handle real-time updates or infinite scrolling. How is styling done? It always feels like we should just standardize the current thing because we cannot see what will come next. That said, there still does not feel like a good data grid for React, and trying to build one makes it feel like React is just getting in the way.
- Gigachad 5y ago
  Tables like you mention, have infinite complexity and requirements. If all you need is the most basic grid, the built in <table> element is fine. But what happens when you need inline editing, filters, searches, live updating data from a server, keyboard shortcuts, etc. A single standard element will never handle everyone's use cases. The parent comment is seeing new wheels being designed for a high speed train and wondering why they are reinventing the wheel when wheels have existed forever.
  - vaughan 5y ago
    > But what happens when you need My experience is that a lot of these features are more easily implemented than the time taken to handle the edge cases of using existing libraries, getting them to work with your UI framework (React/Angular), and getting them to work with your data service layer.
  - dmitriid 5y ago
    > The parent comment is seeing new wheels being designed for a high speed train and wondering why they are reinventing the wheel when wheels have existed forever. Nope. The parent is seeing reinvention of basic UI capabilities such as a basic table and virtualized scrolling and wondering why they are not available natively
    - johangavle 5y ago
wildrhythms 5y ago
I work in UX, I am constantly being given designs that don't work well with native/semantic elements- a great example is tables. As soon as the table needs some kind of animation, drag-drop behavior, anything like that, I can't use a <table> anymore; or it becomes some frankenstein kafkaesque amalgamation that is impossible to maintain. Does the table really need an animation? (probably not) drag and drop? (probably not) But management and the people in charge of OK'ing these designs have a 'make-it-happen' attitude and nobody really cares about semantic, native feel when they've invested so much into a "design system" that is largely antithetical to that. Select elements are the bane of my existence. Impossible to style. I am constantly re-implementing a <select> because it has to look a certain way. Just terrible.
- danielvaughn 5y ago
  Every time I’m given a table mockup, it’s flexible column widths with a sticky header. It’s damn near impossible even with JavaScript.
  - wildrhythms 5y ago
    100% agree. Also consider that tables, uniquely, size to their content. So a cell's width is actually the width of the widest cell in its column; the cell height is the height of the tallest cell in its row. It's a problem with so much hidden complexity, and people who come up with these beautiful table designs genuinely do not understand the hidden challenges of implementing it.
    - robbiejs 5y ago
      Exactly, non-fixed row heights / column widths are a performance nightmare. I have managed to create a super fast Javascript Data Grid. There are many performance tricks, but the first thing I decided was to give each column a fixed with and each row a fixed height. Here's a One Million Cells demo that shows its performance: https://www.datagridxl.com/demos/one-million-cells https://www.datagridxl.com/demos/one-million-cells.
  - fiddlerwoaroof 5y ago
lucideer 5y ago
While I agree with the sentiment of this comment (there are so many aspects of modern web development that are layers of abstracted complexity to re-invent wheels long-since optimised). However... scrolling lists are, once one gets to thinking about them in depth, a lot more tricky to implement than they are to use. In fact I can't actually think of a better example of something that seems at first glance simple, but upon closer inspection is riddled with challenges. It basically comes down to the simple question of: how do I render as little as possible at a time, but also render everything/anything in the list "immediately" or as fast as possible. These are fundamentally oppositional requirements, and no solution, whether arrived at after 20 or 50 years, will ever not be a compromise of some sort between them.
- dmitriid 5y ago
  > These are fundamentally oppositional requirements That have been solved literally everywhere except the web.
  - lucideer 5y ago
    This isn't in the slightest bit true. Many UI frameworks provide performant list elements, they are not performant in all cases. Recreating the functionality of those list elements on the web is not the hard problem here: optimising them for your specific application is.
    - dmitriid 5y ago
      > This isn't in the slightest but true. It is. I personally used a virtual list with custom rendering in Delphi in early 2000s. It is, for all intents and purposes, a solved problem. That is, solved everywhere else. > Many UI frameworks provide performant list elements, they are not performant in all cases Yes. On the web. > Recreating the functionality of those list elements on the web is not the hard problem here It is a very hard problem on the web because you don't have any APIs to do this properly: asking for element sizes causes the browser to recalculate the layout, you can't batch-render anything, and a million other things that are readily available, once again, literally everywhere else.
tester34 5y ago
Same things happen on native apps. Let it be Winforms or WPF.

by lxe 5y ago

pojzon 5y ago

Its not only in web development but software development as a whole. Very smart ppl very easly fall for “not invented here” way of thinking and pretty much solve the problems that were solved already like hundred times. It’s hard to fight that, seems to be our nature. But this is something that probably diffrentiates “great” devs from “just” devs.

notreallyserio 5y ago
I’ve been “burned” many times by using standard off the shelf solutions to problems. Not because they didn’t work or had security issues but because they didn’t do precisely what a stakeholder expected, down to the pixel. No amount of me saying “nobody will notice if our app works the same as everyone else’s” worked.

taneq 5y ago

> I don't know if it's strictly endemic to web or frontend, but I feel like we're solving the same problems over and over again, using the same low levels of abstraction. We've been solving the same problems over and over again ever since someone had the bright idea of putting a display on a computer.

agumonkey 5y ago

There are just a few too many forces at play, the quest for dynamic easy to start rules (css) and immense flexibility while never having to dig into lower layers causes that. Wait another 10 years, and even then..

jaywalk 5y ago

> There should just be one way to do a scrolling list, implemented natively and left alone. I can't even imagine how that would work without turning into something like <select> that can only be minimally styled and has to be (usually poorly) re-implemented to get it to look the way you want it to.

agent327 5y ago
Maybe webdevelopers should stop trying to make everything look different from its defaults. It used to be that you could reliably predict what clicking the mouse in a region of the screen would do. It wasn't progress, when webdevelopers threw that out...
- jaywalk 5y ago
  I understand what you're getting at, but that ship has long since sailed. It's also important to note that changing the look of elements doesn't necessarily mean making their functionality indecipherable. Bad design will always be possible, restrictions to try and stop it are pointless.
- sabellito 5y ago
  What do you mean "look different from its defaults" in regards to scrolling lists of things? I'm not sure what you meant with the second and third phrases, do they relate to the first point?
- bryanrasmussen 5y ago
  entertainment media will always develop the ability to arbitrarily control every part of the media presentation, and the web has developed into an entertainment medium. This is why load time is so important, people will wait long times for something they need to do, but will not wait to be entertained.
- xboxnolifes 5y ago
  Unless browser defaults happen to be the optimal expected behavior for the majority of users, sites will always have an edge by changing them.

arendtio 5y ago

> There should just be one way to do a scrolling list, implemented natively and left alone. Maybe this one implementation should not be implemented natively? (otherwise you would need a new implementation for every platform) However, I agree with you, that in the web development we are missing a mature component library. Everybody seems to build his own library when he needs one. In addition, the libraries to connect components to applications (react, vue, etc.) have their own component formats and logic, so that building components that can be used with different libraries is difficult. Furthermore, building a good component library is in itself a pretty daunting task.

thrashh 5y ago
I think it’s a funding issue. A lot of desktop GUI toolkits were funded by the people who created the platform themselves so they had every incentive to make it both flexible and consistent. When I look for a web component, the few component libraries that cover several different components are often extremely incomplete. Often they’re just side projects of a company or even an individual. No one is putting in the money to create something fleshed out. On the other hand, when I look for just a specific component (like a drop down or autocomplete textbox), there are sometimes very complete but because they are a single component, it has its own usage and styling conventions that are going to be completely different from some other component in my app. No one has the funding incentive of building a complete component toolkit for the web.
- irrational 5y ago
  I was going to suggest Google, except... they really don't, do they? They want everyone to use their own tools/sites/etc. Hmm, maybe Mozilla? But they've been firing all of their staff and cutting way back, so they won't do it. Microsoft? Save reasoning as Google. So... yeah, there probably is nobody that has the incentive to do this.
  - jitl 5y ago
    Microsoft is building a web component framework: https://developer.microsoft.com/en-us/fluentui#/get-started/web https://developer.microsoft.com/en-us/fluentui#/get-started/...

sdfaksdfjalj 5y ago

There page in question is simply a paginated list. There is one way to do it: Render an html list and style it with CSS. Then fucking leave it alone.

zz865 5y ago

If only web front ends worked as well as Visual Basic in 1996.

starik36 5y ago
1991

madrox 5y ago

If you think that’s bad, let me talk to you about backend development and the reinvention of CRUD over the same time period…

sergiotapia 5y ago

If you don't invent new ways to render a list how else will you be able to give a talk and get 500 twitter likes?

lxe 5y ago
You're right... I'm undermining my own job security here.

vaughan 5y ago

There is not one set of static requirements for lists. New UX paradigms are being invented all the time, which actually make things more usable. E.g. Think about Airtable vs Google Sheets. Also consider data sources and data binding. Do you bind a cell, a row, the entire table? How do you handle real-time updates or infinite scrolling. How is styling done? It always feels like we should just standardize the current thing because we cannot see what will come next. That said, there still does not feel like a good data grid for React, and trying to build one makes it feel like React is just getting in the way.

Gigachad 5y ago
Tables like you mention, have infinite complexity and requirements. If all you need is the most basic grid, the built in <table> element is fine. But what happens when you need inline editing, filters, searches, live updating data from a server, keyboard shortcuts, etc. A single standard element will never handle everyone's use cases. The parent comment is seeing new wheels being designed for a high speed train and wondering why they are reinventing the wheel when wheels have existed forever.
- vaughan 5y ago
  > But what happens when you need My experience is that a lot of these features are more easily implemented than the time taken to handle the edge cases of using existing libraries, getting them to work with your UI framework (React/Angular), and getting them to work with your data service layer.
- dmitriid 5y ago
  > The parent comment is seeing new wheels being designed for a high speed train and wondering why they are reinventing the wheel when wheels have existed forever. Nope. The parent is seeing reinvention of basic UI capabilities such as a basic table and virtualized scrolling and wondering why they are not available natively
  - johangavle 5y ago

wildrhythms 5y ago

I work in UX, I am constantly being given designs that don't work well with native/semantic elements- a great example is tables. As soon as the table needs some kind of animation, drag-drop behavior, anything like that, I can't use a <table> anymore; or it becomes some frankenstein kafkaesque amalgamation that is impossible to maintain. Does the table really need an animation? (probably not) drag and drop? (probably not) But management and the people in charge of OK'ing these designs have a 'make-it-happen' attitude and nobody really cares about semantic, native feel when they've invested so much into a "design system" that is largely antithetical to that. Select elements are the bane of my existence. Impossible to style. I am constantly re-implementing a <select> because it has to look a certain way. Just terrible.

danielvaughn 5y ago
Every time I’m given a table mockup, it’s flexible column widths with a sticky header. It’s damn near impossible even with JavaScript.
- wildrhythms 5y ago
  100% agree. Also consider that tables, uniquely, size to their content. So a cell's width is actually the width of the widest cell in its column; the cell height is the height of the tallest cell in its row. It's a problem with so much hidden complexity, and people who come up with these beautiful table designs genuinely do not understand the hidden challenges of implementing it.
  - robbiejs 5y ago
    Exactly, non-fixed row heights / column widths are a performance nightmare. I have managed to create a super fast Javascript Data Grid. There are many performance tricks, but the first thing I decided was to give each column a fixed with and each row a fixed height. Here's a One Million Cells demo that shows its performance: https://www.datagridxl.com/demos/one-million-cells https://www.datagridxl.com/demos/one-million-cells.
- fiddlerwoaroof 5y ago

lucideer 5y ago

While I agree with the sentiment of this comment (there are so many aspects of modern web development that are layers of abstracted complexity to re-invent wheels long-since optimised). However... scrolling lists are, once one gets to thinking about them in depth, a lot more tricky to implement than they are to use. In fact I can't actually think of a better example of something that seems at first glance simple, but upon closer inspection is riddled with challenges. It basically comes down to the simple question of: how do I render as little as possible at a time, but also render everything/anything in the list "immediately" or as fast as possible. These are fundamentally oppositional requirements, and no solution, whether arrived at after 20 or 50 years, will ever not be a compromise of some sort between them.

dmitriid 5y ago
> These are fundamentally oppositional requirements That have been solved literally everywhere except the web.
- lucideer 5y ago
  This isn't in the slightest bit true. Many UI frameworks provide performant list elements, they are not performant in all cases. Recreating the functionality of those list elements on the web is not the hard problem here: optimising them for your specific application is.
  - dmitriid 5y ago
    > This isn't in the slightest but true. It is. I personally used a virtual list with custom rendering in Delphi in early 2000s. It is, for all intents and purposes, a solved problem. That is, solved everywhere else. > Many UI frameworks provide performant list elements, they are not performant in all cases Yes. On the web. > Recreating the functionality of those list elements on the web is not the hard problem here It is a very hard problem on the web because you don't have any APIs to do this properly: asking for element sizes causes the browser to recalculate the layout, you can't batch-render anything, and a million other things that are readily available, once again, literally everywhere else.

tester34 5y ago

Same things happen on native apps. Let it be Winforms or WPF.