Shadowing Practice: DejaVue #E001 - The Need for Server-Side Rendering (SSR) - Learn English Speaking with Video

בחר מצב תרגול

כל מצב פותח חדר תרגול במסך מלא.

466 משפטים

אם המשפטים קצרים או ארוכים מדי, לחץ על ערוך כדי להתאים אותם.

Welcome to Deja View, your favorite view podcast.

You just don't know it yet.

And here with me on the microphone is Michael.

I am a full -time view educator and produce lots of content,

newsletters, things like that, including this podcast, which I record with Alex.

Exactly.

And I'm part of the Next Core team.

I'm also creating quite some content on YouTube stream every now and then Twitch.

And I am a web engineering consultant by day.

And today we talk about a topic that might be interesting for most of you, which is server -side rendering.

What is it?

Do you need it?

Why would you use it?

And what are all these other weird acronyms in that space?

Yeah, so let's start with what is server -side rendering to begin with? just

so that we can start off on the same page.

And some of you may not know what it is or the exact specifics.

So what would your definition of server -side rendering be?

Well, I mean, we could go all the way back and say, oh yeah, my old PHP application is server -side rendered because,

oh, there's a PHP server and it renders the HTML.

But if we are in the JavaScript ecosystem and if we talk about single -page applications,

then server set rendering means rendering your single page application on the server, mostly a node server, on the initial request.

That's very important.

So only if you like hard reload the page or if you click from an external source,

like from Google, then your site will be server rendered.

And ideally afterwards, it will just behave as a plain old single page application as before.

Yeah, it's interesting to think about historically that websites have almost always been server -side rendered.

Like if you go back to the 90s, we had JavaScript back then,

but we weren't really building single page apps that just lived in the browser.

We were always hitting the server with every single request, button click, that kind of a thing.

Yeah, absolutely.

I mean, then Ajax came and said like, hey, JavaScript can do a bit more here and there.

But we're still, in a way, we're still torn of like, oh yeah, the server still renders things and we can load more.

And there was XML and then finally some good thing like JSON so we can send data.

And yeah, eventually SPAs were born by saying, why can't we do all of the things in the browser

and front end and like use the backend more as an API?

Yeah.

And this pendulum almost swings back and forth,

it seems between single page apps are the hottest thing.

And then, no, they're terrible for performance.

They've got all these issues.

Let's render everything on the server.

And then, you know, after a couple of years, people are like wait but we can do

so much more with single page apps

so let's you know the the pendulum swings back the other direction

and it almost seems like a bit of uh whiplash

we've gotten in the web development community here yeah it's true

but i think we can't do without both like ideally in the future we have something where the server

and the client they work together hand in hand you embrace the web standards

and i like to see some moves for example what remix is doing with like, okay, we basically have a single page application,

but we progressively enhance it.

Even without JavaScript, you can still send forms.

So that's super interesting to see.

And also what

React is doing with server components and what Nux server components are doing to say,

like we reduce the amount of JavaScript we need to render some stuff.

And from there, we can improve performance -wise, but also still keep the same mental model of the same framework, not the same code we write.

And I like what Nuxt does with the hybrid approach where we try

and take the best of both worlds of server -side rendering and single -page apps and basically stay right in the middle.

I mean, you could argue if it's leaning one direction or the other, but where we use server -side rendering on that first request,

and then after that, we can bootstrap into a single page app and get the benefits there.

So I think that's a pretty neat way to sort of blend the two.

But yeah, what are your thoughts on that?

I also think it's really helpful, but of course introduces some more problems.

Let's say you have more complexity because you always have to think, oh, what if this is rendered on the server?

For me, like I remember back in 2017, maybe 2018, something like that, must be 17, when I first got in touch with Nuxt,

I was like, okay, service -led rendering, super helpful because back then I had a project with public facing.

And as we all know, single -page applications, well, they don't run out HTML straight away.

The JavaScript generates it, and that's not so nice for search engines.

So I thought, okay, service -led rendering will solve all my problems.

And it did, but it introduced some more like, okay, when does that server rendering actually happen?

Is it every request?

And as just mentioned, it's just the initial one, but it's another concept to understand.

So when would you recommend that someone uses server -side rendering in their application? So maybe,

I guess the more standard approach of building view applications has been And before Nuxt became as popular as it is now,

the standard was to build these view single page applications.

