Understand the Next Phase of Web Development - Steve Sanderson - NDC London 2024
This talk was recorded at NDC London in London, England. #ndclondon #ndcconferences #developer #softwaredeveloper
Attend the next NDC conference near you:
ndcconferences.com
ndclondon.com/
Subscribe to our KZhead channel and learn every day:
/@NDC
Follow our Social Media!
/ ndcconferences
/ ndc_conferences
/ ndc_conferences
#web #software #react #blazor #technology #webassembly
It’s 2024, and the web continues to dominate the software landscape. Innovation proceeds in all directions, with new frameworks, build systems, and architectural patterns emerging at pace. But where are we all heading? Is there a pattern? What’s the next big phase?
In this demo-centric talk we’ll look at the common trends across web frameworks: disruptive new features that are showing up across technologies and changing how web apps are built. We’ll dig into live code examples in Next.js (React), SvelteKit, Blazor, Astro, and more. We’ll see how these and others are setting a similar path for the next phase of web technology - and how you could implement the same features yourself without any framework.
Finally, we’ll catch up on the state of WebAssembly and try out WASI preview 2 - the upcoming reinvention of WASI. Will it achieve the dream of seamless interop across all languages, operating systems, and CPU architectures? Will it become the standard for server-side cloud programming? Let’s build something with it!
That’s what a polished and well rehearsed presentation looks like, kids. Bravo!
Incredible talk, the snippets prepared beforehand makes it flow very smoothly. The WASI part is what I'm hyped for. A polyglot jupyter notebook comes to mind
after every Sanderson presentation, I realize I have just learned something important about the web :-)
This was awesome!
Excellent presentation 👏
This was awesome 👏
Awesome talk overall and a fantastic short walkthrough of the web development history at the beginning. Steve's presentation was so good taht it's been featured in the latest issue of Tech Talks Weekly newsletter! 🎉 Congrats!
we are attempting a generic Multi column drop down boxes as paged grids with selection of columns returning a Parameter stack using WASI component , use it across the applications in our product as in winforms.
Well done. Excited about the future.
I'll never not listen to Steve(n?) Sanderson
I think I’ll always be listening to to him 🤣 First time I’ve seen him and very impressed
He’s the best
This looks awesome! Would I be able to compile a C# function to a wasm component and use it in a browser, or would this only work in wasi?
He is simly the best
Such a good speech 🎉
Sadly Steve never talks about Blazors short comings - like awful handling(?) of sleeping tabs on phones or non working re-connect JS on all web browsers. Yes, there are workarounds - but for Blazor to succeed, these functions must work out of the box.
Well in this talk he doesn't talk about any shortcomings from the different languages at all. Do you have an issue-number from github for us that we can upvote?
Wasi looks great. Wasm haven't catch yet, maybe in the server it gets greater attention.
Sadly HTMX was not mentioned.
Why should he? It's neither a trend nor the future
Neither was Brazil. 😢
@@MC_DarkMaster Nor was the AI trend a year ago, so it's impossible to predict a trend. Also your point of view is subjective, for you it might not be the future, but for some it is.
@@gabrielilie4460 Your point is subjective too :) I think it is not possible to list all tiny projects that may become the next big thing. And actually HTMX is not something new. Knockout.js did almost the same thing 2011, Intercooler the predecessor of HTMX was also founded in 2013. So the idea behind that is alreay more than 10 years old. And it did not succeed.
First they ignore you, then they laugh at you, then they fight you, then you win.
Great presentation and all but... tabs for indentation, that's where I draw the line
I am back to command line and consider it future of UI
I just want to mention "Marko" because I don't think it gets enough love.
open my mind, leanred a lot.
Can’t wait to see RPC from flutter/js/blazor webassembly/uno defined with the .wit file as if it is running locally.
Some demonstration which are worth watching.
This looks great, feels a bit like microfrontends but for backends... so microbackends?
As anyone who has written react, the clock code feels illegal to write.
What is the current state of WASI now? When will it be out of "preview" state and be production ready?
more than a couple of years for sure, they are working on preview 3 now which is about async
This isn't new (streaming server side client) . I was doing this at 2 different companies 5 years ago. It does have more features than I made.
I sure hope this is the future. Hopefully we'll see first class support for accelerators like GPU, NPU, etc early on, which will help cement this as a great portable tech for server and edge and IoT alike.
Should have added a SPOILER WARNING for Twin Peaks...
All litters belongs to the portfolio/community chief, at least in papers for now…
Dont I see something similar to CORBA / IDL / Multilanguage theme that I did in one of my previous lives? A great speaker though....
Apparently "there are still a few people coming in" is actually part of this talk. Same exact thing said in NDC Porto, without the odd "I'll just talk over them" comment.
no mention Remix
Looks like a legacy php everything before Astro😅 and then web elements came. What is the reason of using client:load, why it can't just load?
because some people want to generate html in the server and send that for some reason. they believe your server(s) generating html for thousands of users would be faster than doing the rendering on user's device, because it "might" be underpowered. not to mention the complexity behind it all because delineating the "static" parts and "interactive" parts and maintaining it (in your head, documentation etc.) is hard. unless you are a content heavy website, client side rendering is fine, fast, simple, and cheap! in the case of astro, if you have a content heavy website with very little interactivity here and there (like a newspaper that has dynamic visualisations) it is just fine, astro manages the delineation between what is static and what is dynamic very well (islands architecture) so that is the most promising one. but for most other stuff, rendering html in the server is just a losing proposition.
Sounds that it will be messier at least for the next few years.
"...and obviously it keeps us in a job as we keep moving from one framework to the next..." Accidentally said the quiet part out loud. The reason it is out of reach for the average person to build a dynamic website, now, is because how else do you ensure job security? Lol, people can't help it. Even the new, open source versions of Redis demonstrate this. Redict works perfectly fine. If Redis worked for you, then so will Redict. But the other fork, Valkey, seeks to _innovate_ for the sake of innovation, itself. In open source space. Like they don't quite understand why they are doing what they are doing but they have some kind of narrative about why they should. Narratives are funny.
Atsro has a cool feature which lets the developers write client side logic using multiple Frontend Frameworks. It would be really awesome if Blazor adds support for this feature in future.
Cloud: Please run everything on the server again we are making less money😅😂 There are solutions to big client apps like just load what you use.
It wasn't that people outgrew ember angular knockout its just been shiny object syndrome for the last 15 years. O lets go MVC no lets go MVVC no lets go server side, no lets go client side blah blah blah. When I was doing win32/64 dev you picked *one* tool, got one major upgrade a year but stuck with the same tooling *for years* and delivered solutions....fast!
yeah exactly...every day a new fancy library / language / framework or feature everybody has to use...everything running in a docker container and managed by dozens of pipelines :/
I miss delphi
damn, all of that to render a couple of div tags sheeeeeit
He didnt just say Surveillance Driven Development with a straight face, i would have broken character.
*cough* Flash, JAVA applets, ActiveX, ?
😂 the more things change the more they change the same... We went from running code on the server to running on the client and I see we back running code on the server.
at 39:10 my mind = 🤯
but then you look at the network tab, how much javascript is being shipped to the browser your head will go nuclear.
HTMX Bro!
UpdatePanel v.2024
Maybe I'm missing something, but how is any of this revolutionary or the "next phase"? It's just all Ajax requests that are updating part of the DOM, we've been doing that for ages. These are just different ways of doing that without having to write the Java script to do it but ultimately that's what's happening. So this whole thing is kind of a snoozefest.
WASM is not ajax. Similarities?? Yes all computer software work in scope of possibilities brought by hardware and networks, so nothing revolutionary should even be expected. And if you paid attention he marked evolutions (no even revolutionary) to be introduced on their time, and he had that time axis there. You're missing the message. It's not about revolution in web. It's about evolution over the time.
:3
lol - just use HTMX?
Surveillance Driven Development 😂😂😂
soy development
Impressive; but really needs code online. How could I show the before and after? git checkout -b render-counter-frontend-islands && git commit -m "feat: render counter in Astro on client" It's actually the WASI crap I wanted to look at, but a point-in-time demo without access to the sources creates a gap folks have to cross
thank you, but no thank you. Wasm has its role and is not for the most of the web platform. gmail like webapps, games and like, and of course to mine crypto, lol. btw, wasm will make debug very hard. most of the web is information and linked data. we will see the return of server side rendering (has already started). bloated client side apps broke the web (linking is harder, broke accessibility (who cares about semantics when you see the display as a blank canvas to paint on), back button ,...
oh no...another new thing...stop with all these short-lived frameworks that are all the same anyway. The big tech companies and especially Microsoft must sweep through all those hobbyists who come up with a new framework or tool every year that add nothing at all.
Imagine living life without knowing about Twin Peaks 🦉
Before I saw this video, I thought Blazor was a confusing mess. I still do.
If you go from anything to anything (different)....it will look like a confusing mess at the start because it is not what you are use to seeing. Blazor is elegantly designed.
@@PortalUser2elegant is the last word I'd used for blazor. Blazor can't even decide what it is. It is at least two separate frameworks.
You're not wrong @JeffreyRennie
really?
javascript was and is a mistake. HTML is a document,not an "app"
Ok boomer. Meanwhile js goes brrrrrr.
Valid, but then how do we do logic and DBs, what would you suggest?
@@giorgos-4515 Sorry... are you saying we need JavaScript for logic and DBs? Two things that existed long before JS, both off and on the web?
@@Sammi84 Man-buns make me go LOL.
@PerryCodes Html itself is not enough that's for sure, but for interactivity and doing the actual processing(fetching from an API) you need JS.
i like php
Sadly without any comparable async/await. Like calling multiple different other apis concurrently without waiting for one after another
@@MC_DarkMaster I agree. But there is something great about templating html the way php does it. But it is true that it has its short comings. I wrote my own framework for bun that captures this early php vibe but still gives access to the js ecosystem and the js language features like promises and async await. That way we get the best of both worlds.
looks like bicycle reinvention for most cases. Arguments like users have "slow computers" or "bad network" are pretty strange nowdays - computers are extermly fast, network is OK and getting better. May be its sutable first page openning (ecommerce), but for most cases you still need dynamic ui for good UX. May be its better to write modular UIs with dynamicly loading bundles and create better tools for bundle shrinking?
A decent internet connection is out of reach 90% of people in low- and middle-income countries and around 2.7 billion people - roughly one-third of the global population - remain unconnected to the Internet.
@@semikolondev for 99.99% companies its not target audience - its hard to make money in such countries. In developing countries internet is on par or better than EU\US. Fast internet will be there when they become viable market
The real question is the beginning of the end for writing JavaScript. The current state of affairs is a absolute mess. Why should I have to try and write + manage some class in JS, and then on a wing and prayer figure out to have the save class server side? (heck, the data types from JavaScript to server side code does not even match 1 to 1). With these new technologies, then I can write pure server side code, and if that code needs to run client side, then not only can it, but it by-passes JavaScript 100% and is native browser code (wasm). This finally marks the end of having to grab 30 different JavaScript libraries and THEN trying to cobble all those client side frameworks with sever side code. Gee, need a toast message system - yup, go find another JavaScript library and inject even MORE messy JavaScript libraries into what already has become a mess of epic proportions of tying to inject 25 different JavaScript libraries into that browser. The issue not really only about reducing bandwidth, but is about a clean coding environment, where I don't have to adopt anything more then a nice clean server side coding language (say like C#). The potential to by-pass all that JavaScript mess and attempting to load + send all that JavaScript library code to the browser is the greatest promise of these new frameworks. Why send a bunch of messy HTML markup + JavaScript to render a drop down box? Why not send some tight and clean native browser code to the client side that then displays the drop down box? We not there yet, but these new emerging technologies will once and for all get rid of the horrible dance between client side code (JavaScript) and server side code once and for all.
@@Albertkallal it is the beginning of the end of everything but javascript. We will keep all the other languages in a little wasm box and orchestrate everything with javascript.
@@spirobel2.0 Those little bit of JavaScript parts will be added automatic, and you not be reading or writing JavaScript code when the dust finally settles here. The simple matter is this attempt to put a round peg in a square hole (JavaScript playing nice with server side code) been a bad dream and experience for all of us. It what we have, and it is the current state of affairs as to what we have to deal with now. But, in short time, we all going to dump JavaScript, and write nice clean pure server side code, and it will do all the dirty work of sending bits and parts to the client side - including that of having such code run in the browser. As this video shows, what is around the corner is frameworks that figure out all the bits and parts for you, and being able to code out say a nice toast message in clean simple pure server side code? I can't wait...... Right now, all this wiring of JavaScript and trying to call web end points is a mess, and a costly development approach. Trying to have 2 vast different languages (Sever side and client side) play nice with each other? It's fast going away. The end result will be a VERY clean and simple approach to writing code, and building web applications. I can't wait! So, will some JavaScript exist? Yes, it will, but it will be very limited, and YOU the developer will not see, nor write that JavaScript anymore....
**Shows rust: don't worry if you don't know rust or if you hate it** > Follows it rawdogin some C#... LOL
Hoping this talk will not be total grifting nonsense. Most talks with this title are.
Is this seriously just the SSR grift from a few years ago? 27 minutes in
He spent the last half of his talk discussing WASI in apparent total ignorance of its many failed antecedents
It's kind of amazing that someone who apparently works for MS isn't aware that 'ecosystem bridging' is very much a failed idea in the bytecode VM world. Of all the useful things WASI does that is not one of them.
.net? no, thanks.
The fastest platform and amazing languages - C# and F#
.NET and C#?? 500 lines of code just to make a button work? No thanks. Then I'm out!
What that's not true?
node_modules.