I feel Theo didn't understood the "Sites should work without JS" take, it's not about making the web fully functional without javascript, is about getting a good enough experience when it is not available, and frameworks should enable devs to do that.
Basically progressive enhancement should be a focus for modern JS frameworks. I think not a whole lot of people use this way of building sites because it requires extra research and work, plus everything else that needs to be accounted for (i18n, responsivity, business reqs). Would be neat to have a curated list of good practices in one place for easy reference until some support trickles in from framework builders.
I built HTMF, similar to HTMX but with forms first so it makes it easy to build progressively enhanced websites with minimal JS on the front end. It can be even offline completely and a site that works with no JS. Forms for the win!
I think most of Theo's disagreements are misguided. The talk is presented from the point of view of a tool maker. Rich is not saying that developers should carry the burden, instead, the frameworks and tooling should do the heavy lifting.
Incredible that people complain about Svelte’s DSL and they completely forget that JSX is also DSL. And they hated it at the beginning too. Svelte is just awesome and people should use it more :)
"Most sites should work without JavaScript" is something I agree strongly with. I think "most" does some heavy lifting here, because even if most what Theo does can't work without client-side JavaScript, most of what is deployed on the web *can*. Even if I don't disable JS, I have to deal with the consequences of the JS requirement regularly. The number of times in the past month that broken JS has made a site inaccessible without me having to do DOM manipulation or patch the broken script isn't high, but it's ridiculous that it's more than twice. 18:50 Rich isn't saying we should get rid of JS, he's saying removing the JS shouldn't break everything. 14:10 I think Rich's message is basically "we should ensure that people *don't* have to work with datetime themselves"
Yes, I don't like TailWind, and I don't like React. This is not because I think I'm a CSS genius. It's because I'm old enough to remember . We've lost sight of why CSS was created: that styling in markup is convenient but inflexible. In addition, React has no CSS styling isolation between components. There was bleed through. TailWind absolutely helped with that. But once you're not using React, using a framework that scopes CSS to the component (like Svelte does), that need for TailWind to solve that problem evaporates along with the problem. If TailWind were a Sass mixin or used CSS variables like Open Props, I'd have no problem with it. It's not the idea of TailWind-collections of related, pre-made, consistent styles-that bothers me. The implementation when viewed through the lens of React's scoping deficiencies even raises it to truly exceptional engineering. I accept good engineering overcoming bad decisions, but I struggle with accepting the bad decisions as part of good engineering. (And I fully acknowledge that they were not objectively bad decisions a decade ago. 20/20 hindsight and all that.)
Just a note, I see a common theme here he makes an opinion and you immediately decide to agree or disagree. I feel it's generally better to let someone state their position before we decide on which side of the argument we fall.
I love this because you can see both Svelte and RSC approach hand in hand. I'd love to see a Rich's react video to Theo talking about RSC to have the complete circle
When I add an item to my cart I should be able to see it done immediately. Bunk for SPAs. Most SPAs go all the way to the back end to update the data. He's arguing for offline first capability. SPAs don't necessarily achieve this.
Bro, these hot takes are just, awesome! I've felt these things many times, just wasn't able to figure out what was actually wrong, rich harris is just awesome.
A thoughtful response to Rich's thoughtful talk! Thanks for sharing this. 26:51 - "React's whole thing is it's just JavaScript." React folks often say this. This isn't true about any front-end framework, but it means React (and others) are so good that they *feel* like just JavaScript. Most obviously, JSX is widely used and is objectively not JavaScript. It's not in the standard or in any JS implementation. (Linters like TypeScript support it for obvious reasons.) Solid, Vue, React, Svelte, etc. also all need compilers for their abstractions to work and add hidden control flow to do many things such as automatically re-rendering your components when data changes. (Full-stack frameworks are a whole other can of worms that you and Rich already opened in your respective videos. lol) There's a lot more, but this comment is long enough. 42:08 - You *do* have to call signals on props as a function. The code on the slide would only work if those components were passed the return value of the signal
The problem is that React devs don't say, "it feels like its just js", they say "it's just JS", I think the former statement is more acceptable and should be what they say rather.
Calling React "just javascript" is quite the stretch in my opinion. I know React but I put it off many times because of all the extra syntax and rules. The most obvious being the "useState" hook instead of creating and mutating a variable.
Has CSS ever been the problem when it comes to performance? Tailwind or not is a matter of DX taste imo - personally I prefer styled components or even just css modules - anything that will let you write actual css
I feel Tailwind mostly solves issues people had with styled components, which again solved issues people had with global css that again was already solved with css modules. I have never heard any arguments of either styled components or tailwind that css modules dont already solve. The only thing Tailwind has going for it is a good set of default design tokens. But why not just copy those and use them in vanilla css and css modules?
I'm not anti react. It's cool. But I am a svelte lover and oh man, I can still admire react, but I won't touch it if I don't have to now that I know how simple, elegant, and concise web development can be.
I have used a JavaScript blocker for the last 10 years, it works on a white list. From my experience most sites do work without any JavaScript, but it feels like 90s internet. Unless it's super important, I won't even bother with sites that don't load without allowing off-site JavaScript.
i don't think sveltekit users are typically all that aware of performance. svelte was always targeted to casual programmers to an extent; it started as a tool for data visualization professionals to build widgets fast without having to learn much on top of basic javascript.
now I require that rant on the datetime video. I've been working on and maintaing an event timers site for a videogame for almost 4 years now and there are so many nasty pitfalls to step in; I'd love to hear more people their takes on this stuff.
Given your take on how Svelte made = "magical" I'm assuming you approve of the reactivity changes coming in Svelte 5? Just curious, I'm in favor of it as it makes it more explicit but still easy to work with.
I actually feel you on the laptop with big font. I have my choice of Dual screen, iMac, and Macbook, at the beginning of this year I switched back to my laptop, increased the font size, and have noticed less eye fatigue and back issues. Now I only use the other computers when I am testing, or gaming. And then youtube is usually running on my phone. Its gone full circle I started on a MBP and will likely retire on a MBP.
If you lose connectivity your app without javascript won't work either. Without js you need a roundtrip to the server, so if you have connectivity you can get js in the first place.
Navigating the client server divide is the next frontier, eh? My take is be selective about what needs the server at all, but when you do go to the server, make it do most of the work. What this means is, if you don’t need to persist state, stay in the client. If you do, make the server do all the validation and get your response in hypermedia form, ready to just display somewhere on the page. All this to say, htmx and hateoas is the answer. One bit of nuance to generalize a bit better: The computation location should depend on the lifetime of the state. If it’s ephemeral, do it in the client. If it’s shared between a only few users (e.g. Google docs editing), do it on an edge machine close to them. If it’s forever, do it on the main server(s), or even a big distributed back end.
I thought a date picker would be a simple component I could make months back as a newbie. Hell no. I learned to just accept that little ugly module size for not dealing with that much head ache vs. just get it picking and working. When people make their own I instantly start breaking it by going back to pre Gregorian when FUN FACT the pope basically became the first mass time traveler fast forwarding us 10 days. Then you go forward and the date is wrong haha.
I do live coding and I do like having less stuff on the screen, but I'm never giving up all my monitors. I use a 4K monitor for my living coding and I zoom in to 1/4 of the screen so you still get a 1080p stream, so I have the huge fonts in OBS, but I make the Explorer 1/2 of the screen, and the console is 1/4 and code with is 1/4, both on the right-hand side. I have an ultra-wide monitor that I use for OBS and I can add an extra browser window. I use also a dedicated 13.3" 1080p monitor for an extra desktop. This allows me to quickly switch between the browser that the live-stream viewers can seek I also have one more 13.3" 1080p monitor that is for utility. I just use them for quick reference, or I'll have a tutorial video on them. I've got a badass RPC library called Script2 that is a baller and better than tRPC. You have to have RPCs to do most multi-threaded applications. HTTP is essentially a RPC protocol, so is GraphQL.
I just don't think Javascript is evil. Maybe we need better ways to bundle/load/etc and even then things have come along so far. The argument "ever tried to use an app on the subway when connection drops and your JS didn't load?" Ok, you have no connection. You won't be making new calendar appointments either. Remember the PWA idea? Were the site/app you use is cached so when you go to use your app it works offline first? We have chased the goal of "first paint" and "time to interactive" on the very first user at the expense of the tooling around repeat users. Maybe you are a news site, that first visitor is more important. Or you have a calendar app, I'd lean into the repeat user experience.
No, React websites do suck. Yes, some websites need React because of a lot of state. But most don't. .NET Rocks website started using React and the user experience went way down. The thing is most websites a static page with a little interactivity is OK. Other websites something like HTMX works fine.Others, that need a lot of interactivity on the front end, React could be a smart choice. Yes, ads on web pages suck too and can overshadow the problem of SPAs for sites that don't need SPAs.
@@upsxace react websites suck because most of the websites do not have the property of "interactivity everywhere" to justify the use of react. react as a framework doesn't suck, the product "react website" does.
Archiving pages could be improved anyway - stuff could be loaded with a headless browser, and converted to images even... I do like this idea of being able to save the history of the web.
@ This is bad equivocation, some of those companies blatantly abuse open source for their own benefit. You really don’t have to look that far to find some stories. Also, we are talking about developers first, not companies. Most devs who do open source do it for free, where is ‘lucrative’ part in that?
you look up to him. which you took the humble nature with you as well. I am very disappointed by the egotistic opinions of unit tests and code-splitting. Those weren't your humble opinions were they. they were facts.
I have a different take on what could be a major improvement on the web experience for everyone and that is for developers to clean up the garbage they casually throw on the floor with links to docs and demos. We all click through dozens of dead links every day. Not only is it frustrating it also is a big waste of productive time and bandwidth. Add it all up in aggregate and I bet the numbers there are staggering.
my hot take for the editing is that I use neovim + tmux and I code on my laptop. my screen looks like tiny little beehive. i opened so many "windows" in one tab it is insane, plus with the split of tmux I have code running on the side. And this is all cramped on a small laptop screen. you think i'm joking but that's how I code.
29:42 I find the whole "it's just JS" thing funny... JSX is not just JS. It is under the hood, but it isn't in the sense that something needs to convert it to JS. React likes to claim it's just JS yet I rarely have seen react code without JSX. And JSX exists in JSX files and TSX files. Theo... how can you possibly dislike .svelte for the same crime that you experience in a .[jt]sx world?
what is up with the move-fast & break-stuff mentality of people in tech. they're behaving like the tech they're producing which clears the table every time you move a step forward.
Svelte didn't drop typescript, they are still using typescript tooling, just not writing it in "typescript". The consumers of the framework will be unaffected
@@matthewcole4521 That's the point TS is supposed to be for big projects like the Svelte code base. I've done some ActionScript and that was OK, I think I'll just wait out for type comments in JS. Then you can get type checking on the side and not have to hack around JS
In the Solid example, the reason you don't call count as a function is that props is always a reactive object so accessing the count property is the same as calling a signal accessor function. The solution is that doubleCount needs to be a function, which I think makes more sense _unless_ you're React brained. Especially once you're signal-brained, the concept that all dynamically updating state should be wrapped within a function is actually super sensible. I recently converted a React library to be a Solid library and all that it took was identifying each piece of unique input state and requiring that it be a signal accessor and that any subsequently calculated values just became functions rather than values. After that it was just convertilng useEffect to createEffect and getting rid of the now unnecessary dependency arrays. I think it's really dumb that this example got included with "implicit DSLs" and it's a sign of major React-🧠 which is surprising to see from Rich.
When JS will become a real compiled language or be replaced by a real compiled language (and TS is not one), the web will be 5x more secure than it is now. Really hoping WASM is going to become that.
I don't know that I agree with making things better for humans will make it better for AI. That's an unfounded assumption based on the idea that the human mind is the model for all intelligence, but that is almost certainly untrue.
Vercel makes money by selling you servers. Of COURSE they will push into RSC. Otherwise they are just wrapping cloudflare CDN at almost no profit. We really want to do a round trip load on every page? Of course that experience is going to suck on mobile. I've been developing for too long, because I remember BEFORE we had components, PWA, SPA, and all this stuff we created to mitigate the issues. This doesn't even get into the API first and the value of having a robust API layer for future development. We don't need another PHP hellscape experience where back end logic is monolithic and tightly coupled with the web views.
Coding on a laptop is underrated (unless you're using Windows/Linux) and using the IDE terminal aligned to the right instead of on the bottom or something in the background in underrated My IDE looks like this [files|code|git] [files|code|cli] [files|code|cli] And I've never been as productive and I'm using a small 14inch laptop with a trackpad
No idea what you mean by the "windows/linux" thing. Been coding on a linux laptop for like 4 years now and been loving every second of it (well, maybe not every second but tou get the point)
I think it's never do date math unless you absolutetly need to. Date strings never fail. Harris thinks JS is the reason sites fail to archive/maintain old site versions. 404 has been with the web from the start, dear. If anything, JS ca save you, if you wish. DSLs get a bad rap - said Rich Harris and....
React was great, until it wasn't. Somehow I get bored listening to Rich. And also, he has a point that more sites should work w/o js, I agree with that. But. Even SvelteKit static pages rendered on server have NO HTML BODY WHATSOEVER. Nuxt server rendered files have full body. Hmmmmmm....
I feel Theo didn't understood the "Sites should work without JS" take, it's not about making the web fully functional without javascript, is about getting a good enough experience when it is not available, and frameworks should enable devs to do that.
Yeah, as an example, your calendar could just show just a list of your daily appointments when JS isn't available.
Basically progressive enhancement should be a focus for modern JS frameworks. I think not a whole lot of people use this way of building sites because it requires extra research and work, plus everything else that needs to be accounted for (i18n, responsivity, business reqs). Would be neat to have a curated list of good practices in one place for easy reference until some support trickles in from framework builders.
"Graceful degradation" is something I've heard people used before. Now that SPA has become so pervasive, the idea kinda got shoved away.
I built HTMF, similar to HTMX but with forms first so it makes it easy to build progressively enhanced websites with minimal JS on the front end. It can be even offline completely and a site that works with no JS. Forms for the win!
Not sure it's as worth it today as it once was. Plus, you can just cache the javascript...
I think most of Theo's disagreements are misguided. The talk is presented from the point of view of a tool maker. Rich is not saying that developers should carry the burden, instead, the frameworks and tooling should do the heavy lifting.
Exactly, datetime stuff suck, because cause the browser or tooling isn't doing it for me as it should.
He's a very misguided boy. "I was wrong about everything" will be on his gravestone.
I agree. This is a reaction video though, so Theo's responses are parboiled at best
@@theLowestPointInMyLife lmaoo
Incredible that people complain about Svelte’s DSL and they completely forget that JSX is also DSL. And they hated it at the beginning too. Svelte is just awesome and people should use it more :)
"I could rant for 2 hours about datetime stuff." - I felt this in my soul.
Haven't even started Theo's react video but even so, when I saw your comment.... motherfrakkin' datetimes man, them and proper unicode handling.
@@nathanreyes the temporal API can only do so much, our weird ass calendar we came up with, timezone and daylight savings are still a thing.
Such a well needed talk! Rich has the ear of the industry and for a good reason.
"Most sites should work without JavaScript" is something I agree strongly with. I think "most" does some heavy lifting here, because even if most what Theo does can't work without client-side JavaScript, most of what is deployed on the web *can*. Even if I don't disable JS, I have to deal with the consequences of the JS requirement regularly. The number of times in the past month that broken JS has made a site inaccessible without me having to do DOM manipulation or patch the broken script isn't high, but it's ridiculous that it's more than twice.
18:50 Rich isn't saying we should get rid of JS, he's saying removing the JS shouldn't break everything.
14:10 I think Rich's message is basically "we should ensure that people *don't* have to work with datetime themselves"
Yes, I don't like TailWind, and I don't like React. This is not because I think I'm a CSS genius. It's because I'm old enough to remember . We've lost sight of why CSS was created: that styling in markup is convenient but inflexible. In addition, React has no CSS styling isolation between components. There was bleed through. TailWind absolutely helped with that. But once you're not using React, using a framework that scopes CSS to the component (like Svelte does), that need for TailWind to solve that problem evaporates along with the problem.
If TailWind were a Sass mixin or used CSS variables like Open Props, I'd have no problem with it. It's not the idea of TailWind-collections of related, pre-made, consistent styles-that bothers me. The implementation when viewed through the lens of React's scoping deficiencies even raises it to truly exceptional engineering.
I accept good engineering overcoming bad decisions, but I struggle with accepting the bad decisions as part of good engineering. (And I fully acknowledge that they were not objectively bad decisions a decade ago. 20/20 hindsight and all that.)
Just a note, I see a common theme here he makes an opinion and you immediately decide to agree or disagree. I feel it's generally better to let someone state their position before we decide on which side of the argument we fall.
I love this because you can see both Svelte and RSC approach hand in hand. I'd love to see a Rich's react video to Theo talking about RSC to have the complete circle
Date time picker that works without JS? Uhm:
44:42 as a regular Amtrak traveler who frequently works/codes on the train I feel this deep in my soul
When I add an item to my cart I should be able to see it done immediately. Bunk for SPAs. Most SPAs go all the way to the back end to update the data. He's arguing for offline first capability. SPAs don't necessarily achieve this.
We are so thankful to have an awesome journalist on the JS land.
13:07 had me dying! Love both Rich and Theo so much, I think this has become one of my favorite videos of your channel!
Bro, these hot takes are just, awesome! I've felt these things many times, just wasn't able to figure out what was actually wrong, rich harris is just awesome.
A thoughtful response to Rich's thoughtful talk! Thanks for sharing this.
26:51 - "React's whole thing is it's just JavaScript."
React folks often say this. This isn't true about any front-end framework, but it means React (and others) are so good that they *feel* like just JavaScript.
Most obviously, JSX is widely used and is objectively not JavaScript. It's not in the standard or in any JS implementation. (Linters like TypeScript support it for obvious reasons.)
Solid, Vue, React, Svelte, etc. also all need compilers for their abstractions to work and add hidden control flow to do many things such as automatically re-rendering your components when data changes.
(Full-stack frameworks are a whole other can of worms that you and Rich already opened in your respective videos. lol)
There's a lot more, but this comment is long enough.
42:08 - You *do* have to call signals on props as a function. The code on the slide would only work if those components were passed the return value of the signal
The problem is that React devs don't say, "it feels like its just js", they say "it's just JS", I think the former statement is more acceptable and should be what they say rather.
Calling React "just javascript" is quite the stretch in my opinion. I know React but I put it off many times because of all the extra syntax and rules. The most obvious being the "useState" hook instead of creating and mutating a variable.
listening to Rich is like listening to my consience, helps to keep my more wild developer tendencies in check and grounded. PS love the cat
Love this video. It helped me argue against using Qwik
Has CSS ever been the problem when it comes to performance? Tailwind or not is a matter of DX taste imo - personally I prefer styled components or even just css modules - anything that will let you write actual css
I use Tailwind with Styled Components using Twin.Macro -- never happier!
I feel Tailwind mostly solves issues people had with styled components, which again solved issues people had with global css that again was already solved with css modules. I have never heard any arguments of either styled components or tailwind that css modules dont already solve.
The only thing Tailwind has going for it is a good set of default design tokens. But why not just copy those and use them in vanilla css and css modules?
I'm part of the sliver of your Tailwind Venn that isn't complaining based on React performance. Tailwind sucks because it's not vanilla CSS.
A afluent dev guy talking against capitalism? I'M IN!
I'm not anti react. It's cool. But I am a svelte lover and oh man, I can still admire react, but I won't touch it if I don't have to now that I know how simple, elegant, and concise web development can be.
I have used a JavaScript blocker for the last 10 years, it works on a white list. From my experience most sites do work without any JavaScript, but it feels like 90s internet. Unless it's super important, I won't even bother with sites that don't load without allowing off-site JavaScript.
Just finished watching the full stream VOD, this one was really great! I felt like I learned a whole bunch this time around.
i don't think sveltekit users are typically all that aware of performance. svelte was always targeted to casual programmers to an extent; it started as a tool for data visualization professionals to build widgets fast without having to learn much on top of basic javascript.
During your vid you switched to what looks like a PM app to note an idea... What app is that?
now I require that rant on the datetime video. I've been working on and maintaing an event timers site for a videogame for almost 4 years now and there are so many nasty pitfalls to step in; I'd love to hear more people their takes on this stuff.
Given your take on how Svelte made = "magical" I'm assuming you approve of the reactivity changes coming in Svelte 5? Just curious, I'm in favor of it as it makes it more explicit but still easy to work with.
Yes, huge fan of Runes (I have a vid about it somewhere)
54:16 Rich axed Typescript to avoid a double build step for svelte library consumers. Svelte is still very invested in working in and with typescript.
Lol. I built the first browser-based calendar and it was sweet. Why would you put limits on what talented devs can do within limits?
I actually feel you on the laptop with big font. I have my choice of Dual screen, iMac, and Macbook, at the beginning of this year I switched back to my laptop, increased the font size, and have noticed less eye fatigue and back issues. Now I only use the other computers when I am testing, or gaming. And then youtube is usually running on my phone. Its gone full circle I started on a MBP and will likely retire on a MBP.
I wouldn’t hate instead of a separate file for server actions. I understand the trouble around source maps though
If you lose connectivity your app without javascript won't work either. Without js you need a roundtrip to the server, so if you have connectivity you can get js in the first place.
I should try Astro in the next time together with the new Page Transition APIs. They seem to be available in all browsers now , sooo...
The take on JS being event driven and ui is state driven is terrifying
Navigating the client server divide is the next frontier, eh? My take is be selective about what needs the server at all, but when you do go to the server, make it do most of the work. What this means is, if you don’t need to persist state, stay in the client. If you do, make the server do all the validation and get your response in hypermedia form, ready to just display somewhere on the page.
All this to say, htmx and hateoas is the answer.
One bit of nuance to generalize a bit better: The computation location should depend on the lifetime of the state. If it’s ephemeral, do it in the client. If it’s shared between a only few users (e.g. Google docs editing), do it on an edge machine close to them. If it’s forever, do it on the main server(s), or even a big distributed back end.
I thought a date picker would be a simple component I could make months back as a newbie. Hell no.
I learned to just accept that little ugly module size for not dealing with that much head ache vs. just get it picking and working.
When people make their own I instantly start breaking it by going back to pre Gregorian when FUN FACT the pope basically became the first mass time traveler fast forwarding us 10 days. Then you go forward and the date is wrong haha.
I do live coding and I do like having less stuff on the screen, but I'm never giving up all my monitors. I use a 4K monitor for my living coding and I zoom in to 1/4 of the screen so you still get a 1080p stream, so I have the huge fonts in OBS, but I make the Explorer 1/2 of the screen, and the console is 1/4 and code with is 1/4, both on the right-hand side. I have an ultra-wide monitor that I use for OBS and I can add an extra browser window. I use also a dedicated 13.3" 1080p monitor for an extra desktop. This allows me to quickly switch between the browser that the live-stream viewers can seek I also have one more 13.3" 1080p monitor that is for utility. I just use them for quick reference, or I'll have a tutorial video on them.
I've got a badass RPC library called Script2 that is a baller and better than tRPC. You have to have RPCs to do most multi-threaded applications. HTTP is essentially a RPC protocol, so is GraphQL.
I just don't think Javascript is evil. Maybe we need better ways to bundle/load/etc and even then things have come along so far.
The argument "ever tried to use an app on the subway when connection drops and your JS didn't load?"
Ok, you have no connection. You won't be making new calendar appointments either.
Remember the PWA idea? Were the site/app you use is cached so when you go to use your app it works offline first?
We have chased the goal of "first paint" and "time to interactive" on the very first user at the expense of the tooling around repeat users. Maybe you are a news site, that first visitor is more important. Or you have a calendar app, I'd lean into the repeat user experience.
No, React websites do suck. Yes, some websites need React because of a lot of state. But most don't. .NET Rocks website started using React and the user experience went way down. The thing is most websites a static page with a little interactivity is OK. Other websites something like HTMX works fine.Others, that need a lot of interactivity on the front end, React could be a smart choice.
Yes, ads on web pages suck too and can overshadow the problem of SPAs for sites that don't need SPAs.
Now explain why React websites suck?
@@upsxace react websites suck because most of the websites do not have the property of "interactivity everywhere" to justify the use of react. react as a framework doesn't suck, the product "react website" does.
This was a fun one, thanks!
16:25 “if we could go back to 2016 we might have some other priorities” 😅
imho react is just javascript as much as solid is just javascript
Archiving pages could be improved anyway - stuff could be loaded with a headless browser, and converted to images even... I do like this idea of being able to save the history of the web.
"The web sucks because of capitalism"
hmmm I see what you did there...
The web also moves forward because of capitalism 😂😂😂
@@ea_naseer Kkkkk sure... because open source, which is what moves the web forward, is suuuper lucrative...
@@commentercomentando78 open source is indeed lucrative. Companies wouldn't go open source unless they think it's a good way of making money.
@ This is bad equivocation, some of those companies blatantly abuse open source for their own benefit. You really don’t have to look that far to find some stories.
Also, we are talking about developers first, not companies. Most devs who do open source do it for free, where is ‘lucrative’ part in that?
@@ea_naseer imagine actually believing this lmao
Angular and Lambdas. I swear you will like Angular if you give it a try. Specially the dependency injection and RxJS.
About the liminal spaces: the moment you change the j for t or add x at the end of js you're no longer on pure js™ realm
why this sceptical look at 19:45?
Rich is literally Web Jesus.
framework wars hidden behind a presentation. His point is just his framework is better than others.
50:47 oof big SQL injection vibes
Feels like the "sites should work without Javascript" is more a point in favor of caching files.
Please link original video -_-
ruclips.net/video/uXCipjbcQfM/видео.html
KPOP MV reaction ❌
JS Framework Demo reaction ✔️
I was young and needed the JS :P
you look up to him. which you took the humble nature with you as well. I am very disappointed by the egotistic opinions of unit tests and code-splitting. Those weren't your humble opinions were they. they were facts.
about metrics i have to be true, man. 2/3 of the times i come to this channel is because of something i saw on primeagen, even though i'm a subscriber
I have a different take on what could be a major improvement on the web experience for everyone and that is for developers to clean up the garbage they casually throw on the floor with links to docs and demos. We all click through dozens of dead links every day. Not only is it frustrating it also is a big waste of productive time and bandwidth. Add it all up in aggregate and I bet the numbers there are staggering.
pre-fetching resources because someone might click through to that link is bad practice. Fight me.
my hot take for the editing is that I use neovim + tmux and I code on my laptop. my screen looks like tiny little beehive. i opened so many "windows" in one tab it is insane, plus with the split of tmux I have code running on the side. And this is all cramped on a small laptop screen. you think i'm joking but that's how I code.
Sveltekit/Svelte is No.1 frameworks, better than No.2 Next/React 😍🤩🥰😀😎👍😉😘
How about No 😀😃🥰😍🤪😜
I don't understand all what's said in this video 😂😭
I had to watch it 2x lol
29:42 I find the whole "it's just JS" thing funny... JSX is not just JS. It is under the hood, but it isn't in the sense that something needs to convert it to JS. React likes to claim it's just JS yet I rarely have seen react code without JSX. And JSX exists in JSX files and TSX files. Theo... how can you possibly dislike .svelte for the same crime that you experience in a .[jt]sx world?
Yes, SPA docs feel better to use
Really? Date picker is your reason for not making a jsless calendar? lol
One of the few things I vehemently disagree with Theo on is that tall files are better. Rich pretty much spelled out the way I think about it here.
Funny thing is: single file components are taller files :P
@@danvilela They aren't when you do what Theo does and stack 5 related components in the same file.
what is up with the move-fast & break-stuff mentality of people in tech.
they're behaving like the tech they're producing which clears the table every time you move a step forward.
Rich >>>
Rich’s attitude towards the businesses that keep us all employed is a hot take
That’s a big ass kitten
The more I learn details about React the more I dislike it
@3:44 *cough* Alex Russell *cough*
I absolutely love your content. AI !=== Robot tho. Nonetheless those who embrace AI will not be the first overwhelmed by it.
Thanks for the videos!
i dont think theo get what his saying
😆 "Typescript won" ???.... Svelte have just dropped TS and moved back to JS with JSDoc...😆
Svelte didn't drop typescript, they are still using typescript tooling, just not writing it in "typescript". The consumers of the framework will be unaffected
@@matthewcole4521 That's the point TS is supposed to be for big projects like the Svelte code base. I've done some ActionScript and that was OK, I think I'll just wait out for type comments in JS. Then you can get type checking on the side and not have to hack around JS
The greatest Tom Scott video of all time that was also referenced by theo: ruclips.net/video/-5wpm-gesOY/видео.html
that cat was awesome
Theo is a rookie that thinks he is smart. Rich Harris is solid!!
Ackshually, Rich Harris is Svelte. 🤓
Bring back geocities 🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉
In the Solid example, the reason you don't call count as a function is that props is always a reactive object so accessing the count property is the same as calling a signal accessor function.
The solution is that doubleCount needs to be a function, which I think makes more sense _unless_ you're React brained. Especially once you're signal-brained, the concept that all dynamically updating state should be wrapped within a function is actually super sensible. I recently converted a React library to be a Solid library and all that it took was identifying each piece of unique input state and requiring that it be a signal accessor and that any subsequently calculated values just became functions rather than values. After that it was just convertilng useEffect to createEffect and getting rid of the now unnecessary dependency arrays.
I think it's really dumb that this example got included with "implicit DSLs" and it's a sign of major React-🧠 which is surprising to see from Rich.
1 like for video + 1 like for kitty = 1 like bc RUclips logic 🤷♂️
When JS will become a real compiled language or be replaced by a real compiled language (and TS is not one), the web will be 5x more secure than it is now. Really hoping WASM is going to become that.
I don't know that I agree with making things better for humans will make it better for AI. That's an unfounded assumption based on the idea that the human mind is the model for all intelligence, but that is almost certainly untrue.
13:40
Talking about this computerphile video „the problem with time & timezones“? ruclips.net/video/-5wpm-gesOY/видео.html
Whats up with mustache
I think you are a lot too much into it. foldsss
Vercel makes money by selling you servers. Of COURSE they will push into RSC. Otherwise they are just wrapping cloudflare CDN at almost no profit.
We really want to do a round trip load on every page? Of course that experience is going to suck on mobile. I've been developing for too long, because I remember BEFORE we had components, PWA, SPA, and all this stuff we created to mitigate the issues.
This doesn't even get into the API first and the value of having a robust API layer for future development. We don't need another PHP hellscape experience where back end logic is monolithic and tightly coupled with the web views.
lol muh capitalism, no the web sucks because of gov intervention, limited space and too many squatters
Thio should switch to svelte belive me 😅😅
tz nightmare
Coding on a laptop is underrated (unless you're using Windows/Linux) and using the IDE terminal aligned to the right instead of on the bottom or something in the background in underrated
My IDE looks like this
[files|code|git]
[files|code|cli]
[files|code|cli]
And I've never been as productive and I'm using a small 14inch laptop with a trackpad
No idea what you mean by the "windows/linux" thing. Been coding on a linux laptop for like 4 years now and been loving every second of it (well, maybe not every second but tou get the point)
I think it's never do date math unless you absolutetly need to. Date strings never fail.
Harris thinks JS is the reason sites fail to archive/maintain old site versions. 404 has been with the web from the start, dear. If anything, JS ca save you, if you wish.
DSLs get a bad rap - said Rich Harris and....
I need more cat breaks in my videos!
React was great, until it wasn't. Somehow I get bored listening to Rich. And also, he has a point that more sites should work w/o js, I agree with that. But. Even SvelteKit static pages rendered on server have NO HTML BODY WHATSOEVER. Nuxt server rendered files have full body. Hmmmmmm....
What? Sveltekit static prerendered pages have all their HTML. You'd have to specifically toggle the configuration for there to be no body