And the one place that I worked at, we actually used

Ruby on Rails, which is a server -side rendered framework.

But it actually bootstrapped itself into this single page app where that initial page render was done with Ruby on Rails,

but then now we've got a Vue single page app that's running.

What would you say are the reasons you would want to switch to server -side rendering?

Or how would you think about that?

Because you did mention there are some tricks or catches there with server -side rendering.

Yes, absolutely.

So if you use Vue more

or less as progressive enhancement of like okay i want to do some interactivity

but i don't render my full front end in it then switching to server -side rendering is almost impossible

i know there were some projects saying oh yeah maybe we can do the v8 engine

and php and whatnot but it never really took off um

and in that case yeah render your page in in rails

or in laravel or django whatever

and then use view on top of it it's totally fine

but as soon as you have the whole front end under the control view,

then it really makes sense thinking about server -side rendering when you need search engine optimization.

So if it's like a public page you want to share and when it's performance critical.

So typically any kind of landing page, any kind of e -commerce,

that's always a very tricky area because lots of things to show has to be very like recent updated data.

And that's like the classic example where server -side rendering helps.

But even for your blog or portfolio page, they just want to put out there, then service -led rendering makes sense.

100

But now that I think about it, we can't even go the other way around.

101

We're saying if your application is behind authentication, then we don't really need service -led rendering at all because no third -genge will ever hit that.

102

And, well, people have to log in anyway and to wait a little bit.

103

So that's not a big of a deal.

104

So as long as it's not public -facing, no service -led rendering is needed.

105

And it's also important to mention that you don't have to turn on the switch

106

or turn it off for service -led rendering for your application.

107

You can also say, oh, hey, I have routes, let's say, slash admin, and everything starting with slash admin should not be server rendered because it's,

108

well, the admin area.

109

But hey, my blog page should be server rendered.

110

So you can also make sure that you have a nice fine -grained structure saying, okay, that part should be server rendered and that part shouldn't.

111

But even if you had, And for example, this admin section that's behind authentication,

112

wouldn't you still get some performance benefits from having it server -side rendered?

113

I guess it would depend on what exactly that page is rendering.

114

Yeah.

115

So you would definitely have a better perceived performance because what happens in detail during server -side rendering is,

116

okay, you send a request and the server returns the HTML.

117

So you see straight away, okay, this is what the page will show.

118

It also ideally includes some inline CSS.

119

So I actually have the styles too.

120

And then the JavaScript is also sent, but that will be downloaded, executed, parsed, and then Vue and Knox will boot up

121

and basically go through the send HTML and more

122

or less convert it over to like Vue's representation to Vue's own VDOM representation and then for interactivity, attach some listeners.

123

And that whole process from, okay, I see the HTML,

124

but right now it's not interactive because there are no listeners and Vue is not up yet.

125

Until the point where it's up, that's called hydration.

126

Very important process.

127

And it's a little bit intensive, especially CPU intensive, if you have like a big page or like very complex components.

128

And while the perceived performance could be better for people saying, oh yeah, I see the page you might have the problem

129

that they want to click something but they can't

130

because the listener isn't there yet and there are also ways to improve

131

that but i think that's something to keep in mind yeah you could improve performance with ssr

132

but then you have to make sure that the hydration cost is low

133

that you can ideally delay that or say hey these parts shouldn't be hydrated and so on and so on

134

right and which is why nuxt has

135

that um hybrid mode where it switches between the two yeah exactly

136

and you can even go further

137

there are ways to delay the hydration to say okay as soon as i interact

138

or scroll then i want to actually do hydration

139

so you have a better first um like the first page load is faster

140

you get a faster largest contourful paint is one of the metrics that's relevant there.

141

But then you have to be very careful because there's another metric called interaction to next paint, which is a core web vital, same to LCP.

142

And that basically says, oh, if you click something, how long does it take until the UI shows something?

143

And if you say, hey, on click, I want to do the whole CPU intensive hydration part,

144

it might reduce the value there, causing troubles.

145

Also because your users, okay, click, and I wait.

146

maybe on your, I don't know, MacBook M2, like with all the fancy devs having that, it's like no problem.

147

But if you're on a mobile device, or maybe it's also an older device with German cell phone reception and mobile data,

148

which means it's not that nice, then it might take longer.

149

And people are like, oh, I clicked.

