large_Crossover Series NFTs.png

medium_Crossover Series NFTs.png

small_Crossover Series NFTs.png

thumbnail_Crossover Series NFTs.png

From Photography to NFT Art: Twisted Digital Landscapes with Nate Hill

From Design System to ‘NFT Design System’: Creating TinyFaces

Neurodiversity and Inclusion: Choosing Kinder Design

medium_652ccf22c8853584bde5553986a4eed0.png

small_652ccf22c8853584bde5553986a4eed0.png

thumbnail_652ccf22c8853584bde5553986a4eed0.png

Web5 is here. Goodbye Web3? TBD.

Published on <a href="https://blog.prototypr.io/thinking-in-components-better-from-front-to-back-7b43e4f2273f?source=rss----eb297ea1161a---4">| Prototyping: From UX to Front End &mdash; Medium</a> Aaron Smith <img alt="" src="https://cdn-images-1.medium.com/max/960/1*tSgbw7NFS-TSNZ_HQjj0hQ.png">
With the advent of large-scale, component-based CMSs like Sitecore and Adobe AEM, back-end development teams have had to adapt to developing with the idea of reuse in future development cycles in mind. Likewise, the front-end development teams that work with them should adapt to the changing development landscape when developing for a CMS. The increasingly widespread practice of component-based development across teams helps ease the transition of code between development specialties, previously one of the most challenging and time-consuming tasks in a development life cycle. By rethinking the way that front-end development teams work, we can help increase developer productivity, ease unit testing and debugging, and substantially reduce impact on timelines and budgets.
Out with the Old: Page-Based Development
Using a page-based development approach tends to hinder the development life cycle in a variety of ways. The process would begin with front-end developers creating full-page templates based on the approved creative, and back-end developers would have to sift through documentation to accurately determine the beginning and end of each individual component. This lapse often led to elongated timelines, communication issues, and additional back and forth for both parties, but more often the majority of the time-consuming documentation discovery burden falls on the back-end development team.
In with the New: Component-Based Development
Using a component-based development approach enables iterative, agile development throughout the project lifecycle. This ideology allows developers to work side by side, creating back-end integration with large scale CMSs like Adobe AEM or Sitecore, and letting the front-end developers take over, compose, and polish the components afterwards. This improved, parallel teamwork strategy offers the benefit of continuous delivery and iteration without the blocks of a turn-based development strategy.
<img alt="" src="https://cdn-images-1.medium.com/max/624/0*fgm7UWce6f2-ZJYR.">
The Front-End Use Case
Implementing reusable components helps keep design consistent and can provide clarity in organizing code. By using a well-thought-out html component structure, the development teams are provided a clear use case for each component without the issue of scoping or miscommunication. Each of these front-end pieces should be independent, clearly defined, encapsulated, and above all, reusable. For consistency, frameworks such as Bootstrap should be utilized for their rigorous testing and widespread knowledge libraries. These highly regarded frameworks integrate well with component-based sites, and observe formats that can be easily interpreted by anyone with a background in development.
Quicker Updates with SASS
A set of well-organized Syntactically Awesome Style Sheets (SASS) adds to the component’s ability to be updated quickly, and allows for more confidence in those areas which will and won’t be affected. Placing appropriate mixins, extensions, and variables related to a component in the same location as the component styles can lead to a better organized and clearer style architecture. As with the HTML structure that they style, each of these SASS files should be completely independent and reusable. This will allow for more global styles, such as fonts and colors, to be imported without the fear of disrupting a component’s style or functionality while adjusting another.
<img alt="" src="https://cdn-images-1.medium.com/max/624/0*x26pzTco1UF9DnWI.">
Meet the Future: Component-Driven Architecture
Currently popular and emerging web technologies are favoring component-driven architecture. Using what is currently available, as front-end developers we can improve the development cycle of all CMS projects and work towards the future of our discipline. Whether this skillset is leveraged against Javascript frameworks such as React or Angular, or the emerging Web Component specification, we have the ability to not only shape the way we develop, but change the mindset of the teams within which we work.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=7b43e4f2273f" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="https://blog.prototypr.io/thinking-in-components-better-from-front-to-back-7b43e4f2273f">Thinking in Components — Better from Front to Back</a> was originally published in <a href="https://blog.prototypr.io">prototypr</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Thinking in Components — Better from Front to Back

Thinking in Components — Better from Front to Back

Top Stories