*By "we're," I mean front-end developers.

This is a written version of a 2019 Jamstack Conf London presentation, created after an unfortunate mountain biking accident prevented my attendance. I'm republishing it here for archival purposes and to showcase WordPress Gutenberg's capabilities.

? Hello! My career has been dedicated to front-end development and helping others excel in this field.

And boy, are my arms tired.

I manage CSS-Tricks (recently celebrating its 12th anniversary), a website dedicated to web development resources.

I also co-founded CodePen, a social coding platform for front-end technologies.

Additionally, I co-host the ShopTalk Show podcast, nearing its 400th episode.

Through these experiences, I've interacted with countless developers, gaining valuable insights into the industry and the multifaceted nature of website creation.

Defining the Front-End Developer Role

✅ It's a job title and a recognized profession.

This isn't just semantics; it's a real job with associated employment and titles. Financial compensation underscores its importance.

However, how we define this role and its expectations is subjective.

Browse any tech job board, and you'll find numerous postings for front-end developers.

Defining the Front-End Developer Role (continued)

✅ Direct interaction with browsers, devices, and users.

While many web professionals use browsers daily, front-end developers live within them, utilizing DevTools and testing across various browsers, versions, and platforms.

Crucially, they prioritize the user experience, including accessibility considerations.

Mina Markham provides a high-level explanation of the front-end developer role: [Insert Markham's quote here if available].

A distinction exists from back-end developers; it's not that back-end developers disregard users, but rather that responsibilities are distributed.

Monica Dinculescu aptly states: [Insert Dinculescu's quote here if available].

The browser is central to front-end development. If your focus is on how things appear and function in a browser, that's front-end development. It's more challenging than often acknowledged.

Defining the Front-End Developer Role (continued)

✅ Reliance on HTML, CSS, and JavaScript, despite a wide array of tools.

These are the fundamental languages browsers understand. While other technologies are involved, the core deliverable resides in these languages, and front-end developers are accountable for this.

Proficiency levels vary; some developers may write minimal JavaScript, while others focus heavily on it. This leads to a fascinating divide.

My article, "The Great Divide," explores this dichotomy: [Insert link to article if available].

This isn't a singular viewpoint; numerous developers acknowledge this split.

Brad Frost introduces "Front of the Front" and "Back of the Front" to categorize this division. He highlights that this diversity is a strength.

At Google, this distinction is recognized and reflected in job titles, with equal compensation for both career paths.

JavaScript's prominence since 2015 is undeniable.

(For larger views, use DevTools. You're front-end developers, right?)

Our roles are inherently fascinating! We all interact with browsers, users, and devices. However, our expertise and contributions differ significantly.

Some specialize in design, photography, legal aspects, performance optimization, accessibility, or social media.

Metaphorically, we can visualize this as a branching tree. [Insert tree diagram here if available].

This metaphor may not be perfect, but it illustrates the division. We share fundamental skills but branch out into diverse areas of expertise. One branch focuses heavily on JavaScript and "Back of the Front" tasks, while the other doesn't.

Since this discussion centers on the expanding role of front-end developers into full-stack work, let's focus on those with stronger JavaScript skills.

The Shifting Landscape of Web Development

Back-End Tasks Shifting to JavaScript

Many tasks previously considered back-end responsibilities are now handled within the JavaScript realm.

Component-Driven Design and Development

Thanks, JavaScript!

Non-JavaScript server-side rendered projects rarely embraced components (exceptions exist, but consider the vast PHP CMS and Ruby on Rails landscapes). While templates and includes existed, they pale in comparison to true component-driven development.

Interestingly, despite disagreements among JavaScript frameworks, the concept of components is universally accepted. Even native web components reflect this.

Let's examine CodePen (primarily React-powered). Even a small SVG icon is a component. We call it an component because it abstracts away useful aspects.

Pairing an icon with a number is another component due to its repeated pattern and potential interactive functionality.

A row of MetaItem components might become a component, along with other display aspects of an item.

Consequently, the entire item becomes a component.

These are visual and functional abstractions for UI construction. Semantic HTML underpins them, but these abstractions are custom building blocks.

Larger sections become components. A grid of items becomes a component to manage layout and pagination.

Designers often work this way in tools like Figma, Sketch, and Adobe XD using "symbols," conceptually similar to components.

Many developers understand components readily.

Site-Level Architecture/Routing

Back-End Tasks Shifting to JavaScript (continued)

URL handling and site structure were traditionally back-end concerns. Now, "routing" is increasingly a front-end responsibility.

[Insert code snippet here]

In CodePen's UI, componentization extends beyond the grid; everything becomes a component: tabs, titles, buttons, forms, menus, and the sidebar.

Ultimately, the entire page becomes a component, effectively transforming the URL into a component.

All URLs become components, granting control over the entire site.

This architectural responsibility is substantial. Consider the existing front-end workload; it doesn't disappear; it expands. This explains the increasing prevalence of full-stack-like roles for front-end developers.

State Management, Data Acquisition, and Manipulation

Back-End Tasks Shifting to JavaScript (continued)

State management, central to most JavaScript frameworks, resolves many past front-end spaghetti problems.

However, state often relies on data acquisition, now frequently a front-end responsibility. Updating and sending data back to servers adds further complexity.

GraphQL offers a powerful solution. Its value varies, but for me, it's about empowerment.

With a robust GraphQL endpoint and tools like Apollo, front-end developers can access any data needed for UI construction.

[Insert GraphQL query code snippet here]

Note that data fetching and asynchronous handling are managed within the component. Should a skeleton, spinner, or delayed rendering be used? How are errors and timeouts handled?

Data manipulation and sending updates back through GraphQL mutations are also handled.

[Insert GraphQL mutation code snippet here]

Mutations are not significantly more complex than queries, but this adds to the front-end developer's workload – tasks previously handled on the back end.

These examples illustrate GraphQL via Apollo Client in React.

Regarding components, queries, mutations, and styling, let's consider co-locating styling information.

Front-end developers always managed styling, but within self-contained components, co-locating styling makes sense.

Here, CSS modules scope styles to specific components. Global styles and Sass for abstractions are still used.

[Insert CSS module code snippet here]

[Insert code snippet showing import of styles]

Componentization and co-location result in folders containing logic, view templates, queries, mutations, and styling.

This is convenient and has positive side effects. JavaScript bundles contain only what's needed (code splitting). Styling doesn't bloat; when components are unused, their styles are removed. Naming is simplified due to file-scoped naming.

The GraphQL documentary is insightful. Kyle Mathews (around 20:24) discusses React's impact on front-end problems and GraphQL's similar effect.

While not suitable for all projects, this approach is beneficial for large, complex applications.

Existing Front-End Responsibilities:

• Design implementation
• System integration of design
• Accessibility considerations
• Performance optimization
• Cross-browser testing
• Cross-device testing
• UX considerations

New Responsibilities:

• Component-driven design
• Site-level architecture
• Routing
• Data fetching
• API interaction
• Data mutation
• State management

The workload significantly expands. This doesn't mean everyone must master every aspect, but these tasks fall within the front-end domain.

Peggy Rayzis discusses the broadened scope of front-end development and the increasing specialization: [Insert Rayzis quote here if available].

Many tasks have shifted from back-end to JavaScript.

The Evolving Technology Spectrum

Let's examine the technology spectrum's evolution.

LAMP (Linux, Apache, MySQL, PHP) is a significant, albeit older, stack powering many CMSs. Front-end developers in this stack are on the far end of the spectrum, minimally interacting with the stack's core technologies.

MEAN (MongoDB, Express, Angular, Node) includes Angular, a front-end framework. Front-end developers' work overlaps more with this stack.

Serverless shifts the stack further to the right. Server identity becomes less relevant; the focus is on server-side code and APIs. Front-end developers might even write serverless functions and manage APIs.

Shawn Wang termed Design Systems, TypeScript, Apollo GraphQL, and React a "STAR" app – all front-end technologies.

The technology discussion increasingly centers on the front-end developer spectrum.

Serverless Expansion of Front-End Capabilities

I created a website about serverless technologies: [Insert link to website if available].

I consider JAMstack (JavaScript, APIs, Markup) part of the serverless movement. (SHAMstack might be more accurate, tongue-in-cheek).

Here's a JAMstack site leveraging serverless technology: a site listing upcoming front-end development conferences: [Insert link to site if available].

[Insert Markdown file code snippet here]

Each conference is a Markdown file with front matter for metadata. A static site generator and flat Markdown files are a natural fit.

The site is a public GitHub repository. This is significant:

1. The entire site is in the repo; deployment involves cloning and a single command.
2. No logins, permissions, or credentials are needed.
3. Content, design, and functionality are open for public contributions.

GitHub Pages could host the site, but Netlify offers significant advantages:

• Deploy previews
• Analytics integration
• Programmatic image manipulation

Netlify CMS provides a UI for on-site content editing, eliminating code editing or Git. Netlify Identity simplifies authentication.

Consider a feature: a button reveals an email input form. Submitting an email triggers an email with conference details.

This requires back-end functionality. Client-side technology alone cannot send emails. APIs are used, but API keys require back-end code for secure management.

[Insert SparkPost code snippet here]

SparkPost handles email sending. Its Node.js library simplifies the process. The code is JavaScript.

How is this run? Cloud functions (AWS Lambda, Azure Functions, Google Cloud Functions) are key to serverless. Netlify uses Netlify Functions (AWS Lambda under the hood). Functions are placed in a /functions/ folder and accessed via relative URLs.

Building an entire site from front to back feels powerful.

Revisited Technology Spectrum

Operating systems and servers become less relevant. Entire products can be built without focusing on these.

Databases are less critical; data interaction often occurs through APIs (Headless CMSs like Contentful, API-focused tools like FaunaDB, or on-page libraries like Firestore).

The technology spectrum allows interaction with all parts.

Full-Stack Capabilities

Adding:

• Git proficiency
• Testing skills
• Design capabilities
• Build process knowledge
• Performance awareness
• Accessibility expertise
• Deployment pipeline setup

?
You're Gosh
Danged Right
A Full-Stack
Developer!

However,

The skillset is vast.

Specialization is possible and likely.

"Actual" unicorns (those proficient in all aspects of website building) are rare.

Back-end developers remain crucial; website complexity necessitates their expertise.

CodePen's issue tracker reveals tasks I can't handle alone; back-end support is essential. I can consider myself full-stack, but back-end skills are my weak points.

The reality often resembles this: [Insert diagram showing partial overlap of front-end and back-end skills here].

Or, in my case: [Insert diagram showing even less overlap, highlighting areas of weakness].

This isn't meant to be derogatory; it's a metaphor. We are the whole horse or dragon, but with rough edges.

It's exciting that technology allows us to encompass the entire process. Concerns arise when complexity raises the barrier to entry. However, it's also encouraging when technology simplifies the process, enabling individuals to build things independently.

Remember that quality is everyone's responsibility.

• Good UX
• Good performance
• Good security
• Good accessibility
• Ethical treatment of users

Even if not directly involved in code affecting these aspects, advocate for their proper handling.

CodePen PRO (support your local artisanal craft software products)