150

Why does nothing happen?

151

I click again.

152

And maybe people are frustrated and don't know what's going on.

153

That's an interesting point to bring up with with single page apps versus server side rendering,

154

where you have control over the server and how fast it is.

155

You don't have control over the network speed.

156

And you also certainly don't have control over your user's devices, whether they're on my phone,

157

which I still have an old iPhone 6S, which is like, I don't know, eight years old now.

158

And certain websites are very, very slow because probably the dev was like, whatever, it's fast on my machine.

159

And so the single page app on that case,

160

you're offloading more of the processing and those things to the end user's device versus on the server.

161

So yeah, that's an interesting trade off to consider.

162

Absolutely.

163

And the problem is if you have that hydration part in Vue especially, what Vue is doing is it's doing the same thing on the server,

164

but again, because you want to get to the point where the client is in the same state as the server.

165

So the client will get some values from the server, but also has to build up all the components again.

166

And other frameworks, like for example, there's Qwik, that's an experience of free zoomability.

167

And there are also lots of lots of other ways of dealing with hydration or saying, hey, I use island architecture,

168

which for example, Iris or Astro is doing saying,

169

okay, there are parts that are not really necessary to hydrate and other things that should be interactive.

170

I want to hydrate them and not all aesthetic content.

171

That's something I'm very interested in, especially in the view space to see where this is going.

172

Yeah.

173

Some of these frameworks have some really interesting approaches with how they very incrementally,

174

like progressively do that without having to load a whole bunch of stuff.

175

It's just like on demand,

176

which is, it kind of breaks my brain to think about because it's a totally new way of thinking about these things.

177

And it once again brings other complexity, like, oh yeah, if you don't have to do the whole,

178

like if you don't have to replay or do the same things on the client as on the server,

179

and let's say you send a console log on the server and think, why doesn't that appear on a client?

180

You also have to teach developers these concepts.

181

So the problem is not only like, okay, hydration is kind of solved, let's say,

182

but how you actually teach people how that works

183

or make a nice abstraction around that is yet another issue to be solved.

184

Yeah, and it's one of the trickiest parts of using Nuxt

185

that I've found is that server -side rendering introduces these different complexities because you're running it once on the server,

186

but you're not running it exactly the same as it would run on the client.

187

And so if you're used to just like client side single page apps,

188

then you have to shift your thinking quite a bit to be like, okay, it's going to generate this payload and...

189

I want things to sync up properly.

190

This part, you know, certain lifecycle hooks are not run on the server even.

191

And why am I getting this weird bug?

192

Because, oh, it did something on the server, but it's not doing it on the client.

193

And then, you know, there's, I find most of the bugs and weird things that I come across for my,

194

like when I'm writing my own code is,

195

has to do with that maybe because I'm like already comfortable with the view specific side of things and I'm still,

196

you know, my brain is still taking a bit to get around to the next way of doing things.

197

I think it's very common.

198

And just a quick mention here, you can even run your own server -side running setup with something like

199

Vibe, which was previously Vue plugin, no, sorry, Vite plugin SSR, or even rolled fully on your own.

200

Or you can even use Quasar, which also supports it.

201

But in the most common scenarios, yeah, if you use SSR in view,

202

then you rather don't want to roll your own because it's painful and you have to deal with all the issues that,

203

well, Naxx is already solving for you, let's say.

204

So that's one thing.

205

And the other issue, yeah, of course, the complexity, especially with, okay, which data has to go from the server to the client?

206

How can I mark the data so it goes over there?

207

Or like, what are these weird hydration errors which are always coming up?

208

Yeah.

209

And I know it can be tricky because you go for, oh yeah, I'm doing everything in the client.

210

It's fine.

211

A little bit of window here, a little bit of document, dot query selector here.

212

Please don't.

213

But I use this chart library here, no problem.

214

Yeah, on the server.

215

It isn't that easy because there's none of that there.

216

No window, no document.

217

And that's something definitely worth dealing with and understanding.

218

Like not into every tiny detail, it's fine.

219

But having that idea how the process of server -side rendering, what we just talked about, works, that it's only for initial request.

220

And that's, yeah, the complexity shouldn't be underestimated.

221

So another similar term is SSG.

222

So we've got SSR, we've got SPA, and we also have SSG.

223

And I have been confused about these terms, especially because they're kind of used interchangeably almost it seems.

