Speaker 1: Ever feel like you're constantly playing catch up with the
Speaker 1: latest tech.
Speaker 2: Oh definitely.
Speaker 1: One minute you think you're right in the wave, the
Speaker 1: next you're wondering like, should I have learned that new
Speaker 1: framework last week?
Speaker 2: Yeah? It moves so fast.
Speaker 1: It's a real challenge, isn't it, staying genuinely well informed
Speaker 1: without just drowning in, you know, information overload totally. Well,
Speaker 1: today we're hoping to help you cut through some of
Speaker 1: that noise. Our deep dive today is into view js two.
Speaker 1: It's a really powerful JavaScript framework that's made building reactive
Speaker 1: web applications surprisingly accessible.
Speaker 2: I think, yeah, it really has.
Speaker 1: We're going to explore its capabilities, its core philosophy, and
Speaker 1: you know what truly makes it stand out in the
Speaker 1: let's face it crowded world of web development.
Speaker 2: And for this deep dive, our main source is it's
Speaker 2: excellent book Learning VIEWJS two by Olga Philipova, came out
Speaker 2: back in December twenty sixteen, okay, and it's just a fantastic,
Speaker 2: really practical guide. It takes you through everything from the
Speaker 2: basics right up to building you know, complex real world apps.
Speaker 1: Great, So our mission today is to really pull out
Speaker 1: the most important insights from that source, we'll guide you
Speaker 1: through viewjs's origins, its foundational principles, then get practical with
Speaker 1: how to actually build applications, test them thoroughly which is key,
Speaker 1: and finally deploy them so the world can see them.
Speaker 1: All right, should we dive in, let's do it. Okay,
Speaker 1: So to kick things off, what's the origin story here?
Speaker 1: How did view js even come to be? What's the
Speaker 1: behind the scenes tail?
Speaker 2: What's actually a pretty classic story sort of necessity breeding invention.
Speaker 2: Evan you the creator. He was working at Google Creative
Speaker 2: Labs at the time, and he found himself needing a
Speaker 2: tool for quickly prototyping large user interfaces. He looked around
Speaker 2: at what was available. Then you had Angular widely used
Speaker 2: but well quite heavy, yeah, and react to es was
Speaker 2: just sort of starting to emerge, but often involved a
Speaker 2: more complex MBC architecture, you know, model view controller layers,
Speaker 2: standard pattern exactly, and those options they just felt too complex,
Speaker 2: maybe too heavyweight for the kind of rapid UI prototyping
Speaker 2: he needed to do. I think so Evan saw this
Speaker 2: clear gap, you know, for something lightweight, flexible and really
Speaker 2: focused on easy reactive data binding with reusable components. That's
Speaker 2: really where view began.
Speaker 1: So born from a very specific need speed in prototyping,
Speaker 1: but it obviously grew way beyond that pretty quickly. Did
Speaker 1: What was it about views core design that let it
Speaker 1: evolve like that to handle complex, scalable applications? Yeah? How
Speaker 1: do you bridge that gap from just prototyping?
Speaker 2: That's a great question, and it really boils down to
Speaker 2: its core philosophy simplicity and reactivity. Okay, viejs as real
Speaker 2: brilliance I think lies in its almost deceptively simple approach
Speaker 2: to data. It treats your models as just plain JavaScript objects.
Speaker 1: Plain JavaScript objects. H Yeah.
Speaker 2: And that wasn't just like a convenience thing. It was
Speaker 2: almost a philosophical stand You don't need special syntax or
Speaker 2: complex class or you know, an endless list of dependencies
Speaker 2: just to define your data. And that drastically lowered the
Speaker 2: barrier to entry. It let developers focus on the application logic,
Speaker 2: not wrestling with framework stuff, which I mean that's a
Speaker 2: huge part of why it gained traction so fast. Makes sense,
Speaker 2: And just to clarify some key terms here reactivity and VIEWJS.
Speaker 2: That refers to the immediate propagation of any changes to
Speaker 2: your data straight to the view layer, so.
Speaker 1: Data changes, UI updates.
Speaker 2: Instantly instantly exactly. And components they are like self contained
Speaker 2: Lego bucks for your app, little pieces with their own
Speaker 2: data and view designed to be reused everywhere.
Speaker 1: Okay, reusable building blocks.
Speaker 2: And two way data binding means changes in the data
Speaker 2: model update the view and crucially, changes in the view
Speaker 2: like typing in an input field, they reflect right back
Speaker 2: into the data model.
Speaker 1: That seamless feedback loop precisely. That clarity around data flow
Speaker 1: and component sounds really powerful. So with that foundation, how
Speaker 1: does the book actually show view dots in action? What
Speaker 1: are the practical example? Right?
Speaker 2: So the book introduces two very practical applications. There's a
Speaker 2: shopping list and a Pomodoro.
Speaker 1: Timer okay, classic examples.
Speaker 2: Yeah, And the shopping list one is particularly good because
Speaker 2: the book first implements it using jQuery for comparison exactly,
Speaker 2: and then it does it with VIEWJS, and that side
Speaker 2: by side really highlights views elegance and frankly efficiency in
Speaker 2: handling things like adding and removing items dynamically compared to
Speaker 2: what can become pretty verbose jQuery code I can imagine.
Speaker 2: And then the Pomodoro pimer app you know, based on
Speaker 2: that time management technique with work intervals.
Speaker 1: Yeah, focus bursts, right.
Speaker 2: It uses VJs for managing the countdowns, handling all the
Speaker 2: state changes, starting, pausing, stopping the timer, switching between work
Speaker 2: and rest. It's a great way to see that reactivity
Speaker 2: concept really working.
Speaker 1: That sound like great learning tools. Yeah. Does the book
Speaker 1: also mention how VJs is used out in the wild
Speaker 1: beyond these examples, any like big projects or companies using it?
Speaker 2: Oh? Absolutely, Yeah. The source points to some really impressive
Speaker 2: real world projects that adopted view, which really speaks volumes
Speaker 2: about its practicality and scalability Wiku. Well we're talking big
Speaker 2: names like Grammarly's online editor uses it, Optimizedly's website testing service.
Speaker 2: There's filter Blend, which is a CSS playground, push silver
Speaker 2: and invoice service, and also Adera, a Ukrainian online educational
Speaker 2: project where the author Olga Philipova is actually the CTO.
Speaker 2: They use view too.
Speaker 1: Grammarly and Optimizedly. Those are huge. Yeah. That definitely shows
Speaker 1: it's not just for small projects or learning. It's clearly
Speaker 1: robust enough for serious production grade stuff, no question. Okay,
Speaker 1: so we've seen it in action. Now let's get under
Speaker 1: the hood a bit what makes VIEWJS work its magic?
Speaker 1: What are the the underlying mechanics right?
Speaker 2: So, fundamentally, VIEWJS is deeply rooted in the model view
Speaker 2: view model architectural pattern or MVVM MVVM okay, and the
Speaker 2: view model part that acts as the sort of clever bridge.
Speaker 2: It enables declarative data binding between raw data model and
Speaker 2: the user interface.
Speaker 1: The view declarative meaning you just say what you want,
Speaker 1: not how.
Speaker 2: To update it exactly. You declare the relationship, and the
Speaker 2: view model handles the synchronization. Now that magic of the
Speaker 2: instant updates, that's powered by JavaScript's object dot defined property,
Speaker 2: specifically its gutters and setters ah.
Speaker 1: The built in JavaScript features right.
Speaker 2: And what's crucial here is that view isn't constantly like
Speaker 2: rechecking everything the way some older frameworks did. Instead, when
Speaker 2: you change a piece of data, View's internal watchers are
Speaker 2: immediately alerted. They pinpoint exactly what needs updating in the UI.
Speaker 2: So it's targeted efficient, very efficient. And here's where things
Speaker 2: got really interesting. A major evolution in View two point
Speaker 2: zero compared to one point zero was the shift to
Speaker 2: a virtual dom.
Speaker 1: Right. I've heard that term.
Speaker 2: View one point zho directly manipulated the real browser dom,
Speaker 2: which could you know, get slow sometimes, but moving to
Speaker 2: a virtual dom and view two point zero that was
Speaker 2: the key unlock. Also, Mike, i'reating this lightweight blueprint of
Speaker 2: your UI in memory. View could figure out the absolute
Speaker 2: minimum changes needed and then applied just those changes to
Speaker 2: the real browser dom.
Speaker 1: So it minimizes the actual slow DOM updates exactly.
Speaker 2: It turned what used to be a performance bottleneck into
Speaker 2: a massive advantage. It allowed for building really complex dynamic
Speaker 2: interfaxes without constantly worrying about performance hits. It wasn't just faster,
Speaker 2: it made certain kinds of UIs feasible.
Speaker 1: That virtual dom sounds like a genuine game change of
Speaker 1: then it really was. Speaking of performance and architecture, How
Speaker 1: does viejs stack up against the other big players like
Speaker 1: React in Angular.
Speaker 2: Good question. Let's start with React in view because they
Speaker 2: share quite a bit. Okay, both use a virtual dom,
Speaker 2: both are built around reusable components, and both are fundamentally
Speaker 2: about reactivity.
Speaker 1: Similar core ideas very similar.
Speaker 2: A key difference though, often comes down to how you
Speaker 2: create components. React famously embraces this everything is JavaScript idea,
Speaker 2: often using jsx.
Speaker 1: Right that htmail in javascripts and text exactly now.
Speaker 2: View can use JSX too, but it's more common practice.
Speaker 2: The sort of idiomatic way is to structure components with
Speaker 2: distinct template, script and style blocks inside a single dot viewfile, which.
Speaker 1: Might feel more familiar to folks coming from traditional web dev.
Speaker 2: It often does, yeah now learning curve wise, View is
Speaker 2: often described as like out of the blue, simple to
Speaker 2: just start using. You can drop it into an existing
Speaker 2: page with plain JavaScript. React, on the other hand, typically
Speaker 2: requires a bit more initial investment in learning JSX and
Speaker 2: modern JavaScript features like e S twenty fifteen classes and erowfunctions,
Speaker 2: though those are standard now anyway.
Speaker 1: Got it and performance performance.
Speaker 2: Wise benchmarks at the time showed View two point zero
Speaker 2: is actually even faster than React in many scenarios.
Speaker 1: Interesting. Okay, what about Angular versus View right?
Speaker 2: The main difference there is that View is significantly less
Speaker 2: opinionated than both Angular one and Angular two were, or.
Speaker 1: Are less opinionated, meaning more flexible yea.
Speaker 2: Less prescriptive about how you structure your entire application. Also,
Speaker 2: Angular ones specifically used a technique called dirty checking.
Speaker 1: Dirty checking sounds messy.
Speaker 2: Yeah, well, it meant that every time something might have
Speaker 2: changed in the scope, Angular had to reevaluate all the
Speaker 2: watchers to see what needed updating. With lots of watchers,
Speaker 2: that could impact performance. Okay, views approach using object dot
Speaker 2: defined property is more direct. When a specific property changes,
Speaker 2: only that property's watcher gets triggered and reevaluated, much more efficient,
Speaker 2: especially in complex apps.
Speaker 1: That makes sense. That less opinionated aspect sounds really appealing
Speaker 1: for developers who like flexibility.
Speaker 2: It's definitely one of its big draws.
Speaker 1: Okay, let's circle back to those core building blocks, components
Speaker 1: and data binding. Can we get into the nitty gritty
Speaker 1: details of how they work in practice?
Speaker 2: Absolutely so. Components, as we said, are these self contained units.
Speaker 2: They have their own data scope, their own methods. They
Speaker 2: can access global application scope, but they encapsulate their own logic.
Speaker 1: Right now.
Speaker 2: A critical point, especially for components their data and l properties.
Speaker 2: The element they mount to must be functions that return
Speaker 2: an object, not direct objects themselves.
Speaker 1: Okay, why is that so critical?
Speaker 2: It's vital to prevent shared state issues when you reuse
Speaker 2: a component. Imagine you have a counter component used in
Speaker 2: multiple places. If data was just an object, every instance
Speaker 2: would share the exact same counter variable.
Speaker 1: Oh right, Clicking one counter would increment them all chaos.
Speaker 2: Exactly. Making data a function ensures each component instance gets
Speaker 2: its own fresh copy of the data state.
Speaker 1: Got it. That's a key detail.
Speaker 2: And view offers a really elegant way to organize these
Speaker 2: single file components. These are files ending in dot feustways. Yeah.
Speaker 2: They let you bundle a component's HTML template, its JavaScript logic,
Speaker 2: and its CSS styles altogether in one file.
Speaker 1: That sounds really clean.
Speaker 2: It is. It improves readability, makes components easier to manage,
Speaker 2: and it also enables cool development features like hot relf loading.
Speaker 2: And you can easily use preprocessors like SaaS for CSS
Speaker 2: or PUG for HTML.
Speaker 1: Nice. Okay, what about the different ways to actually bind
Speaker 1: data to the UI?
Speaker 2: Right? If you gives you several techniques, The most basic
Speaker 2: is interpolation using the double curly braces.
Speaker 1: Like the handlebar syntax exactly.
Speaker 2: That's for one way binding, just displaying data values in
Speaker 2: the DOM. And inside those braces you can use full
Speaker 2: JavaScript expressions and.
Speaker 1: Filters expressions like math yeah like.
Speaker 2: Mouth output just twenty five. Or you can use custom
Speaker 2: filters to format data right there in the template, maybe
Speaker 2: a lowercase filter or a left pad filter for numbers.
Speaker 2: You can even chain them together.
Speaker 1: Handy for formatting.
Speaker 2: Very Then you have directives. These are special attributes you
Speaker 2: add to HTML elements, always prefixed with V They apply
Speaker 2: reactive behavior okay, like v model exactly. V model is
Speaker 2: the key one for two way data binding. You typically
Speaker 2: use it on form inputs like input select, text area,
Speaker 2: user types, something. The data updates, data changes, the input
Speaker 2: field updates, but back and forth.
Speaker 1: Clop.
Speaker 2: Right. Then there's v bind, which you often see shortened
Speaker 2: to just a colon like dot src or dot class.
Speaker 2: Ah the shorthand hold, Yeah, that's for one way binding attributes,
Speaker 2: binding data to an attribute, like setting an image source
Speaker 2: dynamically or toggling CSS classes based on data.
Speaker 1: Okay, data flowing into the attribute correct.
Speaker 2: Then you have v if and v show for conditional rendering.
Speaker 1: Right, what's the difference there?
Speaker 2: Again, both hyder show elements based on a condition, but
Speaker 2: v if actually adds or completely removes the element from
Speaker 2: the dom physically gone physically gone, which has a higher
Speaker 2: initial cost if the condition changes, but might be better
Speaker 2: if it rarely toggles. V show, on the other hand,
Speaker 2: just toggles the CSS display none property, so.
Speaker 1: The element is always there, just hidden.
Speaker 2: Exactly, lower initial cost, always rendered, so it's often better
Speaker 2: for things you toggle frequently.
Speaker 1: Like tabs. Okay, good distinction.
Speaker 2: And finally, V four is super useful for iterating over
Speaker 2: arrays or objects. To render lists. You can loop through
Speaker 2: data and render and lie for each item, or even
Speaker 2: render instances of other custom view components.
Speaker 1: Dynamically generating lists very common, extremely common. Those directives really
Speaker 1: show off views reactive power. But you know, as apps
Speaker 1: get bigger, managing all that state across loads of components,
Speaker 1: that sounds like it could get messy fast.
Speaker 2: Oh, it absolutely can, and that is precisely the problem
Speaker 2: that viex solves. The wix VX is View's official centralized
Speaker 2: state management architecture. It's inspired by patterns you might know
Speaker 2: like flux or reducts from the React world, right, but
Speaker 2: it's generally described as having a much gentler learning curve.
Speaker 2: The book calls it easier to understand and to use.
Speaker 1: Easier is good. How does it work well?
Speaker 2: The book uses this great analogy think of the human
Speaker 2: body and brain. Your brain in this analogy is the
Speaker 2: viewx store. It is the single source of truth for
Speaker 2: your applications. Global state things shared across many components.
Speaker 1: The central control exactly.
Speaker 2: Now, your components think of them like your hands or
Speaker 2: your stomach. They are bound to the state, but they
Speaker 2: can only read it directly. They can't just, you know,
Speaker 2: directly change how hungry the body feels.
Speaker 1: My hand can't decide I'm not hungry anymore precisely.
Speaker 2: Instead, components dispatch actions to the brain the store. Hey
Speaker 2: I touched something hot, or hey food arrived.
Speaker 1: Okay, sending signals right.
Speaker 2: These actions can be asynchronous, maybe fetch data, then actions
Speaker 2: trigger mutations. Mutations are the only way to actually change
Speaker 2: the state, and crucially, they have to be synchronous.
Speaker 1: Synchronous. Why is that important?
Speaker 2: It makes tracking changes much easier. You know exactly when
Speaker 2: and how the state changed because it happens in one
Speaker 2: predictable step. This whole structured approach prevents components from just
Speaker 2: randomly changing global state, which makes things way easier to
Speaker 2: debug and maintain.
Speaker 1: I see a clear predictable flow exactly.
Speaker 2: So, the key parts of a Vieux store are the
Speaker 2: state itself, which is just your centralized data object, mutations,
Speaker 2: which are those synchronous functions that change the state. Components
Speaker 2: commit mutations, mutations, got it getters, which are like computed
Speaker 2: properties for your store's state. They let you derive state
Speaker 2: or calculate values based on the state without actually changing.
Speaker 1: It by calculating the total price from items.
Speaker 2: In a card state, perfect example. And finally, actions these
Speaker 2: can handle asynchronous stuff like calling an API. Once they
Speaker 2: have the data or finish their logic, they then commit
Speaker 2: mutations to update the state. Components dispatch actions, dispatch actions
Speaker 2: commit mutations.
Speaker 1: Okay, So this whole structure state, mutations, getters, actions sounds
Speaker 1: like it brings a lot of discipline, especially to bigger projects.
Speaker 2: It really does. It creates this predictable data flow in
Speaker 2: a complex app. Trying to figure out where some piece
Speaker 2: of state change can be a nightmare. If components are
Speaker 2: modifying things.
Speaker 1: Directly, yeah, I've been there.
Speaker 2: Fux centralizes it. You know what the state is, how
Speaker 2: it changes only via mutations and when triggered by actions.
Speaker 2: That clarity is massive for debugging, collaboration.
Speaker 1: Just keeping things same makes total sense. Okay. So beyond
Speaker 1: views core and VIEWX, what if you need some really
Speaker 1: specific custom functionality or want to integrate a third party
Speaker 1: library smoothly? How do developers handle that?
Speaker 2: That's where views plugins system really shines. Plugins are basically
Speaker 2: a way to add global level functionality. Global level yeah
Speaker 2: things like adding global methods or properties, custom directives, filters,
Speaker 2: or even adding methods directly to view instances themselves, things
Speaker 2: that aren't tied to just one component. For a plug
Speaker 2: in to work, it just needs to provide an install
Speaker 2: method that.
Speaker 1: View calls okay, an install method right.
Speaker 2: The book gives a couple of great examples. First, using
Speaker 2: an existing plug in view resource a for HTTP requests exactly,
Speaker 2: it shows how to integrate that plug in to let
Speaker 2: the shopping list app talk to a back end API
Speaker 2: fetching lists, creating items, updating, deleting using a simple tool
Speaker 2: called Jason Server.
Speaker 1: Jason Server it's super handy.
Speaker 2: I lets you spin up a fake rest API really quickly,
Speaker 2: just using a JSON file as your database. Great for
Speaker 2: development and examples like this. Oh. Then the book also
Speaker 2: walks you through creating a custom plug in for the
Speaker 2: Pomodoro app. It shows how to build a noise generator plug.
Speaker 1: In noise generator like white.
Speaker 2: Noise exactly, white pink or brown noise to play during
Speaker 2: the work intervals, and the plugin provides methods to control
Speaker 2: it start, pause, stop, which are then managed through viewx mutations,
Speaker 2: integrating neatly with the app state.
Speaker 1: That's a great example of extending functionality building your own
Speaker 1: plug in.
Speaker 2: It really shows the flexibility.
Speaker 1: Okay, so you've built these cool apps, maybe added some plugins,
Speaker 1: but how do you make sure they actually work reliably
Speaker 1: and you know, don't break when you change something later?
Speaker 1: Let's talk testing.
Speaker 2: Yes, testing absolutely paramount. The book covers the two main pillars,
Speaker 2: unit tests and end to end E two E testing.
Speaker 1: Unit tests first, what's the focus there?
Speaker 2: Unit tests focus on testing the small TuS pieces of
Speaker 2: your code in isolation, individual functions, methods, or components. The
Speaker 2: book emphasizes they help us to identify failures and algorithms
Speaker 2: in logic, They improve the code quality by forcing you
Speaker 2: to write testable code, and crucially, they prevent future changes
Speaker 2: from breaking.
Speaker 1: The functionality right, catching regressions exactly.
Speaker 2: The tools mentioned are pretty standard. Karma as a test runner,
Speaker 2: Mocha as the testing framework, Chry for assertions checking if
Speaker 2: things are correct, and sign On for creating mocks and stubs,
Speaker 2: mox and steps. Yeah, ways to fake dependencies, like if
Speaker 2: you're testing a component that calls VUX, you don't want
Speaker 2: to involve the real viewx store. You mock it to
Speaker 2: control its behavior just for the test.
Speaker 1: Okay.
Speaker 2: The book gives a good example testing of UX mutation
Speaker 2: like a D shopping list. It shows how a test
Speaker 2: might initially fail if the mutation doesn't say validate the
Speaker 2: input properly. You write the test. It fails, You fix
Speaker 2: the code. The test passes, that cycle improves the code.
Speaker 2: It also mentions code coverage, a metric showing what percentage
Speaker 2: of your code is actually covered by your tests.
Speaker 1: Right, aiming for high coverage. Okay, what about end to
Speaker 1: end testing?
Speaker 2: So end to end E t E testing is different.
Speaker 2: It tests the whole flow of the application from a
Speaker 2: user's perspective.
Speaker 1: Like simulating a real user clicking.
Speaker 2: Around exactly no mocks allowed here. Usually you test the
Speaker 2: integrated system the front end UI interacting with the real
Speaker 2: or near reel back end. It verifies that everything works
Speaker 2: together correctly. The book uses Nightwatch dot js, which is
Speaker 2: a JavaScript framework that drives Selenium webdriver.
Speaker 1: Selenia okay, the browser automation.
Speaker 2: Tool right now. A common challenge with E two E
Speaker 2: tests is running them in environments without a screen, like
Speaker 2: a continuous integration server. Travis CI is mentioned.
Speaker 1: A servers don't usually have monitors.
Speaker 2: Exactly, so how do you run a browser test? The
Speaker 2: solution presented as a tool called XVFB, the x virtual
Speaker 2: frame buffer. It basically creates a fake in memory display
Speaker 2: that the browser can render to tricking it into thinking
Speaker 2: there's a.
Speaker 1: Screen clever workaround.
Speaker 2: It works really well for CI environments.
Speaker 1: Okay, so we've built it, We've tested it rigorously, unit tests,
Speaker 1: E two E tests. What's the final step getting it
Speaker 1: out there for people to actually use? Deployment? Right?
Speaker 2: Software deployment. The book defines it simply as all of
Speaker 2: the activities that make a software system available for use,
Speaker 2: and it details a really nice continuous deployment process for
Speaker 2: the example apps.
Speaker 1: It continues deployment meaning automated.
Speaker 2: Yeah, setting up an automated pipeline from code commit to
Speaker 2: live application. It makes the whole process much smoother and
Speaker 2: less error prone.
Speaker 1: What tools does it use for that pipeline?
Speaker 2: It describes a three step process. One GitHub for hosting
Speaker 2: the code repository pretty standard. Two Travis CI for continuous integration.
Speaker 2: Travis automatically runs your tests, unit and ETOE every time
Speaker 2: you push code to your main branch like master. If
Speaker 2: the test pass it gives a green.
Speaker 1: Light, so quality check built.
Speaker 2: In absolutely and three Heroku, which is a cloud platform
Speaker 2: use for continuous deploy. You can figure it so that
Speaker 2: after a successful build and test run on TRAVISCI, if
Speaker 2: Travis says okay, Heroku automatically takes the latest code, builds
Speaker 2: the production version, and deploys it, making it live on
Speaker 2: the web.
Speaker 1: Wow, that's slick code. Push to live app automatically.
Speaker 2: It is that feeling when you merge a feature and
Speaker 2: a few minutes later it's live. It's pretty addictive and
Speaker 2: this pipeline makes it almost frictionless.
Speaker 1: Are there any specific configurations needed for say.
Speaker 2: Heroku, Yeah, a few things. You typically need to move
Speaker 2: some development only dependencies into the main dependency section in
Speaker 2: your package dot json file so Heroku installs them. You
Speaker 2: need a post install script and package dot jason that
Speaker 2: tells Heroku how to build your app like running NPM
Speaker 2: run build okay, and usually need a small serve file
Speaker 2: like server dot js using Express, a popular noe js framework,
Speaker 2: and a start script in package dot jason to tell
Speaker 2: Heroku how to actually run your built application and serve
Speaker 2: the static files right. Because Heroka needs to run something
Speaker 2: exactly for the shopping list app. It even integrates Jason
Speaker 2: Server into this setup, so the same deployed application serves
Speaker 2: both the viewfront end and its own little back end API.
Speaker 1: A fully self contained deployable unit.
Speaker 2: Pretty much. It creates that full automated pipeline code desh
Speaker 2: test to desk deploy.
Speaker 1: That's a truly comprehensive journey we've mapped out from the
Speaker 1: initial idea and core concepts all the way to a tested, deployed,
Speaker 1: production ready application. Amazing. Looking ahead just a bit, what
Speaker 1: was next for VIEWJS, even beyond the timeframe of this book.
Speaker 1: How did it keep evolving?
Speaker 2: Well, it's important to remember as the book emphasizes that
Speaker 2: View two point zero itself was a major refactor that
Speaker 2: shnift to the lightweight virtual dom structure we talked about. Yeah,
Speaker 2: that brought huge performance gains. The book quotes benchmarks showing
Speaker 2: its performance beats everything at that time. So I View
Speaker 2: two was already a big leap forward. Okay, But looking
Speaker 2: even further, the book mentions weeks weeks Yeah, a framework
Speaker 2: from ali Baba that allows you to write view inspired
Speaker 2: component and render them as native mobile applications for iOS
Speaker 2: and Android.
Speaker 1: Whoa so using view concepts for native mobile exactly.
Speaker 2: It hints at views ambition expanding beyond just the web.
Speaker 2: The creator, Evan You even said the goal was for
Speaker 2: view inspired to become viewpowered native apps that cross platform.
Speaker 1: Vision interesting, taking the viewaid to mobile.
Speaker 2: And for people who are using View one point zero.
Speaker 2: The book also notes that there was a migration guide
Speaker 2: and even a helper tool provided by the View team
Speaker 2: to make upgrading to two point zero smoother.
Speaker 1: That shows good community.
Speaker 2: Support Definitely making transitions easier is always appreciated.
Speaker 1: What an incredible deep dive this has been. Seriously, we've
Speaker 1: gone from the foundational ideas of viewjs its reactivity, through
Speaker 1: building components, managing state with viex, using plugins, testing everything thoroughly,
Speaker 1: and finally deploying these complex reactive web apps out into
Speaker 1: the world. It feels like we've covered the entire life cycle.
Speaker 2: We really have. But you know, this deep dive, it
Speaker 2: isn't really the end of your journey with viewjas. It's truly,
Speaker 2: as the book suggests, just the beginning.
Speaker 1: Ah, the learning never stops exactly.
Speaker 2: You now have all the fundamental tools and the knowledge
Speaker 2: you need to keep exploring to enhance these applications, maybe
Speaker 2: build your own, make them your own thing.
Speaker 1: So what kind of enhancements could someone try?
Speaker 2: Oh? Loads? Think about the shopping list app. You could
Speaker 2: add authentication, right, so users have their own private lists.
Speaker 1: Yeah, that's a big one.
Speaker 2: Or inline editing for item names, a clear checked items button,
Speaker 2: maybe configurable styling, let users pick background colors, text colors, fonts.
Speaker 2: The book even suggests item categorization with adaptive icons, kind
Speaker 2: of like the split wise app does for expenses.
Speaker 1: Cool ideas. What about the Pomodora timer.
Speaker 2: For the Pomodora application, you could make the working and
Speaker 2: resting periods fully configurable by the user, implement longer breaks
Speaker 2: after say every four pomodoros.
Speaker 1: Standard Pomodora technique rule.
Speaker 2: Right, you could display and store user statistics, which but
Speaker 2: also need that authentication piece. Maybe let users choose their
Speaker 2: preferred noise type from that custom plug. And we talked about.
Speaker 1: White, pink or brown noise on demand exactly.
Speaker 2: I mean, the possibilities they're really endless once you.
Speaker 1: Have the foundation, absolutely, and you don't have to stop
Speaker 1: at web apps either, right.
Speaker 2: Not at all? Consider extending them. Use tools like weeks
Speaker 2: as we mentioned, to try and bring them to mobile,
Speaker 2: or maybe turn them into Google Chrome apps, which the
Speaker 2: book also touches on briefly.
Speaker 1: So take these concepts cross platform.
Speaker 2: Why not. You're now equipped. You have all the instruments
Speaker 2: you need to enhance these apps, improve them, build new ones,
Speaker 2: and show them to the whole world.
Speaker 1: A fantastic challenge and a great place to leave it.
Speaker 1: You've got the tools, now go build something amazing.