3 ms·

On the flip side of that, we use three react libraries at my job: react-table, react-dates, and react-select. If we had been OK just using whatever styles they

On the flip side of that, we use three react libraries at my job: react-table, react-dates, and react-select. If we had been OK just using whatever styles they gave us, it would have been fine. But we have a designer who designs how everything is supposed to look. And even the "style-less" react components have been a nightmare. Just a constant train of bugs to fix, and they still barely function. It would have been way faster to start from scratch, in my opinion. This has all been over 6 months, so it's not like there was some initial payoff period either.

danielvinson 7y ago
As a frontend dev, this really pains me. I’ve worked at many places with the same problems - first of all, pushing back on the designer is incredibly important if something is hard to develop. Most designers are doing their best to make things easy to code, but aren’t developers, so they just don’t know. It’s the engineers job to tell them no when things are exceptionally difficult. If they understand that the style change they want is a 3 month project, maybe they would be happy to design something different. Secondly, frontend is hard. Having a senior react dev who can accurately weigh the trade offs of using external components like that would have been invaluable here. People underestimate how much different in skill level a junior react/frontend dev is from a senior engineer with experience in multiple frameworks. 6 months is long time in terms of dev hours - writing a table from scratch for your use case that works with design is usually a 1-2 sprint task, and that’s absolutely the hardest one there. But more reasonably, work should have been done to make a reusable style library to make this even easier.
- nojvek 7y ago
  Writing data tables isn’t easy. Deffo not a 1-2 week thing and you call it done. The trail of bug fixes and browser edge cases are what slowly get you at the end. +1 on not letting design dictate. Just gotta sit in the room and weigh pros and cons.
  - danielvinson 7y ago
    1-2 sprints, which for most teams is 4-6 weeks. It really depends on use cases... generally startups don't have any need to support old browsers and can enforce current Chrome+Firefox only.

danielvinson 7y ago

As a frontend dev, this really pains me. I’ve worked at many places with the same problems - first of all, pushing back on the designer is incredibly important if something is hard to develop. Most designers are doing their best to make things easy to code, but aren’t developers, so they just don’t know. It’s the engineers job to tell them no when things are exceptionally difficult. If they understand that the style change they want is a 3 month project, maybe they would be happy to design something different. Secondly, frontend is hard. Having a senior react dev who can accurately weigh the trade offs of using external components like that would have been invaluable here. People underestimate how much different in skill level a junior react/frontend dev is from a senior engineer with experience in multiple frameworks. 6 months is long time in terms of dev hours - writing a table from scratch for your use case that works with design is usually a 1-2 sprint task, and that’s absolutely the hardest one there. But more reasonably, work should have been done to make a reusable style library to make this even easier.

nojvek 7y ago
Writing data tables isn’t easy. Deffo not a 1-2 week thing and you call it done. The trail of bug fixes and browser edge cases are what slowly get you at the end. +1 on not letting design dictate. Just gotta sit in the room and weigh pros and cons.
- danielvinson 7y ago
  1-2 sprints, which for most teams is 4-6 weeks. It really depends on use cases... generally startups don't have any need to support old browsers and can enforce current Chrome+Firefox only.