224

And the acronyms are so close together.

225

And I've also seen other people confused about like, what is the difference?

226

What do these things mean?

227

Why, you know, if I run Nux generate, why is it doing this and not this other thing?

228

And so, yeah, let's explain what that acronym is and what it means.

229

Yes, that's a great idea.

230

Maybe let's turn it around this time.

231

Maybe you go for it, explain it.

232

And if I have anything to add, then I'll come after you.

233

Sure.

234

So SSG is static site generation.

235

Is that what it stands for?

236

Absolutely.

237

Good.

238

I was going to say server -side generation, which wouldn't be completely wrong.

239

Well, it's close to that, actually.

240

Maybe that would confuse less people.

241

But yeah, anyway.

242

Yeah, and

243

so there's a difference between a server -side rendered application where it's still being rendered dynamically every time you hit that page.

244

Whereas a static site is exactly that.

245

It's static, it's not dynamic like this is for things like blogs or other documentation sites,

246

things like that where the content doesn't change or need to be dynamically generated based on different requests.

247

And so we can actually generate this ahead of time.

248

Another word that's often used is pre -rendered.

249

Maybe that's why it adds to the confusion because there's so many different terms that describe these very similar concepts.

250

And so, yeah, there's this distinction between, do you need to generate it dynamically?

251

If yes, you have, you know, are you generating it on the server or on the client?

252

If it's not dynamic, you can do it statically.

253

And then you're going to do it on the server in some way.

254

And there's, again, many ways of doing this.

255

You can do it at build time.

256

You can build all your pages or render all the pages ahead of time,

257

which is what I do for my blog because it's straightforward and it works.

258

But you can also do different kinds of building where you...

259

incrementally build it over time.

260

And yeah, it gets complex.

261

Oh, exactly, exactly.

262

But yeah, I think that's a very good summary of static site generation, also known as pre -rendering, because these two things are exactly the same.

263

What I like to say about it is always think of, as you said, server -side rendering, but not on the fly,

264

not dynamically, because it's the static side.

265

So server -side rendering at build time, like as you said, ahead of time, before it goes to the server.

266

The good part is you get out static assets so you can host them everywhere.

267

Very lovely.

268

You don't need any kind of API connection unless you call APIs on the client side.

269

Like, oh yeah, you can submit a comment and that should go into the database.

270

You need that.

271

But if it's just about content that you, for example, grab from a CMS,

272

then you don't need an API connection because what Nuxt will do in this case,

273

it will take all the requests and it will create the payload and save that as well.

274

So some kind of JSON that's a bit compressed

275

and we'll put in all the data there so you don't need to do the API call again somewhere.

276

Because that would also be weird, like, okay, you have the data.

277

Actually, it was like that in Nux2 like years ago for a while.

278

Like it was like, okay, you got the data.

279

And then when you do a client -side request to another page, it will fetch the API again.

280

And if you refresh the page, the data, the content might be different.

281

But yeah, luckily we got over that.

282

and there was like a full static mode back then

283

and this is also the default now when you use NUX3 with npx NUXE generate.

284

Right.

285

And it's super useful for applications and even

286

if you say I want to start to generate a site

287

but turn off server set rendering

288

and you just generate one route then you have your single page application again

289

because that's just an empty HTML file maybe with a loading spinner

290

adding your JavaScript and your CSS in there and you're back to the plain old SPA,

291

which is why you can use a framework like Nuxt to build all kinds of applications

292

and you can switch that by just a few things in the config.

293

Yeah, and so you have a lot of flexibility with exactly how things get rendered and run and all of that.

294

How would you define the benefits of static versus server side rendering?

295

Yeah, I think, as I mentioned, that you can host it everywhere.

296

It's a big plus.

297

You don't need the server running all the time.

298

And it's the faster it gets because there's no API call.

299

There's nothing.

300

Nothing is faster than just plain HTML.

301

Just sending the files.

302

Yes, exactly.

303

That's a big pro.

304

Just putting in a CDN, cache it, and you're good.

305

It's, of course, tricky if you need new data because then you have to rebuild the whole site usually.

306

So if you have to change things every couple of minutes, then static site generation might not be for you.

307

Unless also there are options to say, hey, please pre -render only these pages and then it's fine.

308

So if you have landing pages and they won't necessarily change, you can pre -render them, but still have a server running for the rest.

