DEV Community: Grant Watson

Earned Complexity: A Disciplined, Evidence-Based Framework

Grant Watson — Mon, 19 Jan 2026 01:10:28 +0000

Abstract

Modern software engineering organizations increasingly struggle not because of insufficient technical skill or innovation, but due to a systemic over-accumulation of complexity that is introduced faster than it can be justified, understood, governed, or operated. This phenomenon—often mislabeled as technical ambition, future-proofing, or scalability planning—has been repeatedly identified as a root cause of degraded system reliability, declining delivery velocity, organizational burnout, and unsustainable maintenance cost.

This paper formalizes Earned Complexity, an evidence-based decision framework designed explicitly for software teams to determine when architectural or systemic complexity is warranted and how such complexity must be constrained, monitored, and revisited over time. The framework synthesizes principles from well-established engineering literature, including Choose Boring Technology, You Are Not Google, and the maxim Code Is Read More Than It Is Written, alongside operational insights from reliability engineering, systems thinking, and organizational psychology.

By reframing complexity as a scarce resource that must be earned and continuously paid for, this work proposes a practical, repeatable discipline that aligns technical decision-making with long-term organizational performance. The intended outcome is not minimalism for its own sake, but sustained peak execution through disciplined restraint.

1. Introduction: Why Complexity Requires Study

Software systems do not fail randomly. They fail predictably, following well-understood patterns associated with unmanaged complexity: cascading failures, brittle abstractions, opaque behavior, and disproportionate operational overhead. Despite decades of industry experience, many teams continue to repeat the same mistakes, introducing advanced architectures prematurely and assuming that sophistication is synonymous with professionalism.

The study of complexity in software engineering is not new. Brooks’ No Silver Bullet established early that essential complexity cannot be eliminated, only managed ¹. However, modern development practices—cloud infrastructure, distributed systems, and rapidly evolving frameworks—have dramatically lowered the activation energy required to introduce complexity, while simultaneously increasing the cost of operating it.

This asymmetry has created an environment in which teams can add complexity far more easily than they can remove it.

The motivation for this study is therefore pragmatic: how can software teams systematically distinguish between necessary complexity and optional complexity, and how can they govern the latter to prevent long-term harm?

2. Intellectual Origins of Earned Complexity

2.1 Choose Boring Technology

Dan McKinley’s essay Choose Boring Technology articulates a central insight: most business problems do not require novel solutions, and novelty disproportionately increases risk relative to its benefit. McKinley argues that mature organizations succeed not by adopting cutting-edge tools, but by selecting technologies that are well-understood, widely supported, and operationally predictable.

“If the problem you are solving is not unique, your solution should probably not be either.”

— McKinley, Choose Boring Technology

https://mcfunley.com/choose-boring-technology

This work establishes the foundational idea that engineering maturity manifests as restraint, not maximal sophistication.

2.2 You Are Not Google

The essay commonly referred to as You Are Not Google (popularized through multiple iterations and talks) critiques the widespread tendency for organizations to emulate the architectures of hyperscale technology companies without possessing the corresponding scale, staffing, or operational maturity.

The key contribution of this perspective is the concept of scale proportionality: architectural decisions must be justified by actual constraints, not aspirational ones.

“Premature scaling is just another form of premature optimization.”

https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb

This work directly informs the Evidence Gate in the Earned Complexity framework.

2.3 Code Is Read More Than It Is Written

The assertion that code is read more than it is written reframes software as a long-lived communicative artifact rather than a short-lived construction task. While often attributed informally, this principle is supported by empirical research showing that maintenance accounts for the majority of software lifecycle cost ².

Readable, predictable code reduces onboarding time, error rates, and recovery time during incidents. Conversely, clever or opaque implementations amplify cognitive load and slow organizational response.

This principle informs the framework’s emphasis on cognitive cost as a first-class consideration.

3. Complexity as an Organizational Liability

Complexity introduces costs that are frequently underestimated or ignored during design discussions. These costs fall into four primary categories:

Cognitive Load – The mental effort required to understand, modify, and debug a system.
Operational Load – The ongoing effort required to deploy, monitor, and recover the system.
Failure Surface Area – The number of distinct ways a system can fail, including partial or silent failures.
Dependency Risk – The fragility introduced by external libraries, platforms, vendors, or coordination mechanisms.

Importantly, these costs compound over time. Each additional layer of abstraction increases the difficulty of future changes, often non-linearly.

Research in systems engineering consistently demonstrates that increased system complexity correlates with decreased reliability unless mitigated by proportional investment in controls and expertise ³.

4. The Law of Earned Complexity

Complexity must be earned by measurable pain, and paid for with controls.

This law formalizes two necessary conditions:

Justification Condition: A demonstrable, current problem exists that cannot be addressed through simpler means.
Governance Condition: The organization is willing and able to fund the mechanisms required to safely operate the added complexity.

If either condition is unmet, complexity should not be introduced.

5. The Earned Complexity Framework

5.1 Gate 0: Problem Definition

Teams must articulate proposed complexity in a single sentence:

“We propose adding X to address Y, measured by Z, with rollback R.”

This constraint enforces clarity and prevents ambiguity-driven scope creep.

5.2 Gate 1: Evidence of Pain

Acceptable evidence includes:

Recurrent production incidents
SLO or error-budget violations
Quantified performance ceilings
Measured delivery bottlenecks
Documented compliance requirements

Speculative future needs are explicitly excluded.

5.3 Gate 2: Alternatives Analysis

Teams must demonstrate that:

Procedural remedies were attempted
Localized technical optimizations were evaluated
Architectural escalation is unavoidable

This step enforces graduated response.

5.4 Gate 3: Cost Modeling

Each proposal is scored across four dimensions (0–5):

Cognitive Load
Operational Load
Failure Modes
Dependency Risk

Total Cost Score: 0–20

5.5 Gate 4: Benefit Modeling

Benefits are similarly scored:

Reliability Improvement
Performance or Cost Efficiency
Delivery Velocity
Security or Compliance Risk Reduction

Total Benefit Score: 0–20

5.6 Gate 5: Controls Requirement

Complexity must ship with:

Observability (metrics, logs, traces)
Alerting aligned to user impact
Rollback and kill-switch mechanisms
Named ownership and runbooks
Failure-mode testing
A stated complexity budget

6. Decision Rule

Complexity may be approved only if:

Evidence and Alternatives gates pass, and
Benefit − Cost ≥ +4, or
Compliance mandates the change and controls are funded

Otherwise, the proposal is rejected or deferred.

7. Practical Team Applications

7.1 Architecture Reviews

Replace subjective debates with structured scoring and evidence review.

7.2 Code Reviews

Use the framework to challenge unnecessary abstractions early.

7.3 Incident Retrospectives

Tie complexity reduction directly to incident prevention.

7.4 Engineering Governance

Adopt Earned Complexity as a formal policy or ADR requirement.

