Hi there, VanJS author here. Thank you so much for this awesome video. It's incredible that all of the main logic of VanJS is explained so well in this video within 7 minutes! Thanks for spreading the good words!
Hey! Thank you for your work on this! It was really inspirational to look into Van's codebase. You were able to achieve a lot with just a few lines of code. Really great stuff! Thanks for the donation!
Dear VanJS author, would you recommend anyone to build a portfolio or semi advanced project (not counter or hello world toys) with VanJS. And also do you have any plans to add a DSL like JSX or maybe the goal of the project to create a foundation for people to then add features on top?
@boomshakalaka656 Yes, there are lots of sample apps you can find in the website. There are 3rd party add-ons for JSX support. (this comes directly from Tao Xin, VanJS's author).
Omg I love this! The difference between a good programmer and a great programmer is his understanding of the tools he's using. And this is exactly what I've been looking for.
This video reminds me when I saw the source code of wordle for the first time. It had ui components, animations, state, storage, game logic, and a lot more in just a few lines of code. 60% of js file was just the word array for the game. I think actual code was under 200 lines.
Very good video! And it reminds me of a project I made, I'm not a front end developer, but I created a very similar lib to use in my personal projects, it's called lithen-fns and it uses a tagged function approach inspired by lit-html
Yoo the effort you are putting in is amazing. I am loving the new style of videos ❤. Keep going but IDK if a lot of people would watch these videos though
I would like someone to try to make a semi advanced project with this (not a hello world or counter app) and share with the world if the DX cost was worth it.
It depends on how the development cost of producing something with a mainstream framework like react is calculated. If you take someone who knows JS but not any framework, I'd wager that they'd be quicker with Van than React or Svelte simply because it's so much simpler, you don't need months of tutorials to get to a place where you can build an app and can't say how it works. If you're already an existing frontend dev, then it's not gonna come up directly, but knowing how your tools work is part of being a senior. I've met dozens of React devs and only 1 could ever explain how React actually worked. As for e-commerce, blog or even portfolio with Van: there's literally no problem with that, what are you implying?
@@HeWhoShamesNarwhals Sorry by DX l'm taking about Developer Experience not development cost (sometimes the relation is proportional, but they are 2 diff things). By DX cost I'm mainly talking about things like 1) how fast can you build something (not a hello world or counter app), 2) how fast can you make changes to your webapp, 3) if there is a bug how long does it take you to find and fix what caused it and 4) was it worth spending your time trying to solve problems that have been solved by mature frameworks already. These are challenges that only show up when you build semi - advanced web apps (not a toy counter app)!
Although van.js is arguably pretty in how it employs 133 LOC to make 60% of work that we expect from typical UI framework... it becomes impractical choice if even smallest website requires Google Analytics, custom fonts, carousel, lightbox equivalent gallery viewer and contact from. I know you can get around this by trimming and selfhosting fonts, using Plausible for tracking and custom implementation for essential functionality, but does the audience know as well? :) Just and idea for a future video.
Advanced topics worth covering if you'd ever plan any deep dive: - comparing pieces of Van.js to Vue/React/Angular to get an idea for "why the bloat exists" because it is not entirely useless - augmenting Van.js with fancy logger to have "your own logger" as there are no extensions for DevTools - hence debugging web app could become nightmare - full stack of tools for minimalists... could we (devs) be productive with Bun, Van.js, Supabase or some KV store, etc.?
Pretty good video. Great take on the frontend library but I would hate to maintain this library. The code style makes it unreadable and confusing. I would not mind working with it thou.
@@boomshakalaka656 I'm talking about maintaining the library as of the 150ish lines of code and not about working with the library. I personally wouldnt mind creating something with it. I'm sorry, if my writting skills gave you the wrong impression of what I was trying to say. I will try to correct it immediately
Yep - the code is compact and sometimes confusing due to the focus on making it as small as possible. You could easily make it more clear, but you'll spend some bytes doing so :D
Hi @captsiro233, VanJS author here. I chose a concise style while writing the VanJS code as this is the style I like the most. In the context of corporate programming I have to follow the styling rules that are decided by the org. I understand some styling choices in VanJS are controversial, but since it's a personal project, I decided to just follow my heart on styling instead of trying to guess what styles the world likes the most.
@@alexanderxin I'm sorry if my comment was too harsh. By all means use the coding style that you want. It's just that if I had to work in a codebase like this it would have been really difficult because I like more robust style: - using a lot of blank lines to separate code into logical blocks - using full names for variables (string instead of s or str and so on) ... Still pretty insane that you made it so small
Can we call proxy as actor? Does it share similarity with message passing patterns like actors, microservices talking via pub-sub, processes talking using d-bus?
I don't think that would be possible because van uses the signal reactivity and react uses rerender reactivity. This means that the react component function is executed every single time the state changes. While van component function is executed only once and then signals dictate what will change. It is like trying to implement a method on a class that is executed a lot and turn it into a class constructor. What could be done is to compile just plain old jsx into this approach. Oh wait that is exactly what solid js does.
could you try to explain this again in more detail, maybe rewrite some of the functions to be more readable. it's very compressed code and hard to understand what the heck anything is doing. very very cool
Hey! Thanks for the suggestion. This is one of the main things I'll post in the near future - more hands on implementations of various aspects used in web frameworks. So, for certain, I'll revisit some of the Van's implementation in more detail.
Vanjs is great but has some issues regarding reactive object and array. For that reason, I've created bau, it solves these issues and add functionalities such as lifecycle methods. Both projects move away from the angle bracket syntax. Readability and writability go to the moon.
@@kartikmadhak6327 I did, but it's always the same after revisiting the code after a couple of weeks - I have to focus and remember what I thought I understood in the past.
Realistically, when would this ever be useful? I just can't think of a situation where I feel like other more prominent libraries are too bloated, and vanilla Javascript is not enough. Like honestly, JS is more than performant enough to handle working with proper frameworks without affecting perceived user performance dramatically at all. And if I was building something large enough for performance to become a concern, I wouldn't go for this solution either because of the many drawbacks. If I want reactive components, I'll personally use React - but there are lots of other alternatives that all work fine and have more sophisticated features - and the build step is such a small burden that comes with so many pros that I'm not sure how much that weights in on my consideration.
You just learned this framework in 7 minutes. React takes years to learn, and then the framework changes and you need years to re-learn. So that could be a reason. Or the direction these huge frameworks are taking (going fullstack) might not be what you want to do. I think that the market for these frameworks exists as a "I wanted to do it vanilla and remembered mid development that maybe React is not useless"
basically, any simple personal project + exploration of different takes on a single problem or if you don't want any build step and just make the file run in browser
Basically, any simple personal project + exploration of different takes on a single problem Not everyone enjoys compiling ts or tsx. Also, it uses solidjs's signals reactivity which is more performant because you don't need to go through the whole tree and check for updates
@@captsiro233 People make it sound like they compile TS/TSX by hand 😂. Signals are one small part of what makes a framework usable. Heck the most popular JS framework doesn't even use signals 🤷♂
@@boomshakalaka656 1) A few times I have found myself most of the time just waiting to recompile and then test the output. So it was really nice to just use JS make a change, save, and imidietly see the difference. Talking about 3D rendering, it is a stretch, but when I was debugging 3D projection I would loose my mind to recompile on every single little change like changing -2 to -3 or 10 to -10 2) Signals are better DX for me. It is better abstraction of reactivity for me. I think of reactivity like this: You press a button which triggers like event and then little pieces of the UI change because they are directly connected to the button. Like I said. It is better abstraction for me. Plus I like to do a little bit more computation heavy and highly reactive application and there the little gain of using signals can be felt. (Although at that point I would not probably use a framework and stick to vanilla JS)
Hi there, VanJS author here. Thank you so much for this awesome video. It's incredible that all of the main logic of VanJS is explained so well in this video within 7 minutes! Thanks for spreading the good words!
Hey!
Thank you for your work on this! It was really inspirational to look into Van's codebase. You were able to achieve a lot with just a few lines of code. Really great stuff!
Thanks for the donation!
Dear VanJS author, would you recommend anyone to build a portfolio or semi advanced project (not counter or hello world toys) with VanJS. And also do you have any plans to add a DSL like JSX or maybe the goal of the project to create a foundation for people to then add features on top?
@@boomshakalaka656 I guess you are looking for SolidJS.
I believe VanJS is something comparable to jQuery, but it makes things reactive.
@@boomshakalaka656Yes, there are lots of sample apps you can find in the website. There are 3rd party add-ons for JSX support.
@boomshakalaka656 Yes, there are lots of sample apps you can find in the website. There are 3rd party add-ons for JSX support. (this comes directly from Tao Xin, VanJS's author).
Omg I love this!
The difference between a good programmer and a great programmer is his understanding of the tools he's using.
And this is exactly what I've been looking for.
Glad to hear!
Impressive. Very nice. Let's see Paul Allen's framework
Spot on! :))
Paul Allen's framework - Solid JS, impeccable reactivity, lightning speed, oh my god.. it even has a meta-framework...
@@awesome-coding Something wrong? patrick, you are sweating...
Such a clean and beautiful project. Thank you very much for covering this!
Glad you like it!
This video reminds me when I saw the source code of wordle for the first time. It had ui components, animations, state, storage, game logic, and a lot more in just a few lines of code. 60% of js file was just the word array for the game. I think actual code was under 200 lines.
Yep! Smart people - smart code :D
Definitely going to try this framework, well done on the explanation
Glad it was helpful!
Very good video! And it reminds me of a project I made, I'm not a front end developer, but I created a very similar lib to use in my personal projects, it's called lithen-fns and it uses a tagged function approach inspired by lit-html
Very cool!
i like projects like these. we need to promote them more. strawberry js is also interesting but i think this is more suitable to building real apps.
Strawberry's codebase seems to be way bigger compared to this one 🥲😅
@@awesome-coding much larger but smaller than solid and the other frameworks
Super good video as always ! Waiting for Awesome merch to drop by this point !
Haha, maybe one day! Thanks for the kind words!
I love seeing library code it always intresting
Same here - VanJS is a really interesting case study due to its small size
Amazing video, you are getting better
Thank you!
Yoo the effort you are putting in is amazing. I am loving the new style of videos ❤. Keep going but IDK if a lot of people would watch these videos though
Thank you so much!!
i've seen this implementation before. the wheel of time
I would like someone to try to make a semi advanced project with this (not a hello world or counter app) and share with the world if the DX cost was worth it.
Imagine making an e-commerce, blog or even portfolio with this. 😂😂😂. Thanks @Awesome but lm skipping this one😖
It depends on how the development cost of producing something with a mainstream framework like react is calculated. If you take someone who knows JS but not any framework, I'd wager that they'd be quicker with Van than React or Svelte simply because it's so much simpler, you don't need months of tutorials to get to a place where you can build an app and can't say how it works.
If you're already an existing frontend dev, then it's not gonna come up directly, but knowing how your tools work is part of being a senior. I've met dozens of React devs and only 1 could ever explain how React actually worked.
As for e-commerce, blog or even portfolio with Van: there's literally no problem with that, what are you implying?
@@HeWhoShamesNarwhals Sorry by DX l'm taking about Developer Experience not development cost (sometimes the relation is proportional, but they are 2 diff things).
By DX cost I'm mainly talking about things like 1) how fast can you build something (not a hello world or counter app), 2) how fast can you make changes to your webapp, 3) if there is a bug how long does it take you to find and fix what caused it and 4) was it worth spending your time trying to solve problems that have been solved by mature frameworks already. These are challenges that only show up when you build semi - advanced web apps (not a toy counter app)!
My first reaction is that this poor DX is probably not worth the hassle
@@3urobob I think so too
Although van.js is arguably pretty in how it employs 133 LOC to make 60% of work that we expect from typical UI framework... it becomes impractical choice if even smallest website requires Google Analytics, custom fonts, carousel, lightbox equivalent gallery viewer and contact from. I know you can get around this by trimming and selfhosting fonts, using Plausible for tracking and custom implementation for essential functionality, but does the audience know as well? :) Just and idea for a future video.
Good points! Thank you for the suggestion!
Advanced topics worth covering if you'd ever plan any deep dive:
- comparing pieces of Van.js to Vue/React/Angular to get an idea for "why the bloat exists" because it is not entirely useless
- augmenting Van.js with fancy logger to have "your own logger" as there are no extensions for DevTools - hence debugging web app could become nightmare
- full stack of tools for minimalists... could we (devs) be productive with Bun, Van.js, Supabase or some KV store, etc.?
@@pauljohnsonbringbackdislik1469 All really great ideas! I especially like the "minimalist" angle. Will add these in my queue. Thanks so much!
Alright! We got a new one lol. Great video thanks!
Thanks for watching!
I just love it ❤ amazing
Glad to hear!
Pretty good video. Great take on the frontend library but I would hate to maintain this library. The code style makes it unreadable and confusing. I would not mind working with it thou.
Ohh here you are actually sharing your true opinion 👀
@@boomshakalaka656 I'm talking about maintaining the library as of the 150ish lines of code and not about working with the library. I personally wouldnt mind creating something with it.
I'm sorry, if my writting skills gave you the wrong impression of what I was trying to say. I will try to correct it immediately
Yep - the code is compact and sometimes confusing due to the focus on making it as small as possible.
You could easily make it more clear, but you'll spend some bytes doing so :D
Hi @captsiro233, VanJS author here. I chose a concise style while writing the VanJS code as this is the style I like the most. In the context of corporate programming I have to follow the styling rules that are decided by the org. I understand some styling choices in VanJS are controversial, but since it's a personal project, I decided to just follow my heart on styling instead of trying to guess what styles the world likes the most.
@@alexanderxin I'm sorry if my comment was too harsh. By all means use the coding style that you want. It's just that if I had to work in a codebase like this it would have been really difficult because I like more robust style:
- using a lot of blank lines to separate code into logical blocks
- using full names for variables (string instead of s or str and so on)
...
Still pretty insane that you made it so small
Can we call proxy as actor? Does it share similarity with message passing patterns like actors, microservices talking via pub-sub, processes talking using d-bus?
what if they made a compiler that turns react jsx into this? not sacrificing DX and getting maximum performance
I don't think that would be possible because van uses the signal reactivity and react uses rerender reactivity. This means that the react component function is executed every single time the state changes. While van component function is executed only once and then signals dictate what will change.
It is like trying to implement a method on a class that is executed a lot and turn it into a class constructor.
What could be done is to compile just plain old jsx into this approach. Oh wait that is exactly what solid js does.
@captsiro233 well explained!
tailwind, tailwind, tailwind
could you try to explain this again in more detail, maybe rewrite some of the functions to be more readable. it's very compressed code and hard to understand what the heck anything is doing. very very cool
Hey! Thanks for the suggestion. This is one of the main things I'll post in the near future - more hands on implementations of various aspects used in web frameworks. So, for certain, I'll revisit some of the Van's implementation in more detail.
cover dioxus! it has server functions now
Will do! Thank you for the suggestion!
what did you use to generate the code block and animate it?
Hey! This was made in Premiere Rush with some assets created in Photoshop and Illustrator.
nice job! the code block designs look awesome!@@awesome-coding
this lib is much like MithrillJs
Reefjs works similar
TwoMinutePapers?
I wish but sadly no 🥲
Vanjs is great but has some issues regarding reactive object and array. For that reason, I've created bau, it solves these issues and add functionalities such as lifecycle methods. Both projects move away from the angle bracket syntax. Readability and writability go to the moon.
Interesting - do you have a GitHub repo I can maybe check out?
Thanks!
After a while, all I see is bunch of colorful letters.
😅 you and me both
@@awesome-coding didn't you make the video tho?
@@kartikmadhak6327 I did, but it's always the same after revisiting the code after a couple of weeks - I have to focus and remember what I thought I understood in the past.
Bro created the Flutter of JS🤣I would do one thing differently, use tagged template literals instead.
Great a framework for making hello world and counter apps, exactly what no one asked for😂😂😂
Let's agree to disagree ✌️
Realistically, when would this ever be useful? I just can't think of a situation where I feel like other more prominent libraries are too bloated, and vanilla Javascript is not enough. Like honestly, JS is more than performant enough to handle working with proper frameworks without affecting perceived user performance dramatically at all. And if I was building something large enough for performance to become a concern, I wouldn't go for this solution either because of the many drawbacks.
If I want reactive components, I'll personally use React - but there are lots of other alternatives that all work fine and have more sophisticated features - and the build step is such a small burden that comes with so many pros that I'm not sure how much that weights in on my consideration.
You just learned this framework in 7 minutes. React takes years to learn, and then the framework changes and you need years to re-learn. So that could be a reason.
Or the direction these huge frameworks are taking (going fullstack) might not be what you want to do.
I think that the market for these frameworks exists as a "I wanted to do it vanilla and remembered mid development that maybe React is not useless"
It's a good library to pair with HTMX.
basically, any simple personal project + exploration of different takes on a single problem
or if you don't want any build step and just make the file run in browser
Great video but can you stop ending every sentence on a higher pitch! 😂
I'm really trying to make it better 😅
Serious question. Why on earth would anyone use this?
Regardless, I still believe it is an interesting case study.
@@awesome-coding the project has over 2.2k stars on github, I guess there are people looking for something like this
Basically, any simple personal project + exploration of different takes on a single problem
Not everyone enjoys compiling ts or tsx.
Also, it uses solidjs's signals reactivity which is more performant because you don't need to go through the whole tree and check for updates
@@captsiro233 People make it sound like they compile TS/TSX by hand 😂.
Signals are one small part of what makes a framework usable. Heck the most popular JS framework doesn't even use signals 🤷♂
@@boomshakalaka656 1) A few times I have found myself most of the time just waiting to recompile and then test the output. So it was really nice to just use JS make a change, save, and imidietly see the difference.
Talking about 3D rendering, it is a stretch, but when I was debugging 3D projection I would loose my mind to recompile on every single little change like changing -2 to -3 or 10 to -10
2) Signals are better DX for me. It is better abstraction of reactivity for me. I think of reactivity like this:
You press a button which triggers like event and then little pieces of the UI change because they are directly connected to the button.
Like I said. It is better abstraction for me. Plus I like to do a little bit more computation heavy and highly reactive application and there the little gain of using signals can be felt. (Although at that point I would not probably use a framework and stick to vanilla JS)