4 ms·
OK but my understanding is that modern approaches to client side JS are based around the concept of web components. In which case, even though the JS code encom
by Myrmornis 6y ago
OK but my understanding is that modern approaches to client side JS are based around the concept of web components. In which case, even though the JS code encompasses many areas of software engineering (data flow, dealing with asynchronous events, MVC-like architectures to achieve separation of concerns etc) there is no escaping the fact that part of your code is directly representing a DOM which is rendered as a UI. So I'm not sure I believe that client-side JS can really be divorced from the design of the UI. Sure, the CSS can be done by someone else, but the choice of components that exist in the (virtual) DOM is necessarily very much part of the UI design isn't it?
- jmchuster 6y agoRight, that's why designers generally work with a component library, in an application like Sketch that is designed for building websites and mobile apps. Your component library might first start off with just all the basic HTML stuff, but that eventually becomes tailored to your company's own custom stuff. You're not just hiring abstract artists who then whip up a fever dream in photoshop.
- Myrmornis 6y agoOk, so in the setup you describe can the js engineers focus on software engineering and not be involved in the choice of components and UI layout design? I.e. they can have all that handed to them by a designer? I didn’t know that, in my experience the JS engineers also design the UI layout (but have designers work on CSS styling )
- jmchuster 6y agoSo, if you start off with something new or large, your UI/UX designers would be the ones driving all the work. Then once you're working on something established, then your developers might suggest components based on common patterns they know, and then ask designers to validate it. And then once you're adding trivial things, like another field to a form, you wouldn't involve the designer at all.
- Silhouette 6y agoThe recurring theme in this whole discussion is "it depends", and that is the case here as well. If you're building a relatively simple UI, using common features like buttons and text boxes and maybe some simple charts, you might well do what has been mentioned in this thread. You can identify reusable pieces that the designers can use to define layouts and specify styling and that the programmers can use to implement those things in code. This is an easy method of UI design and implementation, and often it is all you need. If you're building something more challenging -- a rich document editor, a game, an interactive 3D visualisation of a complicated data set, basically anything that isn't just a combination of standard controls and UI patterns -- then the main part in your UI might not fit that component model very well at all. Now you're going to have to approach both the UI design and the programming from a different direction, just as you would in desktop, mobile or embedded software. This is harder, because you're moving away from patterns and tools that are well understood and readily available, and instead you're building something original. However, it's also much more flexible for the same reason, and sometimes that's what you need. Even in the latter case, you will often need standard features in your UI that can be designed and built as individual components as well. There's no rule that says you can't have a hybrid with both reusable components for the simpler, recurring features and then one or more features that are more sophisticated.