8. Case Study: Microservices Adoption

A mid-sized team experiencing deployment conflicts considered migrating to microservices.

Evidence: No scaling constraints, no incident correlation
Alternatives: Modular monolith not attempted
Cost: High operational and cognitive load
Decision: Rejected

Outcome: Delivery velocity improved after refactoring boundaries without architectural escalation.

9. Sustaining Peak Performance

Peak engineering performance is not achieved through maximal output or technical bravado. It emerges from predictable systems, calm operations, and disciplined decision-making.

Earned Complexity provides teams with a repeatable mechanism to protect these outcomes.

10. Conclusion

Complexity is neither inherently good nor bad. It is expensive. Like any scarce organizational resource, it must be justified, governed, and revisited.

By adopting Earned Complexity as a formal discipline, software teams can align technical ambition with operational reality—achieving sustainable excellence without unnecessary risk.

References

https://ieeexplore.ieee.org/document/1663532

Brooks, F. P. (1987). No Silver Bullet—Essence and Accidents of Software Engineering. IEEE Computer. ↩
Lehman, M. M. (1980). Programs, Life Cycles, and Laws of Software Evolution. Proceedings of the IEEE. ↩
Perrow, C. (1984). Normal Accidents: Living with High-Risk Technologies. Basic Books. ↩

12 Powerful React Libraries Every Developer Should Master in 2025

Grant Watson — Mon, 21 Jul 2025 16:52:21 +0000

12 Powerful React Libraries Every Developer Should Master in 2025

React continues to lead the frontend world in 2025, but with its simplicity comes the challenge of choosing the right tools. Whether you're a solo developer or working on a team, these 12 libraries will help you work faster, write better code, and build more dynamic web apps.

1. React Router

What it does: Declarative routing for single-page React apps.

React Router is still the industry standard for managing routes in React. It supports nested layouts, lazy loading, and dynamic route parameters.

👉 Documentation

2. Zustand

What it does: Minimal state management using hooks.

Zustand is gaining popularity for being tiny, fast, and avoiding boilerplate. It works great for global state in small-to-medium apps.

👉 Documentation

3. React Hook Form

What it does: Performant, hook-based form management.

React Hook Form simplifies validation and reduces re-renders in complex forms. It’s a must-have for building accessible, fast forms.

👉 Documentation

4. TanStack Query (React Query)

What it does: Fetch, cache, and sync server state.

React Query (now TanStack Query) helps you manage API requests with automatic caching, background updates, and retry logic.

👉 Documentation

5. Framer Motion

What it does: Declarative animations for React.

Framer Motion is a high-performance library for creating animations, gestures, and transitions without writing CSS keyframes.

👉 Documentation

6. React Helmet

What it does: Control your document’s <head>.

React Helmet lets you dynamically set meta tags, page titles, and social tags—essential for SEO in single-page apps.

👉 Documentation

7. React Markdown

What it does: Render Markdown content as React components.

Perfect for blogs, docs, or CMS-driven sites where content is stored in Markdown. It supports plugins like remark-gfm.

👉 Documentation

8. React Testing Library

What it does: Tests components like a user would interact with them.

It encourages good testing practices by focusing on user behavior, not implementation details.

👉 Documentation

9. Recharts

What it does: Charting with React components.

If you need bar, line, or pie charts quickly without dealing with D3 directly, Recharts is clean and customizable.

👉 Documentation

10. Formik

What it does: Form state management with validation support.

Formik provides a structured way to handle form inputs, validation, and submission logic—often used with Yup.

👉 Documentation

11. React Icons

What it does: Use icon packs (FontAwesome, Material, etc.) as components.

React Icons makes it easy to import and style only the icons you need. Works great with Tailwind and other styling libraries.

👉 Documentation

12. React DnD

What it does: Drag-and-drop interface with full control.

Built by the React community, this gives you precise control over draggable interfaces like Kanban boards.

👉 Documentation

💡 Final Thoughts

The React ecosystem is thriving, but that also means constant change. The libraries above are ones you can trust—actively maintained, battle-tested, and developer-friendly.

Save this post, revisit it throughout the year, and let me know which libraries you’re using in production!

📝 Originally published at grantwatson.dev/blog

Mastering Automation: 5 Real-World n8n Workflow Examples (With Step-by-Step Guides)

Grant Watson — Mon, 21 Jul 2025 16:42:09 +0000

Mastering Automation: 5 Real-World n8n Workflow Examples (With Step-by-Step Guides)

This and other articles of mine can be found here

📌 Overview

n8n is an open-source workflow automation tool that allows you to connect services (APIs, webhooks, databases, CRMs, and more) into powerful automations without writing boilerplate glue code. Whether you're a beginner or seasoned power user, this article provides 5 comprehensive, real-world workflows to launch your n8n journey or deepen your automation chops.

Each example includes:

Use case breakdown
Step-by-step setup
Real-world benefits
JSON download (optional)

🔧 Prerequisites

Before diving in:

Install n8n (self-hosted Docker or cloud-based)
Have credentials ready (e.g., Gmail, Notion, GitHub)
Know how to use the n8n Editor UI

🧠 Workflow 1: Automatic Lead Collection from Typeform to Notion CRM

💡 Use Case

You want to capture leads from a Typeform form and store them in your Notion CRM database automatically.

🧱 Tools

Trigger: Typeform Trigger
Action: Notion node (Database row creation)
Optional: Email confirmation via Gmail

🛠 Step-by-Step

Create a Typeform with fields like Name, Email, Company.
In n8n:
- Add Typeform Trigger → Select your form
- Add Notion node:
  - Choose your database
  - Map answers.fields from Typeform to Notion properties
- (Optional) Add Gmail node to email the lead a thank-you note.

✅ Real-World Impact

Eliminates manual copy-pasting.
Keeps your CRM always up-to-date.
Saves time for your sales team.

🗓 Workflow 2: Google Calendar Event → Slack Notification + Mattermost Alert

💡 Use Case

Notify your team in both Slack and Mattermost whenever a new calendar event is added.

🧱 Tools

Trigger: Google Calendar node (polling)
Actions: Slack, Mattermost

🛠 Step-by-Step

Add Google Calendar node (polling every 10 minutes)
Use Slack node:
- Format: "New Event: {{summary}} at {{start}}"
Add Mattermost node:
- Webhook URL
- Use same message template

✅ Real-World Impact

Ensures every team member is notified, no matter their preferred chat app.
Prevents missed meetings.

📝 Workflow 3: GitHub Issue → Create Jira Ticket → Email Developer

💡 Use Case

New GitHub issues automatically create Jira tasks and notify the assigned dev by email.

🧱 Tools

Trigger: GitHub (Webhook)
Actions: Jira Software, Gmail

🛠 Step-by-Step

Add GitHub Trigger → Connect webhook to repo
Use Jira node to create an issue:
- Project, Summary, Description from GitHub payload
Use Gmail node:
- Subject: New Issue Assigned: {{issue.title}}
- Body: Include GitHub and Jira links