309

For my own website, I have the blog side of things all pre -rendered in that way because they don't really change.

310

I occasionally update them, but then I push those changes and then the build happens again and then the whole site's rebuilt.

311

But that doesn't happen that frequently.

312

But then I have the other part,

313

my course platform side, which is interesting because it's technically just static content.

314

It's like a blog, but it has authentication around it.

315

So it's harder to do statically and have that authentication.

316

And so then the way that I've set it up is the blog side is pre -rendered for speed and all that.

317

And then the other side, the course platform side is just SSR, just the default.

318

Oh, so you use source -ed rendering with something behind authentication there.

319

Yeah.

320

Interesting.

321

I think you could even say for that part, you turn off SSR.

322

Yeah.

323

Then you might lose a tiny bit of perceived performance, but then people will just be faster to login form,

324

I suppose, or a bit slower to login form.

325

And then you can even use that.

326

Because that's also one important thing to mention.

327

even

328

if you do authentication on the server side everything

329

that's in the front end like every component every view page you write is technically visible

330

and human readable you just go through the for the javascript files

331

so if your content i i mean i assume it does

332

but for all the listeners as well um

333

if your content doesn't come from an api people can just read it um

334

and it's most important that it comes from an api

335

and is secured if you don't want certain users to see it because then people really need to be logged in,

336

authenticated to get actually access to that.

337

Yeah, I have considered, well, yeah, to your point about the single page app thing,

338

I want to do some testing with that to see if that's better or worse or what.

339

There's also a way that you could have it pre -rendered,

340

But then if you built a custom server to serve those pre -rendered files,

341

and then that server has the authentication built in, then instead of just like giving it free access,

342

then you sort of get like the best of both worlds.

343

But I think that's a little more complex and I'm not really interested in going down that route at this point.

344

Yeah, I also think you don't gain that much from that

345

because I think the added setup would be a bit more complex for sure.

346

But usually when it comes to authentication, then you have to use cookies then, right?

347

Because if you need authentication during server -side rendering on the server side, no local storage.

348

So there's that only way going for cookies, which is reasonable.

349

But of course, you could reduce the complexity by just saying, hey, okay, it's an SPI, it's fine.

350

And if people, let's say, bought access anyway, they probably don't bother with,

351

I don't know, half a second more perceived loading time.

352

Just like fictional number, right?

353

I don't know the numbers for that, depending on the site.

354

That's the way that I've thought about it too.

355

Obviously, I don't want it to be slow or terrible performance in UX like that.

356

Like it matters but at the same time, it's different than a blog post where someone is coming in from Google and they're like,

357

you know, if it doesn't load fast, you're just like, all right, back, let's check out the next one.

358

Like if you're going through a course, you're spending hours on this thing anyway.

359

And so, you know, it's loaded up and you're going through it.

360

I mean, ideally you bought it already.

361

So that's the best part.

362

Like you're not losing customers or potential customers.

363

People are more like, okay, nice, I'll get in there.

364

And it will already feel fast and snappy.

365

So that's good.

366

Let's pick up one more thing, which you already mentioned.

367

You already said the word incremental.

368

So of course, that's not the end of the service that's rendering, like sub modes or patterns or however you want to call it.

369

Yeah, there's of course more.

370

I think especially with NAX, the whole incremental static generation or incremental static regeneration,

371

ISG and ISR, or incremental static revalidation, I also heard.

372

Anyway, we go all down the same road.

373

A lot of different terms.

374

Yeah, naming things is hard, but then just stick to one, please.

375

It never works, though.

376

They all are ways to say, okay, I have dynamic server -side rendering.

377

But in a way, I don't want to hit the server all the time.

378

I have some cache in between.

379

And depending on how that cache looks like, it's one or the other.

380

So let's go back for a second to static site generation.

381

And the problem is, of course, if we need recent data or very up -to -date things, then it's tricky.

382

The other issue is if you have 100 blog pages, it's fine.

383

But if you have, let's say, 100 ,000 articles or 100 ,000 items in e -commerce store, it's tricky, right?

384

Because the builds would take ages and then you'd have to rebuild and so on, so on.

385

So even if it's like not super real -time data, but more like I have a news website and I have 100 ,000 articles,

386

which is for a bigger news website, not that uncommon.

387

