- This course is not going to make you FE devs
- Why I decided to start this course
- Bridge the gap
- Stop answering the same questions
- Minimize risks
- More info for the interested
- Why FE is a "first-class citizen"
- Rapid application development redefined by the Web
- Rapid means fast to develop and fast to update
- Frontend technologies deliver both
In the modern IT infrastructure, frontend technologies do not play the utility role anymore. Rich interfaces implemented with advanced capabilities of modern browsers play critical role in product success. These have to be backed-up by strict architectural approaches and cutting-edge tools.
Web and frontend technologies redefined the subject of RAD (Rapid Application Development). "Rapid to develop" does not mean "rapid to update" or "rapid to scale". Where traditional desktop-based tools failed a lot, the Web delivers.
- An overview of what a FE dev does
- A dedicated technology for everything
- Which tech serves which purpose?
A frontend developer is basically responsible for everything that you interact with in a browser window. That means page markup, styles and presentation, interaction and app flow, and communication with the server. Sometimes, frontend developers help prepare data from backend sources (e.g. accessing databases or third-party APIs), but in the end the results are sent to a client's browser.
Frontend devs deal with many technologies, of which HTML, CSS and JavaScript are the most important. Although most people know "in principle" what those technologies are about, their true meaning in the development process is often misunderstood.
- What is important in HTML?
- Markup
- Plaintext format vs. binary format
- Semantic vs. visual
- Extensible vs. limited
HyperText Markup Language is a way one specifies static content for web pages. HTML is not a programming language as it's not designed to process data but to represent data, mostly text.
HTML is a markup language. Unlike many data formats that store data in a binary form not easily readable or editable by humans, HTML offers special tags that structure the document. Tags are also text with some formatting rules. Tag may have attributes for extra netadata, its meaning depending on tag type and/or context. A program which parses (reads) hypertext and turns it into a document is a browser.
The revolution behind HTML is that it offered an easy way to define document semantics rather that presentation. On different devices, a document can be presented in different ways, while author mostly defines structure and meaning, not colors, indentations or sizes.
This was not clearly seen as the key advantage during early years of HTML, and it's creators mixed structural and semantic markup tags with purely visual ones, as businesses called for more control over how documents on the Web look like. This has been addressed in later HTML specs.
The way HTML markup is easily extensible as all tags are formed with the same simple principles. What makes it unique is not the way each tag is supposed to behave but the simplicity and extensibility of the hypertext format per se.
- DOM and the container idea
- DOM is a tree
- Incapsulation in its most direct sense
- Difficulties integrating with other schemes
- HTML: made for static text
- Typical document structure
HTML defines a document. The way a document is represented in a browser memory is called "DOM*, a Document Object Model. This term is not HTML-specific and used in regards with many FE technologies.
HTML tags define a set of nested blocks or containers, starting from the "root" tag (which is usually the HTML tag itself). You maybe know that some tags are not "closed" and seemingly do not form a container; in fact, it's not true as "non-closing" tags are simply shortcut syntax for empty containers.
This container structure is easily represented with a tree, thus "document tree" or "DOM tree" are commonly used terms.
The concept of nested structured blocks proved to be very flexible, but it does not "map" onto certain abstractions. "Floating" elements not attached to anything, visually aligning stuff that sits inside different containers, working with items that consist of several integral but freely distributed parts — all these are tricky tasks for HTML itself and require other frontend technologies.
HTML was designed for static structured text not very sensitive to styling. Recent developments in HTML put it closer to fulfilling a new task: providing a markup base for interactive interfaces. Despite HTML5, this transition is not yet complete.
Typical document structure includes "document head" (the invisible part where many document properties are defined) and "document body" where the actual content resides. Multi-document aggregations are only possible with "frames" but this technology is almost not used anymore.
- The purpose of CSS
- Not a programming language
- Visual or semantic?
- How CSS is applied?
- Two levels of CSS: properties and selectors
- properties are simple
- selectors are [too] flexible
- thus CSS is simple but CSS architecture is difficult
CSS (Cascading Style Sheets) was created to address the increasing need of precise visual control over web documents. HTML didn't succeed in addressing the same problem, so it evolved further as a semantic tool while CSS is supposed to control the presentation. As HTML itself, CSS lacks capabilities of a programming language (i.e. doesn't allow for data processing). As standards evolve, CSS gets some rudimentary support for data manipulation.
CSS can be applied directly onto HTML tags by using a reserved attribute on tags, but nowadays CSS is mostly put into separate files that are referenced from HTML, loaded by the browser, and applied to existing HTML document.
CSS code consists of rules and selectors. Rules specify visual properties (fonts, colors, decorations, dimensions, positioning) while selectors specify how a rule set is applied to tags, tag groups or document areas. The number of CSS rules is limited by what a browser supports and developers can't create their own ones. The syntax is relatively simple.
Selectors use complicated syntax to specify which tags are affected. The difficult part is an architectural approach behind large CSS code bases and complicated rules of inheritance as many rules are overridden or extended by other ones (more on this later).
- What CSS can do?
- a set of common assumptions
- on the edge of a programming language
- the story of rounded corners
CSS isn't all-powerful. Its styling capabilities have been strongly affected by market needs and technology limitations. Initially, CSS had to "catch up" with what HTML already did, so the first versions of CSS standard were largely affected by "porting" visual capabilities of HTML.
Even later, CSS development has been driven by common assumptions on which presentation features web developers need. Market needs were prioritizing some features over the others. There is no "one universal way" of controlling all visual aspects; instead, more control capabilities are added with new standard revisions, with browsers sometimes driving the innovation or completely ignoring whole sections of standard.
The story of rounded corners is especially fabulous. Initially, rounded corners were not supported in neither CSS nor HTML, but a trend in web design demanded them everywhere. Unfortunately, they could only be implemented with inferior and hacky techniques with a lot of extra overhead. Frontend devs hated rounded corners, so they suggested a syntax to implement these in CSS and modern browsers followed the suite; Internet Explorer, however, didn't do that until version 9. This became a classical example of old browsers withholding web progress.
- Know what's easy and what's hard
- False expectation of equally powered APIs
- 3D rotating cube vs. a fully-styled SELECT
Product managers and designers need to know which capabilities are provided by CSS "out of the box" and which have to be implemented with other technologies (sometimes taking a lot of resources and time). This helps with planning.
The above-mentioned rounded corner example could help frontend developers significantly reduce the amount of time spent on layout if designers were okay with dropping all round corners on IE. Nowadays we have more advanced cases but the idea is the same: whenever a visual feature is not implemented directly in CSS, or support is buggy/inconsistent, consider finding another visual solution.
Another false expectation is that the power of CSS is "equally distributed": tasks that seem "similar" to a manager do not necessarily have similar degree of complexity, for example:
- Most form controls can be easily restyled. However, fully styling a native <SELECT> dropdown has been a topic for many advanced articles and hacks that took weeks to be tested across all browser versions. A 100% cross-browser solution doesn't exist up to this very moment.
- It's relatively easy to change element dimensions based on browser window size change. However, it's very difficult to achieve the same based on a size of a parent container, with CSS being helpless in this case and JavaScript solutions being either quirky or very resource intensive.
- Centering items in CSS horizontally is a breeze, while vertical centering is not even directly supported (although many hacky solutions do exist, each has its limitations and shortcomings).
- At the same time, most modern browsers can render a 3D rotating multicolored cube with CSS only.
- The language created in 10 days
- Language vs. API
- JS as a language (mostly easy)
- In-browser APIs powered by JS (hardcore)
- Development patterns (constantly evolve)
JavaScript was created in a rush by a Netscape engineer Brendan Eich to fit the tight release schedule for the Netscape Navigator 2.0 browser. Despite a lot of critics received later for its design and architecture, JavaScript is now one of the most used programming languages in the world and fully powers the whole modern Web plus a good deal of server-based architecture solutions.
Although its name suggests some resemblance to Java, this part was pure marketing by Netscape. In fact, JavaScript does share a good deal of syntax with Java — not because it's a Java dialect or a subset, but because they both belong to a densely populated group of C-like languages.
It's important to understand that the true power of JavaScript on the Web lies multiple APIs which different browsers expose and which are accessible with JavaScript. JavaScript itself has no specific properties that make it a "web language". Microsoft supported Visual Basic Script for many years as an alternative scripting language for web pages.
Because browser APIs are evolving, and different browsers have different capabilities (and different bugs!), mastering JavaScript is mostly about mastering those APIs. However, because JS as a language is minimalistic, it's crucial that developers understand all of its capabilities.
For some years, JS has been actively evolving as a server-side language, too.
Development patterns in JS somehow compensate for the language being simplistic and not opinionated in regards to the code architecture. The patterns are expressed in both "community knowledge" and in JS libraries and frameworks.
- Libraries: API glue + syntax sugar
- Frameworks dictate high-level architectures
A JS library is a set of helper functions or methods to make development simpler. They either wrap around existing APIs to protect developers from common incompatibilities, or introduce new tools or abstractions for things not so easily doable on a "low level".
A framework is usually a library (one or more) plus a set of approaches and architecture patterns for building products (applications or services or similar things).
- Client-server communication in a nutshell
- Loading resources
- Rendering and running code
- Modifying the page
- AJAX or Ajax?
- The name is wrong!
- JavaScript is still synchronous
- Most Ajax apps don't use XML
- HTTP applied to a different granularity level
- Web Sockets
- HTTP extensions
- Hacky techniques like long polling, Comet
- Text and encoding
- Images
- GIF
- JPEG
- PNG
- WebP and friends
- SVG
- Plugins, media and HTML5
- More than one can imagine
- Major ones:
- Trident
- Gecko
- WebKit/Blink
- Presto
- Innovation is driven by browsers, not the other way around
- Examples of Netscape, IE6, Chrome
- Technologies are emerging all the time
- 30% standartized, 40% a draft, 30% competitive advantage
- Backward compatibility is the obstacle
- No browsers but live customers
- Techniques for backward compatibility exist...
- ...but grow exponentially expensive with more browsers to support
- Cross-browser techniques are themselves patterns
- Web is always multibrowser because of upgrades
- No patterns == no long-term protection
- 10%-15% fluctuations of a customer base?
- "Hotfixes" are not hotfixes
- A major browser release may bring down your business
- Box model
- Play with properties
- Play with selectors
- What can be styled
- Typical problems
- Box model
- Vertical centering
- Native controls styling
- Floats
- zIndex
- What CSS should and should not do
- MVC
- BEM