✅ Real-World Impact

DevOps automation: from bug discovery to tracking in one sweep.
Instant communication loop.

🧾 Workflow 4: Daily Digest of New RSS Articles to Email

💡 Use Case

Receive a curated daily email of tech news articles from multiple RSS feeds.

🧱 Tools

Trigger: Schedule (Daily)
Actions: Multiple RSS Feed nodes, Merge, Gmail

🛠 Step-by-Step

Add Schedule node: daily at 8 AM
Add multiple RSS Feed Read nodes (e.g., Ars Technica, Hacker News, TechCrunch)
Merge them using Merge node (combine mode)
Use Set node to format email body with titles + links
Send email via Gmail

✅ Real-World Impact

Daily inbox summaries, no feed bloat.
Saves hours of scrolling.

🧮 Workflow 5: Auto Backup New Notion Pages to Google Drive as Markdown

💡 Use Case

When a new page is created in Notion, export and save it as a Markdown file on Google Drive.

🧱 Tools

Trigger: Notion Trigger
Actions: Notion → HTTP node (for Markdown conversion), Google Drive

🛠 Step-by-Step

Add Notion Trigger for new pages in a workspace
Retrieve content using Notion Content node
Use HTTP node to convert content to Markdown (or use JS function to clean format)
Save the .md file using Google Drive upload node

✅ Real-World Impact

Version-controlled documentation.
Local backups for regulatory or compliance reasons.

🧩 Bonus Ideas for Advanced Users

Use Case	Tools
Auto-post job listings from RSS to LinkedIn	RSS → HTTP (LinkedIn API)
Daily DB backup to S3	PostgreSQL node → AWS S3
Sync rows between Airtable & Google Sheets	Airtable → Google Sheets
ChatGPT Summarizer for new YouTube uploads	YouTube → HTTP (OpenAI) → Email
Trigger webhook from Mattermost slash command	Webhook → Custom Logic → Response

📥 Best Practices for Workflow Building

Use Namespaces – Name every node clearly (getIssueDetails, sendSlackAlert)
Group with Notes – Add descriptive notes to each logic block.
Error Handling – Use the Error Trigger to catch and report errors.
Version Control – Export workflows as JSON to Gitea or GitHub.
Security – Never expose credentials in plain text. Use secrets and environment variables.

🎓 Where to Learn More

🧠 Final Thoughts

n8n is more than just a no-code tool—it's a logic engine that empowers creators, developers, and teams to build tailored automations that match their workflows precisely. Whether you’re building a SaaS platform, syncing internal tools, or just automating your morning, these workflows give you a strong launchpad.

Save this article. Build from these. Then go create something remarkable.

Sell Yourself as a Developer: Creating a Personal Brand That Stands Out

Grant Watson — Tue, 27 May 2025 22:37:47 +0000

In a world full of portfolios, GitHub profiles, and online résumés, it’s easy to feel like one developer in a sea of sameness. But here’s the truth: if you want better opportunities, better projects, and more control over your career—you need to sell yourself. And that starts with a personal brand.

You might think “branding” is just for influencers and startups. Not true. As a developer, your brand is your reputation made visible.

Here’s how to build it, own it, and let it open doors.

⸻

🧭 Know What You Want to Be Known For

Before you can create a personal brand, you need clarity. Ask yourself:
• What kind of problems do I love solving?
• Which technologies excite me most?
• Do I want to be known for front-end creativity, backend mastery, architecture, teaching, or something else?

Your brand should be a reflection of both your skills and your passions. You can’t be the “everything” dev. Be the dev people remember for something specific.

⸻

🌐 Build a Home for Your Work

Every strong brand needs a place to live. For developers, this is your personal website or blog. It should include:
• A clean, focused portfolio with 2–4 strong projects
• A professional “About Me” section that shows personality and clarity
• Links to your GitHub, LinkedIn, Twitter, and blog

If you want bonus points? Add a blog. Write about the things you’re learning or building. Teach what you know. It reinforces your brand and builds trust.

Developers who blog consistently get noticed. Not just for what they build, but for how they think.

⸻

📣 Talk About What You Do (Even If No One’s Listening Yet)

Share progress on Twitter, LinkedIn, or dev communities. You don’t need to have a massive audience—you’re documenting your journey for future you and for the one person watching who might open a door.
• Share a cool solution to a problem you hit
• Post a demo or screenshot of a feature in progress
• Reflect on a challenge and how you overcame it

This isn’t bragging. It’s visibility.

⸻

💼 LinkedIn and GitHub: Signal vs. Noise

Too many developers ignore or underuse these platforms.

LinkedIn:
• Keep your headline crisp: “C# Backend Developer | Blazor + .NET Enthusiast” is better than “Software Engineer.”
• Fill out your “About” with what you do best and what you want next
• Share articles, comment on posts, be visible

GitHub:
• Pin 3–6 repos that best reflect your skills
• Keep READMEs sharp and clean
• Avoid noisy commit histories on weak toy projects

These platforms aren’t just your résumé—they’re your billboard.

⸻

🔍 Be Searchable, and Make It Easy to Connect

Use your full name consistently across platforms (or your brand handle). Make sure people can find you by name, GitHub handle, or blog title.

Add contact forms. Post a professional email. Link to your site in your GitHub bio. Make it easy for someone to reach out after they see your work.

⸻

💥 The X-Factor: Authenticity

The strongest brands aren’t fake. They’re focused. You don’t need to pretend to be a 10x genius or tweet in memes. You just need to show up consistently, share your work, and make your value obvious.

Let people see:
• What you care about
• What problems you solve well
• Why you’re worth working with

⸻

🚀 Final Thought

Your brand is already forming, whether you’re shaping it or not. Every project you ship, every post you write, and every way you show up online adds to that signal.

The question is—are you curating it? Or leaving it to chance?

If you want to stand out as a developer, don’t just write good code.

Sell it. Shape it. Share it.

That’s your personal brand.

One Way Binding in Blazor Components

Grant Watson — Sun, 25 Jul 2021 03:36:49 +0000

ORIGINAL POST

Blazor Components: One Way Data Binding

One of the major roles of a developer is on how they can make a static page either in a desktop, mobile or web application dynamic, or even if it needs to be. Binding data is a fundamental task in any single page applications (SPAs). At some point every application needs to either display data in form of labels, or receive data in the form of input fields and select boxes.

While most SPA frameworks have similar concepts for data binding, either one way binding or two way binding, the way they work and are implemented varies widely. In this post, we're going to have a good look at how one way and two way binding work in Blazor.

One Way Binding

One way bindings have a unidirectional flow, meaning that updates to the value only flow one way. A couple of examples of one way binding are rendering a label dynamically or dynamically outputting a CSS class name in markup.

