Welcome to the Deep Dive. Today. We're tackling a pretty big topic, JavaScript frameworks.
Yeah. It's a huge part of web development today for sure.
And we're using Vlad Philippa's book Building Your Own JavaScript Framework as our main guide here.
That's the plan.
Our mission really is to cut through some of the complexity and get to the core of why these frameworks are so dominant and what makes them actually work right.
And this book is pretty recent, came out last year. Vlad Philipov, he's got a ton of experience Mozilla, Stripe, grunt js wow.
Yeah, solid background.
Definitely, and he's really aiming to help developers not just use frameworks, but understand them deeply, maybe even build their own.
That's ambitious, it is.
And Mike Taylor from Google wrote the ForWord, which kind of speaks to Vlad standing in the community.
Okay, cool, And for you listening, maybe you're making tech choices or leveling up your skills, or maybe you're just curious about like the plumbing of the modern web. This deep dive should give you a solt a handle on JavaScript frameworks. We'll try to keep it practical, focus on the why and the what without drowning in jargon.
Sounds good, let's get into it.
Okay, So where does the book start the rise of JavaScript itself?
Exactly? It sets the stage by looking back at JavaScript's journey over twenty five years. Right, it went from just simple scripting.
Yeah, like making text blank basically.
Pretty much to being this, you know, powerhouse language. It's used on something like ninety eight percent of websites. That's staggering, it really is.
You can't imagine the Web without it now. And the book makes the point that frameworks became the standard way to build things.
Millions of developers rely on them. They enable that rapid development we see everywhere.
It's hard to argue with that, And the.
Book poses an interesting thought. Maybe the Web wouldn't have kept up with other platforms like native apps without frameworks pushing things forward.
Huh, that's a big claim. Why what were the early challenges?
Well, think about it. Early on front tend stuff was often lots of repeated code, not much focus on like organizing for performance or scalability.
Right, copy paste driven development sometimes.
Sometimes yeah, And deployment was often pretty basic too. Frameworks brought structure.
And they pushed for things like a build step right tools like webpack s build. Those weren't common before.
Not nearly as common. That build step became crucial. Package managers too for handling all the dependencies, and transpilers like Babble letting you use new JavaScript features sooner.
Okay, So frameworks sort of force the ecosystem to mature in a way.
You could definitely say that, which brings us to the benefits. The big one the book highlights is abstraction.
Abstraction meaning hiding complexity.
Pretty much providing simpler ways to do complex things. It lets developers focus on the actual business logic, the features, and iterate faster.
Gotcha like the example of asynchronous web requests before fetch API was standard.
Oh yeah, that used to be way more complicated. Different browsers handled x some LHTTP requests differently. Error handling was tricky. Frameworks smoothed all that out.
I remember those days. It was painful totally.
And it's not just basic browser stuff. Frameworks help integrate with databases external APIs.
Like graft you all integration, maybe exactly.
Some frameworks make that much simpler. It helps keep your front end and back end talking.
Nicely, and presumably helps with security too. By providing standard ways to do things.
That can be a benefit. Yeah, fewer chances for common errors. Plus they help developers keep up with evolving web standards.
Okay, what else tooling you mentioned CLIs right?
Command line interfaces clies are huge.
Many frameworks come with one, so you type commands in your terminal yep.
Like the Ember CLI. It can set up a whole new project for you, generate boilerplate code for components or routes.
Ah. So it saves a lot of setup time and keeps things consistent exactly.
It's like having a toolkit ready to go.
Makes sense. The book then gives specific examples, which I found really helped.
Yeah, Comparing them really clarifies the different philosophies. They start with MBERGS, which is described as opinionated, highly opinionated. It makes a lot of choices for you about structure, component services, models, routers, CLI, even data management with.
Mber data, so steeper learning curve maybe the.
Book suggests that. Yeah, but the payoff is supposed to be consistency and guidance towards building really solid, maintainable apps, especially for larger teams.
And it came from sprout Core originally.
Interesting, Yeah, it has a history. Then you've got spelt Kit powered by Spelt.
Right the dot sveelt files everything in one place, script style HTML.
Huh. And it's big thing is the compiler. It does a lot of work before the code even hits the browser, compiling those spelt components into efficient vanilla javascripts.
That's different. And it uses vite for tooling.
Yeah, vitees done for being really fast during development.
Okay. Then next JS that's built on React right for service side.
Rendering primarily, Yes, SSR is a big focus. Lots of built in features, especially around fetching data, very popular for sites needing good SEO.
And NEXTJS is kind of the view equivalent.
Broadly speaking, Yes uses VJs. Also focuses on SSR and optimizing the app experience, often using Webpack and babble behind the scenes.
And solid start for solog ijs. What's its angle?
The book highlights its flexibility with rendering methods and its efficient rendering using like standard browser features, real dom nodes, web components.
Interesting and remix full stack.
Yeah. Remix handles frontend and back end. Very UI focused, uses Typescript and React, known for its powerful routing, often file based, lots of rendering options too.
Wow, Okay, that's quite a spectrum of approaches.
It really is, and the book tries to categorize the common features and patterns you see.
Across them, like spa single page application.
Right where the page loads once and content updates dynamically.
SSR service side rendering, which we mentioned, good for SEO initial.
Load, CSR client side rendering, the browser does all the work.
SSG static site generators build all the HTML upfront, good for blogs.
Docs exactly, And patterns like SFC single file components like spelt uses and.
Those classic architectural patterns MVC, MVVM.
Model view controller, model.
Viewview model. Yeah, common ways to structure the code's responsibilities. They're blueprints. Many frameworks adapt.
The book mentioned the Touto MBC project here.
Oh yeah. Totem vc was brilliant, simple to do app built in dozens of different frameworks.
You could compare them side by side.
Exactly apples apples comparison of syntax structure performance. It was incredibly useful for understanding the differences.
We probably need a new version of that now with all the newer frameworks.
The book suggests that too, would be fascinating.
Definitely now The book also touches on back end frameworks right, not just front end.
YEP important distinction. Frameworks aren't just for the browser. Back End frameworks help build server side logic and APIs thick.
Express That one comes up a lot.
Express is huge in the no jail world, very minimal, unopinionated, often a starting point you build on top of it.
What about others? Happy dot js?
Happyjs is more opinionated, convention over configuration, strong built in features for things like validation sales.
Dot js sales is like an MVC framework built on Express. Enterprise focus, RM support powerful CLISJS that sounds familiar. SGS is very popular, uses Typescript, heavily structured similarly to Angular. Actually good for micro services, web sockets, graph QL and isjs another comprehensive typescript back end framework. RM templating routing kind of an all in one solution.
Okay, so lots of options on the back end too, and even goes beyond the web.
Yeah. Briefly mentions native and hardware frameworks React Nator for cross platform mobile.
Apps build once, run on iOS and Android.
That's the idea Electron for desktop apps using web tech like HTML, CSSGS.
Like Slacker vs code exactly.
And even Johnny for robotics programming hardware with JavaScript.
Ohoh, okay, JavaScript really is everywhere.
It's wild, and you can't talk frameworks without talking testing.
Right, ensuring things actually work.
The book mentions just Playwright Vitist as examples crucial for billing, reliable apps and reliable frameworks.
Okay, and mentioned the STATEDJAS dot com survey is a way to track trends.
Yeah, that survey is a great resource. The book noted the twenty twenty two surveys showed maybe a slight dip and reacts retention rate developers saying they'd use it again.
Interesting suggest the landscape is always shifting.
Absolutely, which is why the book emphasizes understanding the core patterns that transcend specific popular frameworks. Those ideas are likely to stick around.
That makes sense. Focus on the fundamentals. Okay, so we've covered the Y and the what, Let's peel back the layers. How are these things actually built? Framework organization and abstractions.
Right, And the book even nudges you to use debugging tools like in vs code to poke around inside a frameworks code and see how let's put together.
Get your hands dirty exactly.
So abstractions we mentioned them before, but they're central taking complex stuff, giving it a simpler interface.
Hiding the messy details, and.
Also organizing different features into usable patterns. It lets developers focus on their specific problem the business logic, not the low level plumbing.
Cuts down on repetition complexity.
Right, and abstraction is a Corsis concept, not just web dev. Simplifying complex systems is how we build anything sophisticated.
The book talks about levels of abstraction.
Yeah, like layers browser APIs or one level back end services running on OS infrastructures. Another frameworks add their own layers on top.
But abstractions aren't perfect right downsides good point.
The book mentions they might be incomplete, not cover every edge case, or they might misrepresent the low level system, which can be confusing if you need to debug deep and being.
Too opinionated can limit flexibility.
Definitely, Like the next JSAP roads examples. Super convenient for the standard case, but maybe restrictive if you want a different structure. It's a tradeoff.
Okay, So what are these abstractions built from? In JavaScript?
On the front end? A lot builds on the web APIs The browser provides domb bomb, cssom fetch, web sockets, storage, background services, tons of them.
So frameworks often wrap these browser features, often.
Yes, or they build their own abstractions from scratch based on their design goals.
Like the next JS nestlink example.
Perfect example. It simplifies creating internal links compared to a basic HTML attag building on view router's capabilities, but adding next specific features takes.
A basic tool, makes it more framework specific and convenient exactly.
And on the back end, no js provides its own APIs, and frameworks build on those, sometimes adding custom extensions.
The abstraction levels vary there too, like nestjs letting you swap HTTP frameworks right, you.
Can choose express or fastify under the hood in nests. That's a pretty high level of abstraction over the server itself.
Events are important too.
Crucial responding to user clicks on the front end, handling beta streams on back end. Happyjs has its event system. Johnny five uses events for sensor data.
It's everywhere and the UI specific stuff components.
Yeah, the building blocks of UI.
Yeah.
The book distinguishes between nesting just putting one inside another and composition designing them to work together flexibly.
Light cycle methods those hooks where you run code at specific.
Times YEP like mounted in view or use effect and React frameworks manage the component life cycle and give you points to.
Plug in routers for mapping URLs.
Essential for spas mapping a URL path to the right component or logic.
And template engines mixing HTML like syntax with data.
Right, defining the structure and binding it to application state.
Okay, and the book clarifies modules, libraries and frameworks good distinction.
Modules are about code organization, encapsulation. Libraryes solve specific problems like podash for utilities, React for UI. Frameworks provide the whole structure the rules of the game, often using libraries internally.
Got it modules Organized libraries solve frameworks orchestrate nicely print Okay, so we understand abstractions and building blocks. What about the overall internal architecture? How are framework structured inside?
This part focuses on the patterns APIs packaging tooling, basically how the framework itself is engineered, and a key point is that the architecture is often designed with the framework user the developer in mind.
Makes sense. It has to be usable.
Totally, so you see things like a clear directory structure, separation of concerns different parts do different jobs, and well defined public interfaces the APIs developers actually interact with.
Some frameworks are split into multiple repos like Angular.
Yeah for very large frameworks that helps manage complexity. Core logic might be separate from the CLI tool, for instance.
And modules are key for organizing the frameworks on code too.
Absolutely the module pattern is universal form encapsulation. The technical architecture then outlines the specific APIs entry points and tooling.
And it's all distributed as packages, usually via NPM.
Mostly Yes, packages contain the core logic, public, private APIs, maybe build tools. The book points out some common package types in modern frameworks.
Like a server interface package for full stack.
Or back end right like ne SGS adapters, NEXTJS server package, feltkit adapters. They handle the connection to the deployment environment.
Shared packages for common utilities.
YEP reusable stuff like helper functions, constants, maybe HTML escaping logic.
Core API packages the fundamental building.
Blocks exactly like Angler's dependency injection system. The stuff developers used.
Directly developer tools packages.
Enhancing the dev experience, linters, formatters, debug tools integrated somehow and plugin extension APIs crucial for customization, allowing users or other developers to extend the framework without modifying the core. Think Happy dot JS plugins or solid as integrations.
What about entry point Where does it all start?
Key concept where the framework or the application using it boots up Ember's application class, nuts, dot com fig, dot JS back end, bootstrap files like an ADONISJS or sjs's app module.
And binary s executables. The cli tools we talked about YEP.
Scripts for building, testing, scaffolding, managing dependencies, automating the workflow.
Compiler, bundler, infrastructure tools like babble s built.
Essential, transforming and optimizing the code. For production frameworks often bundle or configure.
These tools and types.
For Typescript very important if the framework uses Typescript. Exporting type definitions ts files allows developers using Typescript to get autocompletion and type checking. Huge productivity boost.
Wow. Okay, A lot goes into the internal plumbing. So once it's built, how do you ensure it's well, good, usable, in high quality.
That's the next section focuses on documentation, framework, testing, and deb tooling. Documentation is first, and the book calls it absolutely crucial for adoption sense.
If people can't figure out how to use.
It, they won't. So comprehensive API references good examples, maybe even internal docks for contributors.
API references can be generated automatically.
Sometimes yeah from code comments using tools like jstoc or type doc or written manually. Stat Site generators like Docusaurus are often used to build the actual documentation websites. Viewdogs and Angular are mentioned as having strong docs. Examples are key to hugely important. They drastically lower the learning curve. Can be in the docks or as separate code samples, even for internal company frameworks. Good examples save tons of time.
And internal docks for contributors. Explaining how to build test contribute code.
Essential for open source YEAH, setting contribution guidelines, coding standards, Ember and Angular are again cited as good examples here.
Then testing the framework.
Itself vital making sure it's correct performance, handles edge cases using testing frameworks like just playwright vitised internally.
What kinds of tests unit.
Tests for individual functions, modules and isolation, integration tests to check how different parts work together. End to end tests that run a whole sample application built with the framework.
Testing the whole workflow exactly.
The book gives snippets showing how Angular and NESGS might test their own internal pieces.
Benchmarking performance too.
Yep, measuring API speed, rendering efficiency, how it handles large inputs, both public APIs and internal micro benchmarks. Next, dot js having benchmark scripts is mentioned.
And finally, development tooling for the framework's own development.
Right, things like CI systems for automated testing on every commit, good source control practices with get tagging releases, managing branches, and well configured package dot json files for dependencies and development scripts. Linting building testing.
Sgs'spackage dot Jason is shown as an example of how complex that can get.
It really ties everything together. The book wraps up this part by noting that learning from the recurring patterns in existing framework architectures is super valuable.
Okay, so we've gone deep on internals and quality. What about someone actually thinking, Hey, maybe I should build a framework. What considerations come first?
The book shifts to that practical perspective. Next starts with really defining the project goals.
Who is this for the target audience? Right? Web apps, component libraries, back end native exactly.
That defines the scope, then identifying the specific problem space, What pain point are you solving? How is it different or better than existing solutions?
That's the unique value proposition precisely.
And then come the big technical design decisions, your tech stack, architectural patterns, development approach. These foundational choices shape everything.
Revisiting that idea of abstraction levels crucial.
Finding the right balance between simplifying things and keeping enough flexibility, clean interfaces boosting productivity but not overly restrictive.
In which JavaScript environments to support browser node deno big decision.
Supporting multiple environments adds complexity and maintenance overhead. Need to choose carefully.
And leveraging existing libraries. Don't reinvent the wheel.
Strong advice use solid libraries for common tasks routing, state management, data fetching. Focus your effort on what makes your framework unique. Angular using RxJS view, recommending Pinia next, building on React good examples.
Okay, makes sense, right? Did the book gets really hands on with examples building Componium test.
Yeah, this is where it gets concrete. Building a simple testing framework starts with branding, name, logo colors. Seems small, but identity matters. Choosing a unique name space.
Is key avoid naming collisions right.
Then architecting it core goal, test JS code with assertions, what's needed, test runner, cross platform support, assertion types, test suite interface, what's out of scope? Initially, code coverage, stubbing, build system integration, keep it.
Focused, find the minimum viable product essentially kind of yeah.
Then design the overall structure the executable CLI, handling options, emitting test status, respecting test life cycles, sat up, tear down.
And implementing executors for different environments. Node executor, browser executor exactly.
Node executor runs tests in node may be using worker threads for isolation. Browser executor needs to control a real browser, maybe using.
Puppeteer puppeteer let's node control Chrome yep.
It bridges node and the browser handles headless mode, no visible UI or headful visible. Browser needs to send results back from the browser to the node.
Runner complex and designing the API for writing tests the eight function assert object life cycle methods.
That's the developer facing part needs to be intuitive. CT defines a suite assert checks conditions, cert equaliss are true, life cycle hooks like before each run before tests mocking fake replaces also considered.
Then implementing step by step node in first internal packages, browser, infra, result collection.
Logical progression, and the CLI needs to be well behaved, follows standard conventions. Choose the right executor based on user input.
And testing the testing framework itself with E two E tests.
Meta but necessary. Ensure the whole install, import, execute workflow functions correctly.
Okay, that's a great walkthrough for a focused tool. Then it tackles a full stack framework Componium again.
Yep, same brand, bigger scope. Back End and front end functionality starts with the back end entry point a server file using Express as a foundation. Middleware routing requests parsing API responses similar pattern to SGS starting point.
Back End routing uses Express routes.
Configuration handled by a config package. Supports YAML, json JS formats, sensible defaults in default dot JS standard practice. THETIS integration uses sqalized ORM via a dB package, loads models automatically from a model's directory, shows an example query within a route handler.
ORM simplifies database code definitely optional.
Graph Quel support is also mentioned for flexible APIs observability.
Log using a logger class based on Winston logs to console and dev json files and PROD standard levels. Dot info warn.
Error good for debugging and monitoring and developer experience.
A big focus a Componium CLI for in it scaffold project dev, start dev server with hot reloading, create scaffold components, streamlining the workflow, walks through a sample workflow, install in it dev, create components, ad models, ad tests.
Yeah shows how a developer would use the CLI and framework features mentions tools like chokodar for file watching, at inquirer for interactive prompts, yards for parsing CLI arguments.
Okay, so that covers the back and end DX. Then it switches to the front end part of the Componium.
Right building the UI side goals interact with the back end API, provide visual interfaces, mimic features like reactivity from established.
Frameworks, architecture, component based views, routing.
Standard front end patterns. Key features discussed.
Component based architecture, reusable UI.
Pieces, reactivity, UI updates automatically when data changes, uses web components and the proxy API. In this basic.
Example, templating defining UI structure uses lit html here for writing HTML and JS.
Server side rendering SSR pre render on the server for performance, SEO inject state.
Production optanizations, medification using s build.
Shows implementing reactive components. Reactive component class using proxy YEP extends HTM element uses proxy to watch state changes. Templating with lit HTML's tagged templates.
Defines a Componium component class combining reactivity and lit uses. E S six imports handles events like ad Click.
Exactly shows how components are defined and used. Server serve static files. SSR prerenders components.
Client side routing maps URLs to components, basic client views, object examples.
Simple mapping. Yeah shows in a framework item component rendered via SSR, then hydrated on the client mentions enabling prod mode with noto D and V production.
Wow. Okay, so it really walks through building significant pieces. What's the final section about maintenance In the future.
Crucial stuff starts with the software development life cycle SDLC planning, design, implement, test, deploy, maintain applies to frameworks too. Agile is mentioned as an extension.
Development cycle for frameworks. Gathering user feedback is key.
Essential formal future definition processes like RFCs, mber U examples keeping users informed about changes.
Release process details, change logs.
Need good change logs, automating them from commit messages. Commit is in change sets, version INGSIMB major minor dot patch versus calvert date based semantic release tool for automating simver document your strategy.
Simplifying releases. Tools like release it, NPCD pipelines.
Automating testing, building, version bumping, publishing, continues, delivery via GitHub actions circle ci makes it smoother.
Licensing open source apatche MITGPL versus proprietary.
Important decision early on choose al license. Dot com helps consider dependency, licenses too.
And long term maintenance security.
Huge topic, document dangerous APIs, track vulnerabidities oas manage dependencies securely.
Dependency management is ongoing pain.
Can be keep track update, maybe migrade away from stale ones. Minimize dependencies where possible.
Future coverage and deprecation.
Decide long term value of features. Deprecate carefully with migration paths, use extension points, plugins, middleware to avoid.
Core blow modularity, MPM pros cons Evolving design with tech changes, web components, node APIs.
Constant adaptation needed, good abstractions help manage change.
Then common themes in frameworks today, minimalism.
Yeah, lean, core focus, preact happy core performance improvements.
Constant push, faster rendering, lower resource use. Benchmarking tools help compare jsframework benchmark tetch, empower, dot com Developer experience DX.
Big focus, better tooling, clearer APIs, easier workflows in.
The future, more built in tooling.
Likely, continued performance focus, core web vitals, more flexibility, database integrations, packaging, bundling improvements, influence of browser engine changes, package management evolution.
And final practical considerations. Funding, time, support, reality.
Checks, frameworks need resources, money, sponsorship services, donations, significant time investment, and user support structures.
Okay, that's a comprehensive lick, so let's try to wrap this up. What are the main takeaways from this deep dive.
Well, I think it's clear that JavaScript frameworks aren't just random code. They're complex systems built on careful abstractions.
Right, designed to speed up development, handle complexity.
Exactly, and they've evolved so much. Understanding they're building blocks, components, routing, state, abstraction, and their architectural patterns gives you real insight into how modern web development actually works.
And for you the listener, whether you're aiming to build your own tools one day or just want to understand the tech you.
Use better, exploring these ideas really empowers you, right, It helps you make better choices, learn faster.
Definitely, So maybe check out some of the frameworks we mentioned, dig into abstraction modularity.
Maybe even try building a tiny component, or look at the contribution guide for an open source project to use see how it's put together.
Yeah, this deep dive is just scratching the surface. Really, it's a huge, constantly changing feel absolutely so. A final thought to leave everyone with maybe.
Just that the web isn't standing still, so frameworks won't either. Staying curious, understanding the principles behind the tools, not just the tools themselves. That's probably the best way to stay ahead of the curve.
Great point, keep learning the fundamentals. Thanks for joining us for this deep dive.