Frontend development started as web-designer-plus thing
In the era of HTML/CSS and Flash, JavaScript was used by a few developers and widespread mainly by web designers as black box gimmicks that allow interaction between the HTML and some dynamic behavior. Managing conflicts, dependencies and versions soon became nightmarish, and it was clear that there was a road ahead.
Besides offering sites displaying fancy animations, companies started betting on web applications, either for interacting with customers or internally within collaborators. HTML was being produced by server code within the realm of full-fledged developers. Also, the tools and speed were on the server side. Modularity and code reuse (for example, using HTML templates) was readily applied using technologies like ASP or JSP.
Classic programming paradigms in front-end technologies
Fast-forward to the second decade of the second millennium and the front-end web programming is a vast and evolving world. One where the classic programming paradigms, I’ve learned in computer science, fully apply. Even to a visual style description language like CSS. With the rush to a more demanding style of web applications, CSS have been the nightmare of enterprise programming, with horrendous scalability and maintainability. To dominate the beast, SASS and LESS extended the language with things like variables, structure and code reuse. Also, some techniques like AtomicCSS or SMACSS were created to give styling some more structure and rationale. More recently, Angular2 achieved full CSS (and SASS, LESS) modularity.
Even programming patterns and paradigms until recently reserved to core and/or scholar developers are now being applied to front-end programming, like functional programming, immutables, observables and asynchronous programming. Even object oriented programming is being considered unsuitable for asynchronous programming. A tighter control with functional programming, immutables and observables, seems to produce more predictable code behavior, besides allowing more modularity and testability.
To please the hard-core developers used to Java or C#, the front-end technologies needed to solve the JavaScript problem. JavaScript is a loose language, with no static typing and thus no type enforcing or warnings, whatsoever. Changing the name of a variable or a function’s signature is a nightmare, both in effectiveness and efficiency. For medium to big projects, Typescript (invented by the same author of C#) is a JavaScript ES6 extension, that flexibly introduces all the language constructs that server side developers are used to, like static type checking, generics, object classes and more. Powerful IDEs exist to assist in various aspects of typescript programming, namely code refactoring.
Several client-side frameworks exist for years now, but the latest kid on the block is the version 2 of AngularJS. This is a totally revamped version and non-backwards compatible. But it introduces major features and a new architecture that totally appeals to server side core programmers. The new architecture features a solid modularity and a higher separation between view and the logic that governs it, besides separation of business logic which was already easy with the initial AngularJS version. Moreover, lazy loading of components (needed by the user navigation) and possible server side rendering (Angular Universal), places Angular2 as a high qualified framework for the most demanding applications.
Front-end web development has even evolved to allow for developing of mobile apps using client-side web languages and frameworks, with several degrees of sharing of the same codebase for the different mobile platforms and the web. Version 2 of Ionic, for example allows Angular2, Typescript and Cordova to produce cross-platform applications with major productivity gains, not only in cost and time-to-market but also in maintainability. For several reasons, not all application types are suitable for this cross-platform apps, but a lot do. I tend to believe that for line-of-business apps, most do.
Separation of concerns: UI/UX vs. services
The current state of front-end technologies allows for the long pursued separation of concerns to a high degree:
- Back-end programming. Database, business logic, AI, statistical algorithms, data mining, and the like, all remain in the server realm, exposing its functionality by means of an web API. Non-visual oriented programmers can totally keep away from HTML and CSS. In fact, with these technologies the back/front projects have separate life-cycles and architectures.
- Front-end view logic and application architecture. Interfaces with the back-end, and implements the web application. Pleases more visual oriented programmers, but also offers an advanced architecture and advanced programming paradigms.
- Front-end building and release system. Specializes in building, packaging code and publish architecture, with complex tools also allowing for integration in cloud services.
- Web Designer. Coordinates a style guide and implements the design using HTML5, SASS/LESS. For high specialized and complete projects, this job can demand focused personnel. Things can get complicated when introducing support for multiple form factors, for different browser access speeds, high DPI images or vector graphics.
- Graphic Designer. Can be a different professional than the Web Designer, and focuses primarily on the concept and development of the user interface and user experience. Shares work with the Web Designer in the style guide, mainly.
Developers can do app view logic and kept away from HTML
Until recently back-end core programmers looked at producing visual oriented code (like HTML) as a nuisance and often resulted in a neglected area. Nowadays this area can no longer be neglected, and projects tend to have more and more of front-end programming. This has been a problem since some back-end core programmers must be converted to the front-end domain. But thankfully, with the high separation of concerns allowed by current front-end technologies, each programmer class can focus on the area he/she knows best. Besides, the high degree of separation between view logic and view can make some back-end programmers quite comfortable in the front-end realm of the view logic and application architecture, where they do not need to produce a single HTML tag or CSS rule!
Have fun!