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
This is one of the best demo lead presentations I've seen, doesn't surprise me to hear a lovely upper midlands accent on it, can't tell if it is further north or not but he certainly sounds cheery.
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?
@@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.
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!
This will backfire. Why would companies want to render in their starved k8s clusters instead of for free on today’s powerhouses of devices. The problem is instead client technologies.
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.
The WASI component stuff is quite amazing but I’m not sure of the use case yet. I can imagine a sort of web server where you mount wasi components but then I’m just reinventing bits of Java EE application servers - again.
It is interesting to see bridging various technologies like that. Fantastic Steve Sanderson, as always. I love his presentations and the level of detail and complexity he usually goes into. However, the presented concept of combining technologies is making things on the backend much more complicated than most teams will want to accept unless they really have to integrate some legacy code/functionalities/externalities. The more tech interfaces you have to deal with, the more points of failure for your system and issues that will be hard to overcome. It's really difficult for me to come up with a valid real-world use case. Any specific ideas?
Only two things I can think of are: 1) Makes the hiring pool much bigger if people become familiar with using WASI to contribute code from any backend 2) Can utilise the right tool for the job, some languages have features or packages better suited to doing the job, in such a way you might end up making some code actually simpler. I think that will be a hard sell, but it is just a point
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.
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.
next phase of web development already happened. it's called mobile apps. no abominable js, native speeds, native apis, updated frequently, online, discoverable, linkable - most good things of web apps present
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
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.
NO. This is going in the direction of MAXIMAL COMPLEXITY. Huge developer teams will be needed, ONLY large companies will need to apply. Smaller developers who want to be productive CANNOT benefit from such complexity. Voted down.
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.
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 :/
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.
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.
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 ,...
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.
Наверное появится некий реестр wasm компонентов на подобие docker hub, которые написаны на разных языках. Это выглядит многообещающим, особенно, если заметно снизится объем зависимостей в браузер
Please don't use multiple languages in the same web application. Most line of business applications can just be razor pages with limited JavaScript. Complexity will get out of control easily and it is bad for any business or non profit.
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.
I call BS. JS wasn't a horrible language back then because of jQuery being used. DOM was horrible (and kind of still is) so jQuery was a thin library **made in JS**, imagine that - JS used properly to create jQuery, to fix the horrible DOM mostly coming from the Internet Explorer side of the Web.
😂 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.
@@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....
I never saw a Frontend talk structured so well and delivered so fluently as this one. Thanks a lot, Steve!!
That’s what a polished and well rehearsed presentation looks like, kids. Bravo!
after every Sanderson presentation, I realize I have just learned something important about the web :-)
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
The WASI section was mind-blowing 😮
Smooth as glass. Love the tour thru the various frameworks without any marketing-speak. Disarming and informative.
Fantastic presentation. I learned a lot. THANK YOU. You set a standard of how tech talks should look like.
This is one of the best demo lead presentations I've seen, doesn't surprise me to hear a lovely upper midlands accent on it, can't tell if it is further north or not but he certainly sounds cheery.
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?
No HTMX mentioned..
Great wealth of knowledge right there. Thanks a lot
He is simly the best
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.
Some of us were rendering client side using Dynamic HTML and JavaScript in the early 2000's.
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!
Excellent presentation 👏
where can i find the github repo for all those sample projects? Or at least the one made in blazor.
*cough* Flash, JAVA applets, ActiveX, ?
Can’t wait to see RPC from flutter/js/blazor webassembly/uno defined with the .wit file as if it is running locally.
This will backfire. Why would companies want to render in their starved k8s clusters instead of for free on today’s powerhouses of devices.
The problem is instead client technologies.
This is a benefit for content websites that need faster load time not for productivity apps that we use daily at work
Back to CGI times with Javascript on the server and spaghetti code for the client ... nah !! ... don´t worry, everything is fine !!
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
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.
I am back to command line and consider it future of UI
As anyone who has written react, the clock code feels illegal to write.
Bravo! Great presentation! 🙌
Wasi looks great. Wasm haven't catch yet, maybe in the server it gets greater attention.
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 looks great, feels a bit like microfrontends but for backends... so microbackends?
This was awesome!
The "future" is not to use JS at all
The WASI component stuff is quite amazing but I’m not sure of the use case yet. I can imagine a sort of web server where you mount wasi components but then I’m just reinventing bits of Java EE application servers - again.
It is interesting to see bridging various technologies like that. Fantastic Steve Sanderson, as always. I love his presentations and the level of detail and complexity he usually goes into.
However, the presented concept of combining technologies is making things on the backend much more complicated than most teams will want to accept unless they really have to integrate some legacy code/functionalities/externalities. The more tech interfaces you have to deal with, the more points of failure for your system and issues that will be hard to overcome. It's really difficult for me to come up with a valid real-world use case. Any specific ideas?
Only two things I can think of are:
1) Makes the hiring pool much bigger if people become familiar with using WASI to contribute code from any backend
2) Can utilise the right tool for the job, some languages have features or packages better suited to doing the job, in such a way you might end up making some code actually simpler. I think that will be a hard sell, but it is just a point
Dont I see something similar to CORBA / IDL / Multilanguage theme that I did in one of my previous lives? A great speaker though....
Should have added a SPOILER WARNING for Twin Peaks...
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.
open my mind, leanred a lot.
He didnt just say Surveillance Driven Development with a straight face, i would have broken character.
This is where you start understanding how farseeing the theory base under the HTMX is...
Thanks for this... I was beginning to get frustrated by blazor 😢
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.
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?
Microsoft has docs how to build wasm from c# and call it from javascript in the browser 😅
OK but what *font* is that in his editor? so clean...
Well done. Excited about the future.
I just want to mention "Marko" because I don't think it gets enough love.
superb presentation
Some demonstration which are worth watching.
What about Wordpress?
Is this related to google web dev ?
Damn it, That was smooth! Everything was super clear.
Thank you.
Funny that actually React was based on Elm
He's a genius
damn, all of that to render a couple of div tags sheeeeeit
next phase of web development already happened. it's called mobile apps. no abominable js, native speeds, native apis, updated frequently, online, discoverable, linkable - most good things of web apps present
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
Sveltekit... let's go 🎉
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.
Sounds that it will be messier at least for the next few years.
won't client size lazy loading serve the purpose?
NO. This is going in the direction of MAXIMAL COMPLEXITY. Huge developer teams will be needed, ONLY large companies will need to apply. Smaller developers who want to be productive CANNOT benefit from such complexity. Voted down.
We just need to get back to rails, django or laravel.
@@tomasmilgronfull circle confirmed 😂
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.
lol - just use HTMX?
Such a good speech 🎉
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.
Great presentation and all but... tabs for indentation, that's where I draw the line
HTMX Bro!
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 :/
Literally no one "outgrew" angular! Still one of the most used framework. Please dont comment about something you have no idea! 😂🤣🤡🤡
I love that the AI recommendation for the highly productive “camera covered” person is “investigate” 😂 suspect the AI is being a little sassy there.
Also, brilliant use of snippets for the live demos!
awesome!
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.
We need to move past the web and start coding dreams for angels that can save hubmanend cind
90% of the websites don't need this kind of tools.
UpdatePanel v.2024
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.
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.
Surveillance Driven Development 😂😂😂
soy development
I was starting to think I was the only one who heard the part about surveillance 😂 Presenter sounds like a fucking Dictator to work with
No privacy development 😂
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.
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 miss delphi
really?
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 ,...
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
Наверное появится некий реестр wasm компонентов на подобие docker hub, которые написаны на разных языках. Это выглядит многообещающим, особенно, если заметно снизится объем зависимостей в браузер
Please don't use multiple languages in the same web application. Most line of business applications can just be razor pages with limited JavaScript. Complexity will get out of control easily and it is bad for any business or non profit.
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.
Lee Elizabeth Brown Sarah Anderson Sarah
Imagine living life without knowing about Twin Peaks 🦉
no mention Remix
I call BS. JS wasn't a horrible language back then because of jQuery being used.
DOM was horrible (and kind of still is) so jQuery was a thin library **made in JS**, imagine that - JS used properly to create jQuery, to fix the horrible DOM mostly coming from the Internet Explorer side of the Web.
😂 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.
IDL (of CORBA) keeps getting re-invented in myriad interesting ways from gRPC to WIT 😀
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.
shame on you!
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
PHP on steroids.
.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.
.net? no, thanks.
The fastest platform and amazing languages - C# and F#
This was awesome 👏