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