3 ms·

I believe the Model View Controller or Model Template View architectures provide sufficient separation of concerns without requiring separate codebases, teams,

by brylie 5y ago

I believe the Model View Controller or Model Template View architectures provide sufficient separation of concerns without requiring separate codebases, teams, tooling, and project management.

egeozcan 5y ago
I didn't mean the classic separation of concerns. I meant that front-end development should be taken seriously enough to (sometimes) warrant its own focused team. A proper FE developer who knows about accessibility (not just ARIA-attributes but also contrast and usability), UX, semantics, and also being capable of delivering performant user interfaces is rare these days, because people think full-stack development really is a thing. I think it is one of those mythical things like a 1000x engineer. People think that they can get away with 90s style websites, but please test stuff with a screen-reader, and also while you're there get some front-end consulting, you will be surprised how badly you may be doing. IMHO, many need dedicated FE development. Whether they use React or not, I think many do. You can distribute many responsibilities on non-technical members of the team, but then you start thinking "couldn't they just learn a bit templating so I don't invest so much time on implementing their seemingly never-ending requirements"! BTW, this separation is of course also possible with your traditional MVC stack, which I also use in my personal projects a lot, in which React is indeed overkill, and there are many cases that a bunch of templates deliver all the things you may ever need. If it gets complicated enough some day, return your View Model as JSON and there you have a perfect API. IMHO REST APIs aren't suitable for any dynamic front-end development anyway. The only reason I wrote that single sentence in my previous original comment is that React forces your hand a bit, in this matter. It's a small point among other things.
- JasonCannon 5y ago
  Doing a ground up rewrite of our app at work. I made the call that the application needed to be semantically correct (well, mostly correct. We avoid div everywhere), have proper tab order, and be screen reader accessible. It takes more time but honestly it's not that difficult to do. Most people just.... Don't do it.
  - egeozcan 5y ago
    It doesn't end there. Even caring a bit for that makes a huge difference, I agree, and I appreciate the effort. The last time we had an accessibility audit, however, it was consisting of more than 200 problems with different priorities for an app with 70 something views. Our FE people were immediately up to the task of getting them fixed; a motivation I simply cannot expect from anyone who doesn't have a front-end focus. My basic checker reports in this simple comment-editor already a couple of problems. It also doesn't end there. There's the UX part, re-usability (huge difference to have a cross-team front-end service-team), performance (not just initial load... Are the widgets you build with, say, Alpine.js tested for performance?), development speed, caching, offline-capabilities, opportunistic rendering, other best practices, branding, consistent design and interaction and so on. It's a science on its own. Front-end is not just some basic thing which got a complex solution for no reason. It is a complicated task.

by brylie 5y ago

I believe the Model View Controller or Model Template View architectures provide sufficient separation of concerns without requiring separate codebases, teams, tooling, and project management.

egeozcan 5y ago

I didn't mean the classic separation of concerns. I meant that front-end development should be taken seriously enough to (sometimes) warrant its own focused team. A proper FE developer who knows about accessibility (not just ARIA-attributes but also contrast and usability), UX, semantics, and also being capable of delivering performant user interfaces is rare these days, because people think full-stack development really is a thing. I think it is one of those mythical things like a 1000x engineer. People think that they can get away with 90s style websites, but please test stuff with a screen-reader, and also while you're there get some front-end consulting, you will be surprised how badly you may be doing. IMHO, many need dedicated FE development. Whether they use React or not, I think many do. You can distribute many responsibilities on non-technical members of the team, but then you start thinking "couldn't they just learn a bit templating so I don't invest so much time on implementing their seemingly never-ending requirements"! BTW, this separation is of course also possible with your traditional MVC stack, which I also use in my personal projects a lot, in which React is indeed overkill, and there are many cases that a bunch of templates deliver all the things you may ever need. If it gets complicated enough some day, return your View Model as JSON and there you have a perfect API. IMHO REST APIs aren't suitable for any dynamic front-end development anyway. The only reason I wrote that single sentence in my previous original comment is that React forces your hand a bit, in this matter. It's a small point among other things.

JasonCannon 5y ago
Doing a ground up rewrite of our app at work. I made the call that the application needed to be semantically correct (well, mostly correct. We avoid div everywhere), have proper tab order, and be screen reader accessible. It takes more time but honestly it's not that difficult to do. Most people just.... Don't do it.
- egeozcan 5y ago
  It doesn't end there. Even caring a bit for that makes a huge difference, I agree, and I appreciate the effort. The last time we had an accessibility audit, however, it was consisting of more than 200 problems with different priorities for an app with 70 something views. Our FE people were immediately up to the task of getting them fixed; a motivation I simply cannot expect from anyone who doesn't have a front-end focus. My basic checker reports in this simple comment-editor already a couple of problems. It also doesn't end there. There's the UX part, re-usability (huge difference to have a cross-team front-end service-team), performance (not just initial load... Are the widgets you build with, say, Alpine.js tested for performance?), development speed, caching, offline-capabilities, opportunistic rendering, other best practices, branding, consistent design and interaction and so on. It's a science on its own. Front-end is not just some basic thing which got a complex solution for no reason. It is a complicated task.