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