One way bindings can be constant and not change, but often the value will have a reason to be updated. Otherwise it would probably be better to avoid using a bound value altogether and just type the value out directly.

In Blazor, when modifying a one way binding the application is going to be responsible for making the change. This could be in response to user action or event such as a button click. The point being, that the user will never be able to modify the value directly, hence one way binding.

Now that we have a rudimentary idea of what one way binding is, let’s take a look of it in the form of code:

<h1>@Title</h1>

@code {
    private string Title { get; set; } = "Banging Title Mate!";
}

In the code above, we have a component which displays a heading. The contents of that heading, Title, is a one way bound value. In order to bind one way values we use the @ symbol followed by the property, the field or even the method we want to bind too.

<h1>@Title</h1>

<button @onclick="UpdateTitle">Click to Update Title</button>

@code {
    private string Title { get; set; } = "Hello, World!";

    private void UpdateTitle()
    {
        Title = "Greeting, Blazor Friends!";
    }
}

In the first example the value is set and never changed, in this example we've added a method which updates the value of Title when the button is clicked.

As we talked about previously, values can only be updated in one direction and here we can see that in action. When the buttons onclick event is triggered the UpdateTitle method is called and Title property is updated to the new value. Executing event handlers in Blazor triggers a re-render which updates the UI.

One Way Binding Between Components

In the previous examples, we looked at one way binding inside of a component. But what if we want one way binding across components? Using our previous example, say we wanted to display the title of a parent component in a child component, how could we achieve this? By using component parameters.

<!-- Parent Component -->

<h1>@Title</h1>

<button @onclick="UpdateTitle">Update Title</button>

<ChildComponent ParentsTitle="Title" />

@code {
    private string Title { get; set; } = "Hello, World!";

    private void UpdateTitle()
    {
        Title = "Hello, Blazor!";
    }
}

<!-- Child Component -->

<h2>Parent Title is: @ParentsTitle</h2>

@code {
    [Parameter] public string ParentsTitle { get; set; }
}

In the example, the parent component is passing its title into the child component via the child components ParentsTitle component parameter. When then components are first rendered the headings will be the following.

<!-- Parent Component -->
<h1>Hello, World!</h1>

<!-- Child Component -->
<h2>Parent Title is: Hello, World!</h2>

When the Update Title button is pressed then the output will become the following.

<!-- Parent Component -->
<h1>Hello, Blazor!</h1>

<!-- Child Component -->
<h2>Parent Title is: Hello, Blazor!</h2>

Similar to what happened with the earlier example inside a single component. The button click event calls the UpdateTitle method and the Title property is updated. Then the running of the event handler triggers a re-render of the parent component.

This also updates the Title parameter passed to the child component. Updating the component parameter triggers a re-render of the child component, updating its UI with the new title.

I cannot wait to start working on the next post for 2 way binding. If you would like to have me as your personal coach for learning how to program, feel free to email me here or email me directly at info@grantwatson.dev

Blazor Components

Grant Watson — Tue, 20 Jul 2021 21:22:47 +0000

ORIGINAL POST

Blazor Components Basics and Simple Structure:

What are Blazor components?

A Blazor component is an independent part of the Blazor Application. These entities can be as simple or as complex as the application calls for. Blazor applications are made utilizing parts that are adaptable, lightweight, and can be settled, reused, and shared between ventures. A component is the base component of the Blazor application, i.e., each page is considered as a segment in Blazor.

It utilizes the mix of Razor, HTML, and C# code as a part. For example:

@page "/counter"

<h1>Counter</h1>

<p>Current count: @currentCount</p>

<button class="btn btn-primary" onclick="@IncrementCount">Click me</button>

@functions {
    int currentCount = 0;

    void IncrementCount()
    {
        currentCount++;
    }
}

Blazor segments are executed in *.cshtml records utilizing a mix of C# and HTML markup. The UI for a segment is characterized utilizing HTML while dynamic delivering rationale like circles, conditionals, articulations are included utilizing an installed C# language structure called Razor.

In the work square, we can characterize all the properties that are utilized in see markup, and the techniques are bound with control as an occasion.

At the point when a Blazor application is assembled, the HTML markup and C# delivering rationale are changed over into a part class, and the name of the produced class coordinates the name of the record.

Component Members

Individuals from the segment class are characterized in a @functions square, and you can utilize more than one @functions obstruct in a part. In the @functions square, segment states, for example, properties and fields are determined alongside strategies for occasion taking care of or for characterizing other part rationales. Segment individuals would then be able to be utilized as a major aspect of the part's delivering rationale utilizing C# articulations that start with @.

All rendered Blazor views descend from the ComponentBase class, this includes Layouts, Pages, and also Components.

A Blazor page is essentially a component with a @page directive that specifies the URL the browser must navigate to in order for it to be rendered. In fact, if we compare the generated code for a component and a page there is very little difference. The following generated source code can be found in Counter.razor.g.cs in the folder obj\Debug\netcoreapp3.0\Razor\Pages.

namespace SomeBlazorApp.Client.Pages
{
    [Microsoft.AspNetCore.Components.LayoutAttribute(typeof(MainLayout))]
    [Microsoft.AspNetCore.Components.RouteAttribute("/counter")]
    public class Counter : Microsoft.AspNetCore.Components.ComponentBase
    {
        protected override void BuildRenderTree(Microsoft.AspNetCore.Components.RenderTree.RenderTreeBuilder builder)
        {
            // Code omitted for simplicity
        }
    private int counter = 42;
    private void IncrementCounter()
    {
        counter++;
    }
  }
}

[Microsoft.AspNetCore.Components.RouteAttribute("/counter")] identifies the URL for the page.

[Microsoft.AspNetCore.Components.LayoutAttribute(typeof(MainLayout))] identifies which layout to use.

In fact, because pages are merely components decorated with additional attributes, if you alter the Pages/Index.razor file of a default Blazor app, it is possible to embed the Counter page as a component.

@page "/"
<h1>Hello, world!</h1>
Welcome to your new app.
<Counter/>

When embedding a page within another page, Blazor treats it as a component. The LayoutAttribute on the embedded page is ignored because Blazor already has an explicit container – the parent component that contains it.

Creating Components

Depending on your hosting service, and whether you chose Blazor WebAssembly or Blazor Server, the following may be ambiguous. But let’s say for simplicity sake, your main solution has 3 projects: Client/Server/Shared.

Under the Client Project:

Make a new folder called Components. This name can be anything that you wish it to be, for it is not a special or “needed” name. Once you have create the folder, create a file within the folder and name it ComponentOne.razor and the following markup is the starting point of any new component:

//Section 1
@page "/"

//Section 2
<h1>
  Hello World!
</h1>

<p>
  Welcome to your component
</p>

//Section 3
@code {
    //empty code block
}

Let’s stop for a quick moment to discuss what each section is. If you have ever worked in ReactJS or Angular, this may look familiar to you, and feel free to go forward. If this is your first time working in a front end framework, let’s go over some basics:

Section 1:
For clarity and simplicity over the structure/architecture of a component, this is where you will post and dictate your using statements for your components. There is a _Import.razor file to where you can place your using statements, but this is beyond the scope of this article. When you need to declare another file from your solution into you component, put them at the top of your component here. This is also where you can call your Nuget packages you specifically want to use in your component.

The next area you see here is the @page “/”

Similar with routing in React, we dictate the routing of this particular component as “/”. Again, routing is outside the scope of this article, I will have another article covering this in the future.

Section 2:
This area should look “easy” to you. Especially if your component is a simple display component. This area is where you place your HTML code inside the component.

Section 3:
This area is the fun part of the component in my opinion. This is where we combine C# syntax into the component itself. May it be service calls, httpClient and JSON calls to APIs. In this code block, you as the developer can make you component perform magic here.

In the next few articles, I will go into more in the depth and breadth of components, and the following is what I am considering covering:

One Way Binding in Components
Two Way Binding in Components
Component Literals, Expressions, and Directives
Browser DOM and Component Events
Cascading Values
Code Generated HTML Attributes
Capturing Unexpected Parameters
Replacing Attributes on child components
Component Lifecycles
Multi-threaded rendering

If there is a topic that you would like for me to cover with Blazor, or any language that you would like to see, please feel free to contact me through email at info@grantwatson.dev or on Twitter @granticusdev

Programming Languages That Will Dominate

Grant Watson — Mon, 29 Mar 2021 01:31:36 +0000

Original Post

Forecasting the world’s most popular programming languages over the next few years is a difficult task. Oftentimes, bold predictions about a language’s dominance won’t pan out; then you have the languages that seem to come out of nowhere to seize a significant niche (often with a bit of a boost from a major tech company).

Every so often, though, a language’s spike in popularity makes it easier to predict its rosy future. It’s all about the long term—and you should structure your learning (and mastery) appropriately. “I’d recommend deciding what’s important and building your working culture around it rather than worrying about whether you’re missing out by not using a new language,” he adds. “If you’re an individual engineer and want to know how you can help yourself, double down on the fundamentals of how the languages you currently work in interact with the underlying operating system or runtime. A little focus on the fundamentals goes a long way here, and the fundamentals will still be the same in 2030.”

So which programming languages will continue to dominate in 2021?

Python

Artur Yolchan, Senior Software Engineer and owner of the website Coding Skills, says: “Python will probably be the most favorite programming language for developers in 2021.”

The increased use of Python in a specialized context has a lot to do with that, suggests Alex Yelenevych, CMO of CodeGym: “In the development of artificial intelligence systems, Python has proven itself. In addition, many modern and safe sites are written in Python, and it is also very often learned in schools. The language is pleasant and quite simple for beginners, so its popularity will only grow.”

It takes a lot to erode the usage of older, more generalist programming languages, even when newer languages begin to attract a lot of buzz, adds Matt Pillar, VP of Engineering at OneSignal: “Python is an old favorite, and it’s not going away anytime soon. While incumbents like Rust and TypeScript are occupying more and more mindshare, taking some attention away from Python, Python continues to be one of the most loved and most utilized programming languages. With its strong connection to data science toolkits, Python is being taught at an increasing number of programming bootcamps and is well poised to be a favorite first language for developers in the years to come.”

If you’re totally new to Python, start your learning journey by heading over to Python.org, which offers a handy beginner’s guide. Microsoft has a video series, “Python for Beginners,” with dozens of short, Python-related lessons. There’s also a variety of Python tutorials and books (some of which will cost a monthly fee) that will teach you the nuances of the programming language (and don’t forget your IDEs).

JavaScript

Michael O’Connell, Chief Analytics Officer at TIBCO Software, doesn’t think the ultra-popular JavaScript is going anywhere, especially when it comes to dominating developers’ mindshare in 2021:

The maturation of JavaScript as a design and development environment has been phenomenal and will accelerate in 2021. Whether you are working on the front-end with JavaScript, apps and frameworks with React, Angular and vue.js, desktop apps with Electron.js, or backend with Node.js, JavaScript is the ticket! You can even develop machine learning with Tensorflow.js.

I see the worlds of self-service BI and visual analytics becoming ever more mashed up in 2021 with (a) BI and analytics vendors providing seamless experiences for extending their graphics palettes as simple-to-modify native capabilities and deployment; and (b) marketplaces for sharing extensions across broad communities of practice. The maturation of Vega (from the d3 pioneers) as a visualization grammar and platform will help standardize and enforce best practices across these communities.

Yelenevych agrees, citing JavaScript’s frameworks as a key component to its success. “JavaScript—you can find this language in use on almost every website. I think React, already the most popular JS frontend library, will continue to gain popularity. In general, developers love to create applications in React.”

Indeed, it seems virtually certain that JavaScript will continue to serve as the engine that powers the web well beyond 2021, especially as new generations of students utilize it for websites’ scripted behavior. Millions of websites will still rely on third-party JavaScript libraries and frameworks.

Blazor

With the popularity of C#, I believe deeply that Blazor will become extremely popular this year. Typically speaking, programmers love working in one language, especially if that particular language is used for web development. In previous years, for any form of web development, a developer needed at least 2 different languages, a backend API as well as JavaScript/TypeScript. With Blazor now, you can potentially dismantle all use of JS for the use of C# from the backend to the frontend. They utilized the Razor language and WebAssembly, as well as a server side rendering. To read more, see a few of my previous articles listed below:

Why are code reviews important?

Grant Watson — Mon, 15 Feb 2021 19:39:11 +0000

Original post here

Define what a code review is:

Code review is a software quality assurance activity in which one or several people check a program mainly by viewing and reading parts of its source code, and they do so after implementation or as an interruption of implementation.

Git Push & Merge Conflicts Galore

Ideas of why it is a good idea to perform code reviews:

Sharing of knowledge and new techniques
Maintainability
Compliance in quality and requirements
Committers are motivated to write clean code, minimizing mistakes
Sharing of knowledge and new techniques

Every project has a host of unwritten rules and tacit understandings. This "institutional knowledge" must be transmitted to all new arrivals on a project. By definition it is impossible (and perhaps not even cost effective) to write down this information or to convey it all in one sitting. The inductee must acquire this information in the first months on the project, usually elicited from experienced developers when he does something wrong.

Code review can facilitate the communication of institutional knowledge as it relates to code written by the newbie. Experienced team members have the opportunity to impart their wisdom and advice.

At the heart of all agile teams is unbeatable flexibility: an ability to take work off the backlog and begin execution by all team members. As a result, teams are better able to swarm around new work because no one is the "critical path." Full stack engineers can tackle front-end work as well as server-side work.

Ensuring maintainability

The expense of developing software is not just in its initial creation but in the ability of developers to use and modify existing code in the future. Software is notoriously difficult and expensive to maintain. This is especially true when a developer leaves a project and a new developer arrives, but it is even true with a single developer looking back on code he wrote six months ago.

