Angular, via its modules has had the ability to load "modules" as needed, and ember has lazy-loading engines. You don't need entry points when you can separate your app into "microservices". Sites using HTTP/2 or above don't need to re-negotiate a connection, and caching works better when we have more files, not less. As in 51:44, the problem of "hoisting" is a problem central to JSX and trying to mix up HTML and Javascript; they do not belong together, and that's why frameworks like angular and ember separate concerns. From a classic MVC perspective, keeping the template as simple as possible through declaring separate event handlers in controller/component files assures that you don't have any logic in templates and allows fetching modules as needed. I appreciate that Qwik shows that we don't need to load all scripts upfront, but this ultimately comes down to user experience; I think some upfront loading of assets will be desired in most cases, as has been exemplified by additions to the HTML spec like preload (for styles). Thankfully, ESM modules and the rise of vite allow us to customize any solution, but qwik doesn't necessarily need to play a part in that transition other than to educate people that parsing scripts can be costly, especially on mobile devices, and we don't have to eat our cake all at once; instead, we can have our cake and eat it too, but come back for seconds when we are hungry again.
This was a great session! I learned a ton and both of you are very easy to listen to and follow along with. I love the idea of pausing and resuming a session on devices (although I tense up a little at the potential security implications 😬). Amazing stuff, can't wait to see more and more of this especially now that they're officially in beta since a few days ago
The security implications are no different from existing systems. At the end of the day it is your code executing on the server/client. The only thing which Qwik brings in is that the code does not have to be downloaded all at once.
WOW, I was not aware of micromorph/spa package. Very cool, my brain is racing about how we could use it. For routing, what is needed is to deliver ports of the page. This gets more complicated because one has to transfer the state of the route as well. So what is needed is a way to break the state into different parts of the page, and treat each part as a separate app. We call these containers. So Astro can do diffing because it is only HTML, Qwik the problem is harder because it is not just HTML but also the state of that pace section.
ok so, this is nice, i like this, seems like it has more power than astro, can't wait for it to get a more stable release, i tried out different templates the one with partytown failed, i think i have node 16+, don't remember right now. but anyway, qwik is an interesting tool i will follow. thanks json!
What happens if you deploy a new version of your application while someone is connected to one of these pages? If the HTML holds references to component paths, wouldn't the entire page break?
I would love a full tutorial on qwik. I'm a new junior dev just learnt React. I like what Qwik proposes but need proper tutorials. When I can find some, I will most definitely start using it. I have watched nearly all on the website and I still couldn't get it.
Is the state only stored in the browser or does the server save the user states somewhere.. db.. memory.. Does any of this resumability help with state / session issues and scaleable serverless technologies?
Excelent question. You should think of Qwik/Qwikcity in the same way you think about tradition frameworks/meta-frameworks in its capabilities. The different being the resumabality. Similar to existing technologies it is up to developer to create backend starage solution, it is not automatic. Qwikcity does have facilities to move data between client/server, but in the end it is up to the developer to store it.
I know basic HTML, CSS and JavaScript. I want to learn Framework. Is Qwik worth learning? What would be salary range of Qwik developers? Does it remains for long term?
If you're looking for a framework to learn in order to get a job, Qwik is probably not going to get you there (at least at the moment). It's very new and the job market is going to be extremely limited. As a frontend developer, you might want to look into React(NextJS) / Angular / Vue. Not to say Qwik isn't worth learning, but if your short-term goal is to land a job I wouldn't start there.
not yet, just learn react for now, because qwik and react almost feel same while u code, so learn react first so that u don't waste any time on a framework that is not adopted by industry ,
First of all: Good job on starting with HTML, CSS and Javascript instead of instantly jumping into Frameworks. If you want to learn something really useful, stick with vanilla Javascript for a while, maybe switch to Typescript (which is essentially an enhanced version of JavaScript with strong typing) and try things like asynchronous operations in vanilla JavaScript. Try to build an app entirely with vanilla tools before you switch to any framework. It will be painful, but you will learn so much. You'll get a deeper understanding for the technology which will help you in the long term, regardless of the framework you might use. And then you can start digging into frameworks. React is still the obvious choice because of job security (because it's so popular) but because of your general knowledge, you can branch out to other frameworks at any time.
Amazing session. This is the first video about Qwik that got me to finally understand it. I appreciate how Jason interacted with Misko on this.
Angular, via its modules has had the ability to load "modules" as needed, and ember has lazy-loading engines. You don't need entry points when you can separate your app into "microservices". Sites using HTTP/2 or above don't need to re-negotiate a connection, and caching works better when we have more files, not less. As in 51:44, the problem of "hoisting" is a problem central to JSX and trying to mix up HTML and Javascript; they do not belong together, and that's why frameworks like angular and ember separate concerns. From a classic MVC perspective, keeping the template as simple as possible through declaring separate event handlers in controller/component files assures that you don't have any logic in templates and allows fetching modules as needed. I appreciate that Qwik shows that we don't need to load all scripts upfront, but this ultimately comes down to user experience; I think some upfront loading of assets will be desired in most cases, as has been exemplified by additions to the HTML spec like preload (for styles). Thankfully, ESM modules and the rise of vite allow us to customize any solution, but qwik doesn't necessarily need to play a part in that transition other than to educate people that parsing scripts can be costly, especially on mobile devices, and we don't have to eat our cake all at once; instead, we can have our cake and eat it too, but come back for seconds when we are hungry again.
This was a great session! I learned a ton and both of you are very easy to listen to and follow along with. I love the idea of pausing and resuming a session on devices (although I tense up a little at the potential security implications 😬).
Amazing stuff, can't wait to see more and more of this especially now that they're officially in beta since a few days ago
The security implications are no different from existing systems. At the end of the day it is your code executing on the server/client. The only thing which Qwik brings in is that the code does not have to be downloaded all at once.
1:25:55 Misko, what if you would use the micromorph/spa like astro does?
WOW, I was not aware of micromorph/spa package. Very cool, my brain is racing about how we could use it.
For routing, what is needed is to deliver ports of the page. This gets more complicated because one has to transfer the state of the route as well. So what is needed is a way to break the state into different parts of the page, and treat each part as a separate app. We call these containers. So Astro can do diffing because it is only HTML, Qwik the problem is harder because it is not just HTML but also the state of that pace section.
Man, I love you channel! Thanks you!
Thank you too!
Excellent session. Thanks.
ok so, this is nice, i like this, seems like it has more power than astro, can't wait for it to get a more stable release, i tried out different templates the one with partytown failed, i think i have node 16+, don't remember right now. but anyway, qwik is an interesting tool i will follow. thanks json!
Yes, we are revamping the templates and working on REPL to make the starting even easier. Stay tuned!
What happens if you deploy a new version of your application while someone is connected to one of these pages? If the HTML holds references to component paths, wouldn't the entire page break?
Same thing as would happen with current technologies.
But all code is stare with hashes so updating it is straight forward.
yay misko!!
I would love a full tutorial on qwik. I'm a new junior dev just learnt React. I like what Qwik proposes but need proper tutorials. When I can find some, I will most definitely start using it. I have watched nearly all on the website and I still couldn't get it.
hey carlos, have you found any useful tutorial along the journey. I
Is the state only stored in the browser or does the server save the user states somewhere.. db.. memory..
Does any of this resumability help with state / session issues and scaleable serverless technologies?
Excelent question. You should think of Qwik/Qwikcity in the same way you think about tradition frameworks/meta-frameworks in its capabilities. The different being the resumabality. Similar to existing technologies it is up to developer to create backend starage solution, it is not automatic. Qwikcity does have facilities to move data between client/server, but in the end it is up to the developer to store it.
craaaaaaazy so nice
How do we submit a form in qwik as apparently e.preventDefault() doesn't work
Amazing 😃😃😃
I know basic HTML, CSS and JavaScript. I want to learn Framework. Is Qwik worth learning? What would be salary range of Qwik developers? Does it remains for long term?
It might be too early to start with qwik. I don't think there is any job market out there yet. Stick with React or Vue as your first framework.
If you're looking for a framework to learn in order to get a job, Qwik is probably not going to get you there (at least at the moment). It's very new and the job market is going to be extremely limited. As a frontend developer, you might want to look into React(NextJS) / Angular / Vue.
Not to say Qwik isn't worth learning, but if your short-term goal is to land a job I wouldn't start there.
not yet, just learn react for now, because qwik and react almost feel same while u code, so learn react first so that u don't waste any time on a framework that is not adopted by industry ,
First of all: Good job on starting with HTML, CSS and Javascript instead of instantly jumping into Frameworks. If you want to learn something really useful, stick with vanilla Javascript for a while, maybe switch to Typescript (which is essentially an enhanced version of JavaScript with strong typing) and try things like asynchronous operations in vanilla JavaScript. Try to build an app entirely with vanilla tools before you switch to any framework. It will be painful, but you will learn so much.
You'll get a deeper understanding for the technology which will help you in the long term, regardless of the framework you might use.
And then you can start digging into frameworks. React is still the obvious choice because of job security (because it's so popular) but because of your general knowledge, you can branch out to other frameworks at any time.
it seems like qwik is a real deal.