you can't steadily generate all of them ahead of time because

388

that will take ages hours maybe even days um so

389

that was one of the big problems also by the whole jam stack movement was a bit like yeah

390

it's tricky and then someone came up with isg

391

and isr saying okay you know what we do the same thing as with dynamic server set rendering

392

so we have a server there and it's rendering stuff but why don't we cache the whole response?

393

So why don't we just say like, okay, we take it, stick in the cache and when someone hits the page again,

394

we'll just get that cache response.

395

And that's more or less incremental static generation.

396

Let's say the sites won't be generated initially.

397

The first user who hit the site, yeah, they have to wait a little bit because that's the initial server -side rendering,

398

which might take longer because our API calls on the server and so on and so on.

399

But after that, we just get the cached version.

400

So we're taking this binary choice between static or server -side rendered,

401

and we're turning it into more of a spectrum where you can like...

402

you could be fully static, you could be fully dynamic server side rendered, or you could be somewhere in the middle

403

and sort of kind of figure out what balance works for your application and your site, your needs in that way.

404

Exactly.

405

And then you can even say, oh, these are like more important.

406

Let's cache them not that long or these sites can be cached for a day.

407

It's fine.

408

And you can even go one step further and use SWR, which is another acronym for Stale Revalidate,

409

basically saying, okay, for my pages, I just set up, let's give them the cached version.

410

So let's say you hit slash about and slash about was never generated.

411

Then you as the first user, you get the generated version.

412

So it will take a little bit.

413

It's fine.

414

Now, if I hit the page, I get the cached version.

415

But if you enable stale, very validate, it will check, okay, is this cached version too old?

416

Too old meaning it should be revalidated.

417

But if I say yes, for example, it is too old, it should be revalidated.

418

I still get the stale content while the server in the background will revalidate the page, meaning it will update the cache with the newest entry,

419

and then the user after me hitting the page will get the new website, and the same starts again.

420

That's a wonderful pattern if you say, oh yeah, I want to reduce the load on my server because if I set it to one second,

421

for example, I have 100 users going on the same page.

422

I don't have 100 requests to the server, but when I'm going to the server,

423

the rest may be also waiting for the cache to populate or just get the things out of the cache.

424

And then the server will repopulate the whole thing once and you're good.

425

And it's an interesting way of balancing performance for the end user

426

and serving them the content as fast as possible while still updating the content and regenerating it as needed.

427

it is kind of like tricky to think about because it's like, wait, every, as a user, if you hit the endpoint,

428

you're, unless you're the very first one, you're never getting like the most recently generated one.

429

You're always getting the cached version, which might be, you know, as you had pointed out, it might be still valid,

430

but it might also be like the old, the old one.

431

And then the next person gets the updated version.

432

But it's kind of interesting to think about because then it sort of,

433

it means that the routes on your app that are the most popular get updated more frequently.

434

And the ones that no one goes to don't really get updated at all.

435

And so it makes sense from that sense.

436

That's good and bad as well, right? then like, oh yeah, somebody might go to a page and get like super old content.

437

You can even fix that by saying, oh yeah, if the cache entry is older than an hour a day or whatever,

438

then just do whatever the first user did with like your full service rendering request.

439

Then the user might have to wait a bit, but gets the most recent thing.

440

Right.

441

So there's ways to catch that so you don't get like really old content.

442

Yeah.

443

Yeah, you can basically say, okay, when should it be revalidated in background?

444

When should the cache entry be thrown away?

445

Like these are the two like maximum ages you can define.

446

So there's a lot of stuff with server -side rendering.

447

It's a very complex, in -depth topic.

448

And I think we've covered quite a bit of stuff here.

449

There's certainly a lot of ways to optimize and to configure for your specific needs and for whatever,

450

like literally whatever kind of app you are running,

451

whether it's like a basic marketing page or a giant news site or a SaaS app or whatever,

452

whatever else you're building.

453

yeah what as long as it's public facing

454

you might need ssr at least for a tiny part of application that's true

455

and i mean there i guess there are a few more things

456

that we could cover

457

but might be good for another episode like next server components could be could be very interesting to go into

458

that a bit more in depth um also islands architecture

459

and astro something that's really interesting and getting a lot of traction is loved throughout the whole like ecosystem them.

460

But yeah, I also think now everybody should have a little bit of a better understanding with regards to server -side rendering.