Maintainability is generally achieved by code organization and adequate comments. A person uninvolved in the project should be able to read a portion of code and understand what it does, see the constraints and preconditions of its use and contextual information (e.g. the author used a peculiar technique because of a bug in the OS). In addition, software organizations often have coding guidelines ranging from whitespace conventions to the maximum size of a function. A reviewer can provide the ignorance and objectivity necessary to ensure these goals.

Shell Research saved an average of 30 hours of maintenance work for every hour invested in inspections.

— Software Practice and Experience, 22(2):173-182, Feb. 1992.

It dramatically improves code quality

Let’s make something clear: this is not about standards and code linting (at least not exclusively). It’s about making code more efficient. In a team where everybody has their own background and strong suits, asking for improvements (because that’s what it’s about) is always a good idea. Someone could suggest a smarter solution, a more appropriate design pattern, a way to reduce complexity or to improve performance.

Minimizing your mistakes and their impact

This might seem like the most obvious advantage to the code peer review process, but it’s also one of the most important. When you’re working with the real pressures of time and budget, it’s easy to skip this step. Sure, you’re confident in your work, but even the best coders can go crossed-eyed from looking at their own work too long. Code review helps give a fresh set of eyes to identify bugs and simple coding errors before your product gets to the next step, making the process for getting the software to the customer more efficient.

Simply reviewing someone’s code and identifying errors is great. However, when it comes to the code peer review process there also needs to be a level of follow-up and accountability. Make sure there is process in place for checking back in to confirm code discrepancies have been addressed before moving into production.

Ensuring project quality and meeting requirements

The scope of any given software project and its requirements might run through the hands of several developers. The code review process can serve as a check and balance against different interpretations of that scope and requirements compared to the code that ends up being delivered. The second set of eyes can ensure you don’t fall into the “pit” you created based on your own understanding of what is being asked and that something important hasn’t been overlooked. Having code scrutinized by your peers can save a lot of time “confronting” QA later on.

Improving code performance

Due to the lack of experience, some younger developers might be unaware of optimization techniques that could be applied on their code. The code review process provides an opportunity for these developers to acquire skills and boost the performance of their code. Additionally, it gives these younger developers a chance to hone their skills and become experts in their craft.

While realizing the required functionalities, many developers also try to pursue optimized code for conciseness and performance efficiency. However, this will result in more code complexity and less readability. (Note: Code conciseness doesn’t mean its logic is simple to understand.) Moreover, the data model that the code is built on might change in later development phases. Thus, such premature optimization will eventually increase the cost of maintenance.

A Blazing Good Time in Blazor

Grant Watson — Mon, 15 Feb 2021 19:28:39 +0000

Original post here

This will be my first attempt at writing an article over something that I am learning on the way. Please be kind. I do think the best way that a person can learn something is to dive in and try and describe it another way, without diverting from the original definition. I am actually utilizing Blazor in an enterprise setting with my current position, so I am looking forward to learning about Blazor as my next step as a developer.

This article will cover some of the basics of Blazor, as well as an entry point for a series of future articles. What I plan on covering in this article:

What is Blazor?
What can Blazor be used for?
Blazor Hosting Models
Blazor Architecture

What do I plan on this series:

Blazor WASM
Blazor Server
Blazor Components
Data Binding
Routing
Dependency Injections
Lifecycle Methods
Invoke JS Functions
View Logic Separations
Forms and validation
Server Side Rendering
Client Side Rendering
What is Blazor?

So let’s get into it, what is Blazor. Blazor in of itself is Microsoft’s vision of a frontend framework. Blazor lets you build interactive web UIs using C# instead of JavaScript. Blazor apps are composed of reusable web UI components implemented using C#, HTML, and CSS. Both client and server code is written in C#, allowing you to share code and libraries. And we need to remember that Blazor is a feature of ASP.NET, so it can utilize other libraries of the .NET realm.

What can Blazor be used for?

Like I stated before, Blazor is part of Microsoft’s vision to allow it’s community of C# developers to continue in their route to write applications in C# from the backend to the frontend. Blazor allows for C# developers to limit their need of JavaScript. With that being said, there is still a need of JS in Blazor apps, more so in the JS Interop form, but not in as much as it was previously. Blazor should be categorized, and rightfully so, as a SPA framework. Microsoft took the concepts of other SPAs like Vue and React to make Blazor. Let’s build our applications in reusable components that can be utilized across our app(s).

Being able to code in majority of one language throughout an application’s life cycle, as well as building reusable frontend components so that I can keep up with the DRY philosophy seems like a dream. For these two reason, Blazor is your answer, and this is what Blazor can be used for. If you are strong in your confidence of ASP.NET and Razor page syntax, Blazor will be your new favorite toy to breakout and play with.

Blazor Hosting Models

There are two hosting models new developers to this arena need to know about: Blazor Server, and Blazor WebAssembly. Dependent on the structure of your needs for an new application will depend on the hosting model that you do.

Blazor Server:

With this hosting model, the app is executed on the server from withing an ASP.NET Core app. UI updates/changes, as well as some JS calls are handled over SignalR connection.

There are a lot of benefits from using this model:

Download size is significantly smaller that a WASM (another name for WebAssembly)
The app takes full advantage of server capabilities, including use of any .Net Core compatible APIs
.Net Core on the server is used to run the app, so existing .Net tooling, such as debugging, works as expected.
Thin clients are supported. For example, Blazor Server apps work with browsers that do not support WebAssembly and on resource-constrained devices
The app’s .Net/C# code base, including the app’s component code, isn’t served to the client
There are some cons of Blazor Server hosting:

Higher latency usually exists. Every user interaction involves a network hop
There’s no offline support. If the client connection fails, the app stops working.
Scalability is challenging for apps with many users. The server must manage multiple client connections and handle client state.
An ASP.NET Core server is required to serve the app. Serverless development scenarios aren’t possible.
Blazor WebAssembly(also known as WASM):

If Blazor Server runs on the server, you can safely assume, correctly so, that Blazor WASM runs on the client side inside the browser. This allows your site to be deployed as static files. Despite this, Blazor WASM apps will not directly run from the local file system due o the browser security restrictions.

Some of the benefits of Blazor WASM hosting:

Blazor WASM can work offline. When the network connection to the server is lost, the client app can continue to function. We can utilize sessionStorage/localDb/IndexedDB for “saving” items so once the network comes back up, the client app can talk to the server. Client resources and capabilities are fully leveraged.
It can also quite easily run as a Progressive Web App, which means the client can choose to install our app onto their device and run it whenever they wish without any network access at all.
With code running on the client’s machine it means the server load is significantly reduced.
An ASP.NET Core web server isn't required to host the app. Serverless deployment scenarios are possible (for example, serving the app from a CDN).
There's no .NET server-side dependency. The app is fully functioning after it's downloaded to the client.
Some cons/downsides to Blazor WASM hosting:

