The JavaScript language is moving quickly and accumulating the best features from a variety of languages. If you are a team, already deep into maintaining a code base, adopting the latest syntax additions to the language will be challenging. The only possible way is to slowly spread the love of latest and greatest JS.

Start small, refactor a part of the code or write some new code with the latest features, sneak it in and see if it flies. If you are more adventurous (and why not?), you could also refactor a part of the code-base, may be a small feature and bring in the latest JS. Whatever be your route, the change has to happen, today or tomorrow and Refactoring is a great way to ease in to the new syntax, from ES5 to ES2015+.

Modern JavaScript Refactoring is a short course that takes a ES5 centric code-base and transitions it with ES2015+ style of syntax. It takes a typical use-case of fetching some information from the cloud and connecting it to a React frontend.

In doing so, we adopt a variety of language features like:

• Template Strings
• Arrow Functions
• Destructuring
• Classes
• import/export of modules
• async-await

We will do some refactoring with the React component by breaking it down and adding Material UI.

The course also covers a few tips on naming, domain driven design and touches upon the S principle (Single Responsibility) from SOLID.

You are free to enroll and keep the course forever! Work at your own pace and follow along if you want.

So, let’s use refactoring as our means to take on the modern JavaScript. Look forward to seeing you in the course.

A free-to-enroll course on Modern JavaScript Refactoring was originally published in The UI Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

For someone starting new into the world of UI Development or Frontend, this is a existential question that bothers them. How do you define this field and who exactly is a UI Developer? And it’s not just newcomers, even seasoned folks have some trouble articulating what it is to be a UI Developer 🤔

I have been a Frontend / UI Developer since 2001 (yes, quite a long time!) and it has taken me many years to really crystallize my thoughts on “what exactly is this profession”. From my point of view:

It’s all about building a visual, interactive representation of your domain. Development itself comes down to: 80% Software Engineering, 20% Platform / Framework

Huh? Ya, sounds too abstract. 👆 TL;DR; is not easy 🧐. Let me expand below…

UI Development = UI + Development

UI = Visual, Interactive representation of Domain
Development = 80% Software Engineering + 20% Platform/Framework

Starting out with UI…

When you are starting out, it is natural to pick a platform to learn. The Web Platform is a great fit for most of us. It’s easier to approach, there are literally millions of us doing it, plethora of knowledge all over the internet, tooling is fairly easy and most importantly we all have it already installed: Yes, the Browser! It’s a perfect choice and the barrier to entry is really low!

So can I say UI Development is all about HTML, CSS and JavaScript, the fundamental technologies for doing development on the Web Platform? Yes, it’s good start and you can hold on to that definition for sometime.

Until, you gain more experience.

Your experience will sculpt this definition as you get exposed to more things that you have to do as a UI Developer.

HTML, CSS and JS are the tools to translate your ideas or the ideas of your team / company / business into a tangible, working solution that you can see on the Browser (or other target platforms). The translation part can be tricky as you really have to understand the domain with which you are dealing. By domain, I mean the problem that you trying to solve and all of its trappings:

• The context within which a problem lives (Entities, Values, Relationships)
• Constraints and rules that set the boundaries for operating on the problem
• Workflows that involve a step-by-step approach to completing tasks in the problem
• The actual operations that can be performed, also called actions

As you start understanding the problem even more, you realize that implementing the idea actually involves modeling the domain.

Domain Modeling?

Yes, the act of representing the real-world concepts in software, so we can (ultimately) provide a tangible User Interface (UI). Domain modeling gets us into the realm of Domain-Driven-Design. Yes, its the blue book by Eric Evans that looks like an intimidating tome to read but has all the gems of Domain Modeling 🤓.

You owe it to yourself to read it. Not once, but many times over before it fully sinks in.

It is the domain that contains the data, operations, workflows that eventually will be surfaced on the UI. The first step is to extract these concepts, vocabulary (aka Ubiquitous Language) from the domain and then give a visual face to it.

Usually the visual representations are created by the UX team that does all the User Research (talking to Domain experts), Persona Modeling, Task flows, Wireframing, and the Visual Design.

The Visual Design is the final distillation of all these activities that results in a set of Screens (Pages) to develop.

— Note: with Visual Design, I am being inclusive of sound and motion design (animation) as well. —

And this is where you come in as a UI Developer.

Development

The working set of Screens (UI) is what you have to create as the Frontend Developer, using a static or an interactive mockup and build a working version that can be delivered to the end User. This is the UI that allows the user to manipulate things on the screen, ultimately affecting the real-world.

Here is where you use all the power of HTML, CSS and JavaScript to deliver a Browser-based UI. Using raw HTML, CSS, JS could be too low-level, which is why most UI (Web) Developers prefer a framework like React, Angular, Vue, Ember, Elm, Reason, etc. This simplifies the “development” process considerably.

If we choose to use a framework like React (could be others too), we still have the job of translating the Design documents (Sketch, Invision, Axure, etc.) into a working UI. Doing this translation requires a deeper look at Separation of Concerns: ensuring your React Components are not doing more than one thing. In other words, a Component should not take on more than one Responsibility.

We have barely scratched the surface of what is more commonly known as Component Oriented Development. A set of ideas that allows us to create single-purpose, isolated, reusable Components that help us build the runtime tree of Components: UI.

Whenever in doubt use the Unix Philosophy: Do only one thing and do it well.

Going deeper

Separation of Concerns, or stated differently the “Single Responsibility Principle (SRP)” is worth sticking to. Violating it will only lead to misery later down the road, when you want to reuse Components or add more features to your UI.

SRP is just one of the many principles of SOLID, borrowed from Object-Oriented Programming that help in managing the responsibilities in your UI.

Moving along, as you try to implement more complex features of your UI, you will also encounter Functional Programming (FP). FP allows us to model behaviors in the UI and makes it easier to manipulate data with data-transformation functions. Since we are going to deal with JavaScript, which is already a functional language, it is worth knowing the basics of Functional Programming.

As you can probably see, we are unraveling more layers of the “Development” side of UI:

• Domain Driven Design
• Component Oriented Development
• SOLID principles
• Object Oriented Programming
• Functional Programming

80–20 Split for learning UI Development

The above set of concepts are not really Framework or Platform specific. They are the core tenets of good Software Engineering. In fact, during the lifetime of a UI project, you will probably be spending 80% of your time in applying the above tenets. The rest 20% is where you are using the APIs of a Framework or Platform to create the UI.

The good thing is that learning the 20% is much easier than the 80% part. Moreover, you don’t really have to know everything about the 20% part. You can learn it incrementally and supplement with more as needed. Once you get comfortable with the 20% (the Framework or Platform), you should focus more on the 80%.

In fact, your learning should be a combination of the 80% + 20%. Every time you get comfortable with the 20% part, learn some of the 80% part. Doing this 80–20 split over a span of few months, you will bolster your knowledge with strong foundations: Software Engineering + Platform.

At that point, you are certainly going to be a formidable force in UI Development. And the world needs more like you. Go build that UI muscle.

Tying it together

So what is UI Development?

It’s the process of giving a Visual, Interactive representation to your Domain and developing a working version with the power of Software Engineering and the Platform.

Do you agree? Am I missing something? Some detail that is not already absorbed in the definition above? Perhaps, a perspective that is equally important. Let’s get the conversation going with comments!

Personal Opinion: UI Development is not being taught the way it is meant to be learnt. 80% Software Engineering + 20% Platform. I am taking a different approach with theuidev.com, an online school to teach you UI Development from the ground up. Our first course is almost ready! Take a look.

What exactly is UI Development? was originally published in The UI Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.