461

And if there are any questions left, then as usual, shoot us a message on some kind of social media, wherever you can find us.

462

הורד אפליקציה

כל מה שאתה צריך כדי לדבר בשטף

הגיית AIציון לכל משפט

תרגול IPAשלוט בכל צליל

אוצר מיליםבנה את מאגר המילים שלך

משחק אוצר מיליםלמד תוך כדי משחק

סרוק QR

Download on theApp Store Get it onGoogle Play

FOR YOU

המלץ על סרטון

151 משפטים

אוצר מילים והערות הגייה לשיעור הזה

שיעור הדיבור הזה מבוסס על הסרטון “DejaVue - The Need for Server-Side Rendering”. המילים שחוזרות הכי הרבה: server, page, rendering. בסרטון הזה יש 466 משפטים ו-5783 מילים לתרגול Shadowing. הדיבור נמשך 35:44. הדובר מדבר בקצב טבעי של כ-162 מילים בדקה, קרוב לשיחה יומיומית. 85% מהמילים נמצאות בין 3,000 המילים הנפוצות ביותר באנגלית; כדאי ללמוד את השאר לפני שמתחילים.

אוצר מילים מרכזי בסרטון הזה

15 מילים מהסרטון שכדאי ללמוד, עם ההגייה והמשמעות שלהן:

מילה	הגייה	משמעות
server שם עצם	/ˈsɝvɚ/	שָׁרָת
cache שם עצם	/kæʃ/	מִצְבּוֹר, מַחְבּוֹא
tricky שם תואר	/ˈtɹɪk.i/	טְרִיקִי
component שם עצם	/kəmˈpoʊ.nənt/	מַרְכִּיב, רְכִיב
dynamic שם תואר	/daɪˈnæm.ɪk/	דינמי
complexity שם עצם	/kəmˈplɛk.sɪ.ti/	מורכבות
solve פועל	/sɒlv/	פָּתַר
listener שם עצם	/ˈlɪs(ə)nɚ/	מַאֲזִין
plain שם עצם	/pleɪn/	מִישׁוֹר, עֲרָבָה
versus	/ˈvɝsəs/	נֶגֶד
topic שם עצם	/ˈtɑpɪk/	נוֹשֵׂא
confused שם תואר	/kənˈfjuːzd/	מבולבל
architecture שם עצם	/ˈɑː.kɪˌtɛk.t͡ʃə/	אַדְרִיכָלוּת, אַרְכִיטֶקְטוּרָה
delay שם עצם	/dɪˈleɪ̯/	איחור, אִחוּר
commerce שם עצם	/ˈkɑ.mɚs/	סַחַר, מִסְחָר

Phrasal verbs שתשמעו

מילה	משמעות
turn off פועל	כיבה, כִּבָּה
check out פועל	בדק
figure out פועל	הֵבִין, מצא תשובה
go down פועל	ירד
pick up פועל	הרים, אסף
take off פועל	הֵסִיר, הוֹרִיד
throw away פועל	הִשְׁלִיךְ

משפטים שכדאי לחזור עליהם

משפטים קצרים ושלמים מהסרטון שאפשר להשתמש בהם בשיחה יומיומית:

You just don't know it yet.
Do you need it?
Why would you use it?
Let's render everything on the server.
You don't have control over the network speed.

דקדוק בסרטון הזה

המבנים שהדובר משתמש בהם הכי הרבה, עם המילים המדויקות מהסרטון:

מבנה	בסרטון
סביל (Passive voice) be + past participle — הדגש הוא על מה שקורה, לא על מי שעושה את הפעולה	were born · is rendered · is needed
הווה מושלם (Present perfect) have/has + past participle — פעולה שקרתה בעבר ועדיין יש לה חשיבות או השפעה עכשיו	we've gotten · has been · I've found
משפטי זיקה (Relative clauses) who / which + clause — מידע נוסף על אדם או דבר	Rails, which is · paint, which is · Vibe, which was

הגייה ששווה לשים לב אליה

הדובר משתמש ב-104 קיצורים וצורות מקוצרות, כמו don't, you're, I'm. אמרו אותם בצורה הקצרה, כפי שאתם שומעים אותם.