The blazor.webassembly.js file bootstraps the client application. It downloads all required .NET DLL assemblies, which makes the start-up time of the application slower than server-side.
The Mono Framework interprets .NET Intermediate Language so is slower than running server-side Blazor. Ahead-of-time (AOT) compilation is planned for a future release.
Blazor Wasm does not yet support more than a single thread, so all processing occurs on the UI thread – although calls to servers / JavaScript etc occur asynchronously, so do not block the UI’s responsiveness.
Additionally, Blazor Wasm only works on newer browsers and is not search-engine friendly (unless we enable server-side pre-rendering).
Download size is larger, and apps take longer to load.
.NET runtime and tooling support is less mature. For example, limitations exist in .NET Standard support and debugging.

Blazor Architecture

Traveling backwards a bit, Blazor in itself is strictly a client side web UI framework in nature to JavaScript frameworks like Angular and React. Blazor handles user interactions and renders the necessary UI updates. Blazor isn’t based on a request-reply model. User interactions are handled as events that aren’t in the context of any particular HTTP Request.

Blazor apps consist of one or more root components that are rendered on an HTML page.

How the user specifies where components should render and how the components are then wired up for user interactions is hosting model specific.

Blazor components are .NET classes that represent a reusable piece of UI. Each component maintains its own state and specifies its own rendering logic, which can include rendering other components. Components specify event handlers for specific user interactions to update the component's state.

After a component handles an event, Blazor renders the component and keeps track of what changed in the rendered output. Components don't render directly to the Document Object Model (DOM). They instead render to an in-memory representation of the DOM called a RenderTree so that Blazor can track the changes. Blazor compares the newly rendered output with the previous output to calculate a UI diff that it then applies efficiently to the DOM.

Components can also manually indicate that they should be rendered if their state changes outside of a normal UI event. Blazor uses a SynchronizationContext to enforce a single logical thread of execution. A component's lifecycle methods and any event callbacks that are raised by Blazor are executed on this SynchronizationContext.

I believe that this is a good overview of Blazor for now, and where this article comes to an end. I hope that you found this useful, and keep a look out for my other articles related to this one stated previously. If you have any questions, please comment below and I will reply back. The same goes for emails.

Exception Handling in C#

Grant Watson — Wed, 21 Oct 2020 17:41:02 +0000

The original post was from my site here.

In this post, I will cover, in short, C#’s exception handling. Other than syntax, you can take these principles forward with many OOP languages and utilize them. What are exceptions, and why should we as developers even consider handling them? Consider first what an exception is. Specifically in C#, an exception is a response to an exceptional circumstance that arises while a program is running, such as an attempt to divide by zero. Exceptions provide a way to transfer control from one part of a program to another. Another well thought definitions of an exception is that it is defined as an event that occurs during the execution of a program that is unexpected by the program code.

Your code runs into an exception when you try to give it a value, or expect an output where either is not known within the program. Exception handling allows a graceful way to handle unwanted events, an exception so that the program code still makes sense to the user.

The Anatomy of C# Exceptions
Exceptions allow an application to transfer control from one part of the code to another. When an exception is thrown, the current flow of the code is interrupted and handed back to a parent try catch block. C# exception handling is done with the follow keywords: try, catch, finally, and throw

Try: Used to define a try block. This block holds the code that may throw an exception

Catch: Used to define the catch block. This block catches the exception thrown by the try block

Finally: Used to define the finally block. This block holds the default code

Throw: Used to throw an exception manually

Example 1:

using System;

namespace ErrorHandlingApplication {
class DivNumbers {
int result;

  DivNumbers() {
     result = 0;
  }

  public void division(int num1, int num2) {
     try {
        result = num1 / num2;
     } catch (DivideByZeroException e) {
        Console.WriteLine("Exception caught: {0}", e);
     } finally {
        Console.WriteLine("Result: {0}", result);
     }
  }

  static void Main(string[] args) {
     DivNumbers d = new DivNumbers();
     d.division(25, 0);
     Console.ReadKey();
  }

}
}
Output

Above, we have set the values in a try, and then caught exceptions in the catch. Finally is also set to show the result

try {
result = num1 / num2;
} catch (DivideByZeroException e) {
Console.WriteLine("Exception caught: {0}", e);
} finally {
Console.WriteLine("Result: {0}", result);
}
Example #2: Exception Filters
One of the new features in C# 6 was exception filters. They allow you have even more control over your catch blocks and further tailor how you handle specific exceptions. This can help you fine-tune exactly how you handle exceptions and which ones you want to catch.

Before C# 6, you would have had to catch all types of a WebException and handle them. Now you could choose only to handle them in certain scenarios and let other scenarios bubble up to the code that called this method. Here is a modified example with filters:

WebClient wc = null;
try
{
wc = new WebClient(); //downloading a web page
var resultData = wc.DownloadString("http://google.com");
}
catch (WebException ex) when (ex.Status == WebExceptionStatus.ProtocolError)
{
//code specifically for a WebException ProtocolError
}
catch (WebException ex) when ((ex.Response as HttpWebResponse)?.StatusCode == HttpStatusCode.NotFound)
{
//code specifically for a WebException NotFound
}
catch (WebException ex) when ((ex.Response as HttpWebResponse)?.StatusCode == HttpStatusCode.InternalServerError)
{
//code specifically for a WebException InternalServerError
}
finally
{
//call this if exception occurs or not
wc?.Dispose();
}
Common .NET Exceptions
Proper exception handling is critical to all application code. There are a lot of standard exceptions that are frequently used. The most common being the dreaded null reference exception. These are some of the common C# Exception types that you will see on a regular basis.

The follow is a list of common .NET exceptions:

System.NullReferenceException – Very common exception related to calling a method on a null object reference

System.IndexOutOfRangeException – Occurs attempting to access an array element that does not exist

System.IO.IOException – Used around many file I/O type operations

System.Net.WebException – Commonly thrown around any errors performing HTTP calls

System.Data.SqlClient.SqlException – Various types of SQL Server exceptions

System.StackOverflowException – If a method calls itself recursively, you may get this exception

System.OutOfMemoryException – If your app runs out of memory

System.InvalidCastException – If you try to cast an object to a type that it can’t be cast to

System.InvalidOperationException – Common generic exception in a lot of libraries

System.ObjectDisposedException – Trying to use an object that has already been disposed

Here are a few articles to go into further detail of best practices:

Exception Handling

Microsoft Docs on Best Practices

The Realm of Virtual Reality

Grant Watson — Wed, 19 Aug 2020 06:59:41 +0000

Original Post found here

Definition:

Virtual reality is a simulated experience that can be similar to or completely different from the real world. Applications of virtual reality can include entertainment and educational purposes. Other, distinct types of VR style technology include augmented reality and mixed reality.

Contenders of the arena:

Oculus

Unity Technologies

Virtuix

Limbix

I am utilizing this space to cover 4 companies in a 4 part series that are contenders in the VR realm. There are quite a few other companies that specialize in VR, but it will be interesting to see what these 4 companies have in common, as well as what makes them starkly different.

Let’s start with the overall idea of virtual reality. It is not really a new concept. The idea of VR is plant oneself into an alternate realm of possibility. This could be, in essence, reading a book, role playing board games similar what DnD is, playing a video game. Up until maybe 10 years ago, we were unable to digest virtual reality in the context that we are today.

Let’s expand on what virtual reality is.

Virtual Reality (VR) is the use of computer technology to create a simulated environment.

Virtual Reality’s most immediately-recognizable component is the head-mounted display (HMD). Human beings are visual creatures, and display technology is often the single biggest difference between immersive Virtual Reality systems and traditional user interfaces.

Major players in Virtual Reality include HTC Vive, Oculus Rift and PlayStation VR (PSVR)

You may ask what the difference between Virtual Reality and Augmented Reality? These two realities are just two sides of the same coin. You can think of Augmented Reality as VR with one foot in the real world: Augmented Reality stimulates artificial objects from the view point of the camera, superimposing the computer-generated images over a user’s view of the real world.

In Augmented Reality, the computer uses sensors and algorithms to determine the position and orientation of a camera. AR technology than renders the 3D graphics as they would appear from the viewpoint of the camera, superimposing the computer-generated images over a user’s view of the real world.

In Virtual Reality, the computer users similar sensors and math. However, rather than locating a real camera within a physical environment, the position of the user’s eyes are located within the simulated environment. If the user’s head turns, the graphics react accordingly. Rather than compositing virtual objects and a real scene, VR technology creates a convincing, interactive world for the user.

WTF is JAMstack???

Grant Watson — Wed, 19 Aug 2020 06:56:12 +0000

Original post found here

I am a subscriber to a podcast series called Coding Blocks (https://www.codingblocks.net/). It is a fun series to listen to for developers from juniors to seniors. And throughout the series, they have made some statements toward JAMstack, but the episode they published February 3, 2019 titled “JAMstack for J.A.M”. This episode inspired me to go into a deep dive of what JAMstack is and where I would used versus other technologies.

Let’s go into defining what JAMstack is:

JAMstack stands for JavaScript, APIs, and Markup. The term was coined by Mathias Biilmann to describe “a modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup.” — from https://www.contentful.com/r/knowledgebase/jamstack-cms/

Sites that are similarly built with Jekyll, Hugo, Next and Gatsby, you may have already used, or at least seen sites built on JAMstack. The main selling point for using JAMstack is to host up static sites to the public.

The JAM of JAMstack stands for JavaScript, API and Markup. Let’s break down what each represent in the stack:

JavaScript

Dynamic functionalities are handled by JavaScript. There is no restriction on which framework or library you must use

APIs

Server side operations are abstracted into reusable APIs and accessed over HTTPS with JavaScript. These can be third party services or your custom functions

Markup

Websites are served as static HTML files. These can be generated from source files, such as Markdown, using a static site generator.

Well, what are the benefits? Why not use SPAs?

A single page application (SPA) is a web application that loads a single static HTML page and dynamically hydrates it with new content on user interaction. In this very light definition of an SPA, seeing that it generally serves the user static pages with JS and APIs, they can be considered JAMstack, but should never be assumed to be JAMstack. The long and short of why you may choose JAMstack over SPA is for those wanting better control over SEO. SPAs fall short on SEO.

Main benefits of JAMstack:

Faster performance - serve pre built markup and assets over a CDN

More secure - No need to worry about server or database vulnerabilities

Less expensive - hosting static files for cheap or even free

Better developer experience - frontend devs can focus solely on frontend

Scalability - If your product goes viral with many users, the CDN compensates

Foundations of JAMstack

JAMstack is a set of tools that can be used to build an ecosystem. There are three foundations that are more like conventions rather than a set of specific tools that you have to use to fit in the definition of the term JAMstack.

JavaScript

JS is the first foundation of the whole stack. You can love it or you can hate it but you have to admit that JavaScript is one of the most popular programming languages these days with an incredibly vibrant community. The request and response cycles are based on client side thanks to this technology. You can use either pure JavaScript or use any other framework or library available on the market such as React or Vue.

API

Though I did mention the static websites, the next foundation of the JAMstack are APIs. Thanks to it you can use backend functionality without having a database or the backend engine on your own server. You still have backend, yes, but deploy only a static website. You can use any API you want, public or private. There are many third-part sites you can choose from. You can also connect to the other backend app that you have created.

Markup

The presentation layer of your website. With the JAMstack ecosystem usually, it’s a static site generator where templated markup is prebuilt at the build time. You can write your own HTML and CSS code or use a framework such as Hugo, Jekyll or Gatsby, which will greatly improve the time of template development.

History of JAMstack

It all started with the LAMP stack where LAMP stands for Linux Apache MySQL and PHP. The term refers to the tech stack where a website is running on a Linux server with the MySQL database and PHP programming language. You might hear about WAMP or MAMP which is the same but refers to Windows and Mac OS.

This movement started in the late ’90s. Back then most of the websites on the Internet were running on MySQL and PHP. Before PHP there was just static HTML which allows building static websites. Since LAMP was coined, static websites were not cool for a long time. In 2016 a small group of developers established the term JAMstack and started to slowly promote it among other developers and the whole dev community.

A year later, in 2017, the JAMstack community has grown and static websites became something more than just information pages where the content was changed only by editing page files and uploading them on the server. It was possible to build dynamic websites and apps. The new stack has hit the mainstream and it became very popular in a relatively short time.

Benefits for the developer

The biggest benefit for the developers using JAMstack is the saved time on every step of the development process. JAMstack provides a great developer experience since generating code is way faster than writing it from scratch. Also, the deployment process is easier because you don’t have to think about the database and other backend stuff, you just deploy a static website where most of the content is usually already present. Let’s have a look at how to build a website with JAMstack.

Getting started with the JAMstack

If you’re new to this whole idea of the JAMstack, you might be a little overwhelmed at this point. Knowing where to start is sometimes the hardest part.

First, remember that we’re talking about frontend-centric development here. If you’re new to web development in general, you’ll want to make sure to sharpen your JavaScript skills. Then learning as much as you can about APIs will allow you to push your projects to the next level.

Once you've got this covered, well, the sky’s the limit as they say—as long as you can find the tools to match your ambitions.

New projects

Starting from scratch is the best way to build a “pure” JAMstack. This way you can really choose all the necessary pieces to create what you want. As I explained earlier, building and hosting are decoupled. The first thing you’ll want to decide is what to use to build your site/app.

The modern frontend ecosystem may make your life hard here. Not because of a lack of relevant tools. Actually, it’s just the opposite! There are hundreds of possibilities, even if some clearly stand out.