הצלילים של “th”: bother /ˈbɑðɚ/, aesthetic /ɛsˈθɛ.tɪk/, authentication /ɔːˌθɛntɪˈkeɪʃn̩/
הצלילים של “sh” ו-“zh”: cache /kæʃ/, representation /ˌɹɛp.ɹə.zɛnˈteɪ.ʃən/, occasionally /əˈkeɪʒənəli/, interaction /ˌɪn.təˈɹæk.ʃən/, reception /ɹɪˈsɛp.ʃn̩/
מילים ארוכות — שימו לב להטעמה: complexity /kəmˈplɛk.sɪ.ti/, ideally /aɪˈdi.ə.li/, architecture /ˈɑː.kɪˌtɛk.t͡ʃə/, representation /ˌɹɛp.ɹə.zɛnˈteɪ.ʃən/, technically /ˈtɛk.nɪˌkəl.i/

צלילים שדוברי עברית מתקשים בהם:

/w/ — שפתיים מעוגלות, לא /v/: framework /ˈfɹeɪm.wɜːk/, swing /ˈswɪŋ/, afterwards /ˈæf.tɚ.wɚdz/, whereas /(h)wɛɹˈæz/, wherever /(h)wɛɹˈɛvɚ/
/æ/ — פתוח יותר מה-“אֶ” העברית, לא כמו “a” ב-“cup”: cache /kæʃ/, static /ˈstæt.ɪk/, dynamic /daɪˈnæm.ɪk/, admin /ˈædˌmɪn/, podcast /ˈpɑdˌkæst/
/r/ — הלשון לא נוגעת בשום מקום, לא ה-“ר” הגרונית: render /ˈɹɛn.dɚ/, generate /ˈd͡ʒɛn.ə.ɹeɪt/, tricky /ˈtɹɪk.i/, framework /ˈfɹeɪm.wɜːk/, rail /ɹeɪ(ə)l/

איך לתרגל עם הסרטון הזה

הקשיבו לכל הסרטון פעם אחת בלי לדבר, ורשמו את המילים שאתם לא מכירים.
התחילו במהירות 0.75×, תרגלו Shadowing משפט אחר משפט, וחזרו למהירות רגילה כשזה מרגיש קל.
הקליטו את עצמכם והשוו למקור, תוך תשומת לב למילים כמו server, cache, tricky.

מהי טכניקת השאדואינג?

שאדואינג היא טכניקת למידת שפה מבוססת מדע שפותחה במקור להכשרת מתורגמנים מקצועיים ופופולרית על ידי הפוליגלוט ד"ר אלכסנדר ארגואלס. השיטה פשוטה אך עוצמתית: אתה מקשיב לאודיו באנגלית ילידית וחוזר עליו בקול רם מיד — כמו צל העוקב אחרי הדובר עם עיכוב של 1–2 שניות בלבד. בניגוד להאזנה פסיבית או תרגילי דקדוק, שאדואינג מכריח את המוח והשרירים בפה לעבד ולשחזר דפוסי דיבור אמיתיים בו זמנית. מחקרים מראים שזה משפר משמעותית את דיוק ההגייה, האינטונציה, הקצב, הדיבור המחובר, הבנת השמיעה ושטף הדיבור — מה שהופך אותו לאחת השיטות היעילות ביותר להכנה לIELTS Speaking ולתקשורת באנגלית בעולם האמיתי.

טכניקת Shadowing: קרא את המדריך המלא שלב אחר שלב →

Shadowing Practice: DejaVue #E001 - The Need for Server-Side Rendering (SSR) - Learn English Speaking with Video

בחר מצב תרגול

הורד אפליקציה

We've got separation of concerns wrong

What is a Server? Servers vs Desktops Explained

React Native in 100 Seconds

Cache Systems Every Developer Should Know

Master AI in 60 Minutes with Vector Databases!

How Uber Scaled from One Server to 150 Million Reads Per Second

How I deploy serverless containers for free

BGP Overview

OWASP Top 10 Explained

Armchair Architects: Resiliency in the Cloud – Core Patterns

How do some languages not have tense?

It’s not just you

אוצר מילים והערות הגייה לשיעור הזה

אוצר מילים מרכזי בסרטון הזה

Phrasal verbs שתשמעו

משפטים שכדאי לחזור עליהם

דקדוק בסרטון הזה

הגייה ששווה לשים לב אליה

איך לתרגל עם הסרטון הזה

מהי טכניקת השאדואינג?