Це відео не доступне.
Перепрошуємо.
Have Single-Page Apps Ruined the Web? | Transitional Apps with Rich Harris, NYTimes
Вставка
- Опубліковано 5 жов 2021
- The backlash to modern front end development is gaining steam, with good reason: single-page apps have ruined the web. Can we rescue it without going backwards? In this talk, Rich Harris presents a way to do just that. Rich Harris is a graphics editor at the New York Times, where he builds JavaScript apps to help explain the news. He is also the creator of Rollup, the JavaScript module bundler, and Svelte, the front end framework.
What’s wrong with Single-Page apps? There are a lot of critiques. A non-exhaustive list of terrible things about single-page apps include:
You’ll need a bloated JavaScript framework and performance will suffer
It comes with complex tooling and is less resilient, since it won’t work without JavaScript
It will be buggy and accessibility issues
JavaScript failing is a fact of life. So what’s a developer to do? SPAs solve problems to the traditional approach, but are still problematic. Rich presents a new framework for thinking about how we can get the best of both the MPA and SPA worlds: transitional apps.
What’s a transitional app? Transitional apps samples elements from both traditional and modern architecture. The term is borrowed from interior design’s framing of “transitional design.” Transitional apps are, like multi-page apps, server-side rendered for fast initial loads, resilient since they work without JS by default, and provide a consistent experience with accessibility features built in. But like a single-page application, they also have a single codebase, fast navigation, persistent elements, and client-side state management.
Learn more about transitional apps, and how to get the best of both worlds in Rich’s talk.
Jamstack Conf is hosted by Netlify, a platform to build, run and scale modern web apps www.netlify.com
www.jamstackco...
Please make a video about your previous startup, Aviato.
🤣 😂
You know Aviato? *blushes*
@@ricardoamendoeira3800 My... Aviato? *gasps*
I knew he looked familiar 😂
🤣🤣 think he still has the car?
Traditionalist here. IMO the most valuable part of this vid by far is you explaining the use cases for SPAs. I'd pay money for access to vids that just explain use cases for different tools/technologies like this. I.e. show me clear mocked up examples of what actual new functionality is made possible by this tool, with explanations for why those features were not possible before. Its amazing how hard that can be to come by. I think framework advocates avoid giving those examples because it makes it makes the framework seem less profound and it makes it easier to understand when you don't actually need that framework. So thanks.
SPA ruined Ctrl+Click navigation for power users :(.
In the past, I was so used to holding ctrl + clicking links to open them in separate tabs, now that don't work anymore. You now have to "duplicate" the tab and then hope it opens to a state close to where you were. Simply put for a power user that is good at using shortcuts including Alt-Tab to switch between windows (and yes tabs if you separate your one tab from the rest) or Ctrl+Tab (Ctrl+Shift+Tab) to move back and forth between tabs.
It's not even that hard to add that functionality to an SPA, they should add it every time if they really can't do MPA
What you are describing is HTML fundamentals in my opinion. The problem is not SPAs, it's that devs these days are further away from HTML than before, because of frameworks that abstract away everything. Devs need to learn to use anchors for what they are meant for (linking to content) and how they are meant to (not as a button) and keep as much state as possible related to the URL (i.e deep-linking). I try to enforce and teach both those things as much as possible to my teams. If you have the right fundamentals, it should take the same amount of time as doing it the wrong way
@@dogoku "it's that devs these days are further away from HTML than before" This is probably more accurate, I'm also pro-fundamentals. If you want to be professional in your work you have to understand the basics of what is expected or the norm in your coding domain. For instance, in the past, I've seen so many Windows Forms-based (.net) apps that don't correct "tab" navigation. So if you again use the app and "tab" navigate you jump all over the place. Even after Microsoft spent a lot of time to make it easy to correct this, no one bothers in their apps. I currently dub this as "Rapid Prototyping Coding", vs. "Release Coding" vs "Maintenance Coding".
@@owenpalmer8242, I think the aim of the video is that when you code MPA's you don't need to implement these features the browser has them covered already. Now with SPA, you have to specifically add these features back. Even though we can argue that it is easy or a framework may automate it. Also, I'm wondering how far should you go? Because for instance a dynamic HTML content that gets loaded after the page is loaded, should you now also include the "state" of controls? (Like whether a checkbox is checked or not). You end up basically capturing all dynamic changes in the URL or some client-side storage. I would say go all in, but coding a huge SPA this way may be time-consuming. (Again compared to the MPA where the browser already handles this).
@@bernarddt I agree with a lot of that, and would even say that in a lot of cases, MPA with minimal styling (essentially retro web) is the most natural and the superior way to develop sites. Unfortunately, this does not hold true for a lot of the demands of the user. Not everyone enjoys jumping around a site using only tags and hrefs, regardless of how much easier that would be for devs.
God this talk is almost ASMR to me, not because it's boring (it's definitely not) but because the eloquence and honesty with which they present each argument calm me down. I keep coming back to it when I feel stressed out, I wish more technical talks were like this.
Rich's talks are always intuitive and they will keep you interested till the end.
and he always comes out of the gate swinging.. and I love it.
always intuitive?!?
@@bashful228 yes.
As a traditional web developer who is learning SPA type development, I would like to say that SPA is basically an expected conclusion. a LOT of mobile apps are just wrappers around SPA style web apps.
As to the JS frameworks, there are some nice ones out there.
Never knew that Jesus was a front end guy
I never knew Jesus was white.
Looks more like Erlich Bachman
@@caLLLendar Seriously.. F O
@@Stinktierchen Your fragility is showing.
@@caLLLendar Look at this strong one here. A freaking low IQ creature comes along with his fragility bullshit. I am not an ape, dont come to me with your primitive nonsense. You wanted to provoke.,.. you got my reaction. Exactly what you desired. If you need something in addition. Dont hesitate writing me. Especially if you need some lead, I am willing to provide
Love the nuance. The bit in the beginning about attacking caricatures is spot on. I hope we can all be more charitable to others' opinions like Rich is here. What a wonderful talk.
I always noticed that some sites behaved weirdly and were really annoying to navigate (especially the mouse wheel click that opens the page in the same tab or sometimes not at all is a real pet peeve of mine) but I didn't have the knowledge or vocabulary to pin point why I hated them.
I also appreciate that you tried to stay as neutral as possible and presented both advantages and disadvantages of both models.
Damn the kind of issues he stated with single page apps are exactly the things I am infuriated with my coworkers for. In a lot of cases, manual history push/pop is required to be placed at proper places for example, I saw very few doing this and back button being broken everywhere. When I told this to our QA even he said he forgot about the back button. We back button users need help
Maybe the SPA devs didn't know how to implement client-side routing. This should be foundational knowledge in Angular, React, and Vue.
Doom Guy. Nice.
Doom
How does someone forget about the back button? It's probably the single most used button in a browser.
@@IvanPortugal Wtf does it have to do with dev knowledge? Most developers work either from specifications, or "stories" written by "product owners". They commit to "story points" for delivering exactly the functionality specified by the customer or by their "product owner".
If the product owner described how the back button should work and etc, and the devs committed to delivering it, then I'm sure they would get what they asked for. If they didn't specify how they wanted the back button to work, or didn't view that as valuable enough to consider or to commit story points to, then they likely didn't get it.
Developer knowledge or ability have nothing to do with it. This conversation is entirely about power structures within the industry.
The Rails solution (hotwire) is the one I have been doing for years, except with PHP. Partial page updates are easy and very effective.
I was an early adopter of React (and Flux). Back then installing all the dependencies was a nightmare. Now React has packaged everything together, which makes life easier. Still, SPAs and modern web development force you to depend on packages that are constantly being updated, or that may no longer be maintained. This can leave your app vulnerable. God forbid you should step away from your project for a month and come back to it later... Pray that all the packages still work and can be updated.
This is that caricature thing Rich was talking about
I've kinda been doing this since 2018 in production, and wrote my initial codebase in 2014. We don't need to drop JS altogether. Just stop writing ad-laden, framework-stuffed, dependency-ridden bloat. And successfully convey that message to the visitor. The first and last parts are going to be the hardest though. There's far too many ad-laden sites that needn't be, and people have had numerous CTA's thrown at them over the years from the obvious sales pitches, to notifications about notifications because apparently chickens and eggs both came before chickens or eggs, to cookie banners, privacy/GDPR prompts, and whatever else inevitably comes next.
Why don't we as developers just take a stand and build solid, functionality-rich websites that do exactly what they claim to do without any of the now normalised nonsense.
Yea not sure why he is talking about this now? This is hardly a new thing.
Developers dont take decision. Marketing and shareholders do, that's why
@@anonymeforliberty4387 oh yes the marketing team decides on the framework! Are they also configuring the servers as well? Give your head a shake.
@@GifCoDigital Do you work as a developer?
@@krazymeanie yes why?
My framework is spa and it is lightweight, bugfree, and navigation works. You are right that the trend is to use bloated, buggy garbage, but it doesn’t have to be like that to get the benefits of spa.
I think the point he's trying to make is that by default, SPA's encourage buggy design and you have to put in a ton of work not for there to be really bad navigation issues. Like he said if even Github, Instagram and so on can't get this right, how do we expect random devs to get it right?
@@lieQT the awesome things about SPA for some it make web app development far easier at least for vue and svelte. for react though it kinda annoying also angular which seem sometimes complicate things instead of making it easier
next js doesn't have half of the problems he presented
I can’t really disagree with this viewpoint, however the main thing is to make sure your user is never waiting more than a second to see requested info. Whether single page or multi page, slow & hard to find info is a fail.
The single-page in fact is what the web should be since the introduction of Javascript.
As a Creative Developer from the Flash Player era I know the only concern about this was the indexing and analytics metrics, so to do this they simply killed FLASH so we lost about 10 years of multimedia rich and artistic content the Flash already was delivering, including GPU features. So now finally we're back to the same place where WebApps are eliminating the need for NATIVE Apps and still some ignorant think static text-like documents will lead to evolution.
But I guess this time the WebApps + WebAssembly + WebGPU will simply kill the need for App Stores and the Backend and Native developers will need to adapt.
That's a good point. The web used to be alot more fun back in the day.
But it is transitioning for sure which is pretty cool.
however, I keep thinking the browser based web is not the future in general. It seems more likely that AR / VR will be.
Always hated the "JAM" stack acronym, I hope "Transistional Apps" catches on and superseeds JAM. Great talk as always!
TRapps for short.
@@abj136 I love that.
@@iboos9173 IT'S A TRAPP
Web development is the only place I'm aware of where reinventing the wheel every time is accepted or even considered desirable
Well said!
What wheel does transitional apps recreate?
@@chrisvouga8832 everything that breaks when you don't load content without js, including page rendering
@@MrVecheater Real sorry I’m not following. What wheel does transitional apps recreate?
@@chrisvouga8832 it means you "invent" something that already exists
While i already loath those JS-ridden sites that take enormous amounts of computation and time to finish loading, i find it even worse that web-developers now start claiming their websites to be Apps - no, those are very different.
Making a website that works correctly with multiple pages while still keeps track of various things like where on a continuous-loading page you were or keeps playing music is impossible with multi-page sites? Since when? Why are you making such claims? That has been done with good old PHP like 20 years ago already. It is not even hard.
Even worse is that now many pages you tons of JS just for simple things like mouse-over captions for images - dude, that is base HTML and does not require any scripting.
Many single-page websites nowadays take longer to load AND are slower to navigate than sites from 20 years ago where we had far slower machines and internet. When a modern PC takes 5 seconds to fully display a page that mostly consists of text - image just how long that would have take on something like a Pentium 3 with 300kbps ISDN (current machines are literally hundreds of times faster).
As a developer who has built both MPAs and SPAs where SPAs shine is with cloud business applications. Being able to modify a single page and swap in different elements based on user input selection is very attractive to customers and provides a very clean UI experience. The modern website as we know it which is largely limited to News and Blogs doesn’t really need SPAs.
Wordpress solved all those problems years ago.
Variations of this of course are social media and e-commerce sites and e-commerce sites are all plug and play templates and the average person really doesn’t need a social media site.
Lastly one of the biggest pushbacks for SPAs that I know of is developers tend to be lazy. They really just don’t want to spend years learning a new framework like angular.
I left front-end development after 18 years because of the explosion of frameworks and rendering models client side. Initially, I was happy with the popularity of Node and NPM. I appreciated the tools that it allowed me to optimise package sizes of my bundles. But then React happened. Then WebPack. I just couldn't keep up with the complexity. The mental overhead you just have to deal with on how to model interactions and data movement on the client side is just too much. All this on top of the complexity of setting up your build and bundling pipelines that change almost every few months because of the latest and greatest. Then permute these interactions with all the device form factors you want to support. Combine that with the mid-tier and back-end APIs you have to develop to support your interactions. It's crazy. Have moved to back-end development, and I'm now back to enjoying software engineering again.
You sound like the stereotypical old boy developer who fails to move with the time. I do empathise for you though as I can only imagine this happening to me in my lfietime too.
I agree. It's kind of important to keep the SPA's functionality, or the user stories and UX, really simple (Develop, deploy and run away). And I try to avoid switching frameworks, or adding any new dependency. It would result in task switching, what is very taxing for cognitive performance.
There are max 1.5 things someone can become very good at. 1 thing that currently pays the bills, and a 0.5 thing that might pay the bills in five years. Everything else must be delegated, outsourced, or removed from the wish list.
@@samherd7914 Yes, unfortunately, this is exactly my situation. I'm happy with backend development now, though. Java/Spring and slowly getting into Kotlin.
Blazor is the answer
...and then we have "server side rendering" for SEO, and we have gone full circle.
PS: turns out you point most of these out towards the end of the video, which was a relief.
I get that you're trying the point of view of someone who rejects SPAs (as I did years ago before figuring out the benefits when scaling), but still I want to throw in my 2c.
- you will need a JS framework : yes, unless you want to build it from scratch yourself. You can do that to if you're so inclined. Many people use Laravel for PHP, same deal. Building frameworks is a lot of work and most will use an estabilished one.
- Performance will suffer : not if you do it right, at least, not noticeably.
- It will be buggy : as buggy as all your other stuff is
- Accessibility issues : again, not if you do it right (care for your markup! use ARIA! ) and just the same accessibility issues as your other stuff.
- Complex tooling : yeah, this is the price paid for being able to use and extend languages that are not implemented in a browser. It's complex but most people will not have to touch the complex parts.
- Less resilient - it won't work without javascript : it also won't work for WAP. This is not an issue and hasn't been for over a decade
Sure, once you move from writing documents to writing software you have the hardships of software. You have the same issues if you're writing server code.
Ask yourself: what's my target audience? if you're targeting 2g, there's a lot of other concerns that have nothing to do with SPA, but with the fact that you are dealing with really old tech and bandwidth. Maybe you can't use CSS, SVG or even images either! and if you're targeting terminal users, maybe skip html altogether? always design for the end user.
On the second vs list:
- MPA is server-side rendered, but you can have server-side rendered SPA too via hydrate. Also, the point of SPA is freeing capacity on the server and serve it via a CDN on a leaf near you, which outperforms a centralized MPA, specially after the first load when the bundles are cached.
- SPA typically have poor initial load performance, because they're not done right. Pre-render what you can, split your bundles and lazy load, don't repeat server calls for the same info, don't block the entire UI for a single component's loading, etc.... I'm sure there's more good practices I missed there. All of these help with bloat, specially on large apps. You could also checkout microfrontends for an alternate take on the issue.
you can give paths to modals and they appear when the path is the modal's path, modal appears automatically.
when you wanna close the modal you do history.back()
and it closes. or the user can press back themselves.
if you refresh the page while the modal is active, the modal just opens automatically as expected and modal can either pick the page at the back or it can load main page at the back.
It's a bit of bad-faith argument to use the Instagram website as an example of why SPAs are bad. It's a website that has been designed to be so terrible in an attempt to direct you towards downloading the app onto your mobile device.
That is a really point I hadn't considered.
I'm sorry I'm going to have to disagree with at least the first 8 minutes. SPAs can be designed to work with navigation and in a way that is accessible. You're not going to make a traditional website without javascript so being able to load a site without it is a poor point to argue. The speed of first render can be a problem but you're going to have that problem with a mpa when bandwidth or server resources are limited. Saying you can't persist data while navigating in a MPA is also incorrect when you consider local caching like using local storage. You can also get around the not being able to play media in a MPA by using s.
In 5 or 10 years we will look back at the state of front end web development today and cringe in the same way as we look back at how we used to use spacer gifs in HTML.
Design and engineering should always be about what the application is first and tooling second. How much of any tool or technology is needed shouldn't be a fashion statement about whether one likes something or not. It makes sense for Google Maps to be a one page app. It makes sense for Wikipedia to use HTML links because of its high reference capability, the original design intent of HTML links to begin with. Web development is far more fashion industry than engineering and that's the real problem.
What a terrific talk! Very well-balanced and even-handed.
This mans competence is so evident it punches me in the face through the screen. +1
@championchap have you seen other videos with Rich?
Im pretty sure making the hottest js framework (50k github stars) and making rollup (20k stars) is not considered average.
@championchap WHAT?
@championchap Average? What the hell?! The guy is an insanely productive and competent developer, he created and maintains Svelte, Rollup, and a number of other popular and important projects.
JavaScript to the internet is the equivalent of building your home on quicksand
I'm only 5 minutes in and it's rare that I actually feel thankful for information in a video anymore. I appreciated this
This seems a bit biased view towards MPA.
I keep seeing this argument everywhere. But SSR isn't necessarily faster - it still depends on the request speed. If that request is slow, you will see a big nothing (vs SPA where some layout will be visible + loader). If we are talking about statically generated page, then of course it is faster, but that is not SSR.
Accessibility, for the most part, has nothing to do with SPA vs MPA conversation.
Pretty sad all this human talent and resources is being wasted on all this stuff that is largely unnecessary.
I work on software development teams and SPA often requires an entire team of front end devs due to the added complexity of front end frameworks (React, Angular, VueJS) and it is hard even as a full stack developer to be a master of the complexities of both a front end and back end code. You end up with crops of new pure front end developers who don't even know how to join tables in SQL. NPM and the large number of packages required adds a huge number of dependencies.
The biggest problem with SPA is that most people face it as a one-size-fits-all solution. It does have advantages, but for most business they just add avoidable complexity.
Interesting talk. The 'single-page apps have ruined the web' line is hyperbole. A major reason frameworks are used is to handle the problems that pop up when building complex apps, I think he overlooked that. Although this kind of turned into a Svelte infomercial I will actually be giving it a look. So many of the framework and SPA guys I pay attention to are always raving about it.
Complex apps!
A crud admin panel isn't complex, so why default to React or Vue? This is the problem I see - far too many front end devs are "React Engineers" and default to it for everything no matter how simple the requirements are.
I've seen teams spend weeks building out backoffice front-ends that have no hard requirement for any JS at all which could've been built in server rendered templates in a single day (Rails for instance).
@@growlydog I don't see your point. Are you saying all "complex" apps are mere "crud admin panels"? Obviously not true. Should such a basic panel be built using React? Obviously not. That leaves us the possibility that there are apps more complex than admin panels that might be best built using a framework. It's not hard to imagine such use cases and you haven't made a convincing point against that.
I get the criticism against over-engineering, but the implication seems to be that all uses of frameworks are instances of over-engineering. That thinking seems to just willfully ignore the legitimate reasons that devs/teams decide to use frameworks.
@@ighsight I'm saying that, in *my experience*, over a decade building web apps, I have seen my teams at multiple companies become teams of React engineers that have forgotten that there are simpler, faster technologies to build with. So when we have a simple CRUD form, or an app that lacks a need for dynamic functionality, as is typically the case with backoffice front-ends like admin panels, they still invest extra effort in React instead of just doing simple server side rendering.
I think you interpreted my original comment to be the opposite of what I was saying.
Admin panels are typically simple.
Some apps need more complicated tooling to build, like the Spotify app for instance.
But a back office tool for a user to search for a user account for customer support should probably be server rendered, until there's an express need for app like behavior.
My point was really "Frameworks have become the default for everything regardless of complexity, and that is a bad thing. There are still plenty of common use cases where frameworks add unneeded complexity and we should revert back to simpler rendering in those cases"
@@growlydog I think I did get your point- devs/engineers often use a framework to over-engineer a solution for a relatively simple use case or problem. I didn't see how that was an effective response to my original point- sometimes using a framework is the best solution for what you are doing since what you are building is relatively complex. I'm saying this talk did not address how a "transitional app" would be better than a framework for that situation.
It has more to do with the horrible user interfaces that stem from these apps. People have those really weird ideas on what is intuitive, what is easy to use and so on. They're thinking more about their backs than the end user in most, if not all, instances.
I get easily bored with dev talks but on this I couldn't just press pause. Rich Harris is a fine speaker 😆. Onward to #TransitionalApps
I have been a full stack web dev for a very long time and only got to building very basic SPA's very lately, right before I moved to backend only dev, where I have come to understand and appreciate separation of concerns and other backend dev tricks.
So now I am really convinced that frontend and backend should be completely separate and only communicate by API.
But that being said, as a user, I hate most SPA's :) I think browsers and websites have gotten more and more bulky and slow and trying to do too many things that they shouldn't. One thing is to load some partial info from the server, and a completely different thing to render everything from JS.
As a user, I would appreciate it more if my device used less CPU, less heat, less battery, when simply opening up a webpage! You guys need to figure this shit out :)
i figured out. Create a mobile app and that's it. Web pages are going to be replaced in the future by mobile devices, because of the metaverse. (phones, tablets, VR / AR glasses, etc)
Everything you say feels perfectly obvious after hearing it. There’s something magical about that
My webdev stack is static vanilla HTML, JS and CSS and Go for the webserver. I almost never use 3rd party libraries in my JS. I also use the HTML template tag more than anything rather than server sent page content. Just fetch data from the server, and have functions to clone the proper template and populate the page.
Apparently I've been building transitional apps, and thinking they were SPAs the whole time. I've never regarded it as a departure from SPAs - more of a best practice.
I'm confused by this - if you have to inject javascript into a root HTML page vs delivering individual HTML resources how can you think you're doing one over the other? SPAs are always built with frameworks like React or Angular, were you not using one of those? Not trying to be annoying just interested.
@@chris94kennedy SPAs are about not rendering HTML page on the server side in advance. It means you can do it with only vanilla JS.
Frameworks are just more convenient and they can speed up your development becuase they have solved problems you would likely encounter when developing vanilla JS SPAs.
Could we just revisit IFrames and fix them? Allow nesting, floating, modal... They could really solve some porblems. EG, before AJAX, I used to use a hidden frame, with a generic form that let me do data push/pull.
HOTTUB, SAUNA, JACUZZI...you are a genius 😂
Most SPAs are dumpster fires of frameworks that try to be all things and end up being junk. As with most things in life, the answer is a combination. The URL is king, if you can't share where you are and what you are seeing with someone else, then it's not web.
You're point about maintaining two applications in the MPA area is absolutely correct. Anyone who has had to deal with branding updates with the traditional MPA model understands the pain involved. It's equally easy to get MPAs wrong as it is to get SPAs wrong as well. The reality is that with highly scalable applications, the back end is served by a fleet of microservices that spin up and down based on demand. In order to manage the network load on highly interactive sites with millions or billions of users, it is of paramount importance to reduce the traffic over the wire. The strength of the SPA lies in the fact that all style and interactivity is self contained--and outside of the initial download of the JavaScript (which can be cached), we are only ever trading data between the client and the server. Whether that's in JSON, or Protobuf isn't what's important. It's the fact that we aren't sending potentially heavy HTML snippets (worse with HTML + JavaScript). I am interested in seeing what the Transitional App concept brings to this scenario.
On the desktoo, we talk about entry point. It's just that for websites, the payload to determine the entry point is made of parts of the URL, i.e., paths, GET params, etc..
Anyway, simply put: Noone wants to pay for great UX, they just want something to milk. Product managers aren't technically savvy yet don't let engineers drive the work.
I don't think it's single-page vs multi-page. Instead it's client-side vs server-side view state management. I've found over time that it's best to pull the state management back to the server in most cases unless you absolutely need instant transitions. But if the state changes it's generally good if the server finds out anyways. So perhaps a combination is the best bet. On click of a button it should instantly change color (or whatever), but the complex state changes should still have to hit the back end for the sole reason that there's a maximum amount of state you really want to send up front anyways. Lets say a table with 10 viewable entries. Paging forward should instantly give feedback with an initial small change and possible loading animation, but the query should only return lets say 20 results, the queued results and the viewed ones. A click should show the queued results, but still hit the back-end for the next queued results. Best of both worlds!
First, I loved this talk and I love Svelte.
However, saying that the anti-JavaScript movement is cultural and not technological really ignores the absolute productivity killing "features" in JavaScript, like truthiness and the ability to simply reference properties on an object that aren't there. This makes large projects simply unmaintainable. JavaScript isn't the DeFacto language of the web because it's useful, it's because it had momentum. I don't want to turn this into a JavaScript debate but that point in particular is garbage and Vercel isn't going to change that with their edge functions.
As long as engineers care about maintainability of large applications, JavaScript will always be an absolute risk to any program.
Great talk. I just think that web browsers are just javascript engines, so I disagree with arguments about js not working, that would just mean that you don't have a modern web browser. There is also web assembly as well!... SPA's are here to stay for a bit. I think its cool though that web startups are trying to figure out new frameworks that are even faster than current methods. Except I've never thought any spa apps I use are slow.
Man, you speak so well. It's so Zen like. I forgot that I was watching a video about web apps😂
My opinion: you should only make websites for the web, not apps. It makes no sense to make apps for the web in most cases, you should just make a native app for your target platforms when you actually need an app. I never knew single page apps were a thing until I got into web development and that's how it is for most consumers, they don't care too much if your site loads/navigates with a fancy transition or just abruptly. A common user expects the web to behave like a series of linked pages, we have apps to behave like apps.
"A common user expects the web to behave like a series of linked pages"
I have to disagree here. For people who have been on the internet for a significant time yes. But in modern times, the average user is on their mobile. Meaning its the other way around. They expect the web to behave like apps.
In this day and age for the majority of cases, not developing for mobile is a big mistake.
I don't like web apps either, but one reason for them is convenience. You Only need to make 1 platform, with a single code base. It would 'work' both on web and mobile. The alternative is to code a separate native app, with its own programming language, and nuances which would take time to learn (or you can hire someone to do it). Now you have 2 things you need to maintain. If you ever decide to update your app, you will have to update the site too. and vice-versa. All of this will cost time and money.
Native can be superior in every way to web apps. But their cost in resources and time make them less convenient than web app. It's as you said. People won't care how the website is made under-the-hood, as long as it works. If a webapp can get 70% close to a native experience, they won't care if their content takes an extra half second to load, or if things don't work as expected from time to time.
I don't think you realize how many things on the internet are 'apps'. This site you are using is an SPA. What exactly is an app anyway? I thought a website means something that is basically just html. An App is anything functional and dynamic outside of what is possible with plain html. I think you aren't thinking about this very well. An SPA doesn't have to do with routing, that's actually a 'weakness' of SPA where it actually mimicks regular routing to seems more like a website (otherwise the url would never change and you couldn't go back or forward). So I think you're confused if you think an SPA has to do with page transition. It has to do with having freedom for a site to have increased User experience and functionality. For example, compare youtube commenting with 4chan and tell me which is better. 4chan you have to reload the page to see your comment. On youtube it magically just posts in real time.
It totally depends on the page... you can't compare a company homepage with Instagram or similar.
I think about it that way: I don't build websites/apps for the web. I build them for the browser. I am constantly switching between devices and want to access my stuff from everywhere.... and every device nowadays has a browser with mostly the same standards.
Also that "A common user expects the web to behave like a series of linked pages" might apply to older generations ;-)
@@falias4 I don't think so, I'm quite sure the common user still can't tell if they are using an MPA or SPA because they don't care as long as its fast. Which is why most websites are still MPAs including very big ones like amazon, stripe etc but I do agree it can SOMETIMES make sense to make a web app like figma and youtube.
@@phee3D They can't tell because the developer purposely makes it seem like a normal site. It's also possible that a new form of site will be popularized in the future, and we won't have to make an SPA seem like a normal site. I tend to see this on some personal websites that have a very unique user experience. SPA basically allows for total freedom, which is going to be necessary for the future when VR / AR / metaverse type stuff starts becoming more popular. The idea of clicking links to go to a new page is going to seem extremely archaic in the future. I mean the concept of a 'link' in itself is just an invention for the limits of a particular technology. Hydration has the same concept of a link, except it brings in data on demand when needed, rather than all at once. Which is really the proper flow of data to user.
What a Lit 3.0 could really use however is just far less boilerplate.
Some people say “oh Svelte is most loved because it’s so fast and because it’s compiled blah blah blah”
WRONG!
Svelte is most loved because of its simplicity and it obeys KISS. This is a byproduct of being compiled. If you are going to compile, then you may as well make it expressive an intuitive. A purpose built language designed around a problem it’s solving.
I compare svelte to sql.
Svelte is to reactive web development as sql is to relational database querying.
You COULD use MS Linq to query a database if you hate yourself, but why? Why would you use a hammer on a screw?
And that is why svelte is most loved. It’s a purpose built language designed to solve a reactive UI problem, instead of hamfisting the problem with javascript syntax
First of all we didn't directly move to spa, people were using , they didn't like the boxes so spa came into picture.
Yeah after all it depends on projects requirement.
When I see SPAs I think this can't be what Tim Berners-Lee had in mind when he created hyperlinked documents.
Great video! I was talking about how awful SPA was 5 years ago when I was looking at companies for private equity.
I believe you an do some SPA/PWA stuff in a traditional way as well with a fairly minimal effort: Using ServiceWorker, and some clever navigation replaced transitions just by hooking into existing events you can more-ore-less imitate how a bloated webapp behaves. Like, there is even a callback for Custom Elements for adopting their state/render when they are moved to a different document. And that's today, not the proposal solution for page transitions :)
"Transitional" huh, maybe I misunderstood but this is how I always did web dev... Sometimes its better to ask for rendered html, sometimes just update the current page. I though it was obvious
That's a really interesting and thoughtful analysis. But somehow I can not stop thinking it is like re-inventing the wheel. Getting chunks of the page and the page logic is something we considered normal and common in the golden age of jQuery. Getting a modal content and form validator, a menu content and animations, a notification content and interactions was something very common 12 or 14 years ago.
Of course, the point of the multilanguage issue was a problem, amplified by the use of many template engines all over the place. Making portability a huge issue. In any case... As we all can recognize the need for SSR and the advantages of SPA... Why not to have Svelte (It could also be applied to Vue and React) working as a template engine instead of isolating itself as a SSR capability? I think current SSR support is the one increasing the gap here, not solving any issue (most of the time you could get away easier and faster with smart code splitting). It is fine if SSR applies for a number of cases and you can use it, but the real power tool will be to also include template engine capabilities. Imagine being able to parametrize every page load as you wish but from you business logic.
We have built an spa with no frameworks. Just the gridstack library. We have a c++ backend feeding data over websockets
I'm glad to see that I'm not the only neanderthal out there.
I can't talk about the modern problems of web front end so calmly and non-vulgar. I remember when computers would have more downtime between normal instructions than users would. It could be slow loading pages over dial-up, but it was way less frustrating than the finicky performance issues you mention where interface betrays expectations and fails to meet accessibility needs.
11:07 SPAs are just as affected by page load latency. Whether I look at a more or less blank screen or at blank UI placeholders because the SPA needs to load stuff for 2 seconds doesn't make a difference for the user.
The real performance issue are wrong priorities, and those cannot be fixed by technology. Until that's fixed (probably never) I will always prefer traditional web apps, because those at least respect my middle mouse button. I don't care what paradigm you use, if you ignore my middle mouse click or open a new tab in the foreground your site is a UX nightmare and you should feel bad.
Very inspiring stuff. For me doing a site that's not heavily interactive I've not considered going full SPA. But then again yes it as soon as we added an audio player it hurts that it can't persist navigation as it does in the app. So this mix is very interesting to me.
Rich is one of the most authentic people in the industry. Excellent talk.
Also, what is that VS Code theme at 17:40, I need it!
I believe it's the built-in High Contrast theme?
@@ThatsMistaTwistToYou Classic me, looking to add on something that's built in.
@@ZalexMusic :D All good - So many themes out there! I had to check my themes to verify what it was tbh!
My eyes were bleeding looking at that theme, interesting to know there are people who find it attractive! :D
I agree with most of what he's saying but SPAs still have their place and are very useful. They weren't designed for something like a blog or similar kind of website, but for more complex things like Google Maps, Gmail and Facebook Messenger, something more along the lines of a desktop app for you browser.
This talk it's really close to what I'm actually thinking in term of green computing
I think that a big reason for SPA is for control over the user. Some of the control is even stuff like anti-scraping. and annoyances to promote getting an account (ex instagram only showing a limited number of entrys)
Also with regards to playing media while changing pages, I think that's partially/mostly false, since it can be done with s. Am I missing something? because I'm no web expert, but I've definitely some some web coding.
Yay, s. Let's reintroduce the blink element while we're at it.
@@zendakkonestly though, framesets are better than JS imo. The only real arguments against them were the looks (which is nonsensical, because you can set the border to 0), the URL not being in the title (which is literally the same as for SPAs) and accessibility (which is a lot easier to solve than to hope for each SPA to get it right). So yes, I think we should bring back!
Good talk. I'm just wondering what's the difference between transient web apps and PWAs? It's overlooked but the P is for progressive enhancement which should cover most of the ideas here.
Too many SPAs fail to implement route serialization.
how's the incompetence of instagram devs an argument against SPAs?
@championchap I honestly don't understand how devs working at such big companies are not more capable. I've seen some incredible things from small and single dev teams that blew my mind. I'm not talking about those fancy portfolio sites that your pc cant even run, I mean actual functional, aesthetically pleasing and responsive websites that really set the bar for me.
I know it's probably not completely the devs fault, but crappy management that doesn't know what they're doing. But I still think they hold some blame
@@diamanteduul8084 Its called if it works don't fix it. The website will stay this way unless a competition becomes an issue
@@rafradeki Also, most developers in these big projects work in geographic locations where they have extremely fast internet, so they are never seeing the performance penalty their lack of ability is causing. 1mb is only a millisecond on a gigabit connection after all whereas for an ADSL user, that might take 1-2 seconds
C#, server side, not big JS fan developers here, and OMG did I love this talk. Been following Svelte for a long time and really think I will get out of my C# comfort zone once Sveltekit is released. Also, so many little one-liners in this video that made me laugh. Rich, you where excellent as always.
Why? Blazor with WebAssembly is very robust. At the end of the day all of these frameworks are just framework and run JavaScript underneath. Story will not change as long as JavaScript is what we are dealing with.
@@peymanstd Blazor is another one I'm watching as I am a professional C# dev, but svelte has so many nice little touches, and having Rich behind it and not feeling like a big corporate thing (just like Vue too) is an appeal also. Maybe it's as simple as wanting something different from the day job, so any personal project does not feel too much like your still at work :-)
it is released
Can we have continuous audio playing along with page navigation using svelte framework? If it's not possible, then it's a bummer.
Also what about Blazer and Web Assembly? Another interesting emerging way of building responsive apps.
I think MS has somewhat solved these issues discussed with Blazor wasm and Blazor server. Although istill evolving, developing sites using this technology is simple, fast and seems very reliable. I think the next release 6.0 (and maui later) will even add more to the mix bringing greater flexibility and capability. Of course all evolving/new technology has challenges in the early days but seems like this has a big future.
Great presentation. But I wonder if the "what if javascript is turned off" premise is valid? At this point we should safely assume javascript is present. all browsers of note have it.
Did you visit the website he mentioned that talks about this very issue? Turning JavaScript off is a great way to automatically block most ads, for example.
Pretty nice... I'll chime in with both of my personalities:
Traditionalist: you're not building the new york times and you don't need Transitional Apps Either. Sure you could build a SPA which isn't going to be found in Google and your business will implode under complexity...
Modernist: Are you even a real craftsman? Your app should be the best of the best and custom transitions add to the pizzaz, if your homepage is oldschool then people will leave and wont invest. Pizzaz/brand is even more important than correctness. Show the the examples of a successful 2023 startup that doesn't need javascript (apart from reddit/hacker news/craigslist)?
The most compelling argument for SPA to me is network resiliency. That's also what sold me the idea of Progressive Web Apps in the first place. Especially now that we live in a world where most users on the web are on mobile, with hasardous, very changing mobile networks. We all have experienced the timeouts, the Lie-fi, the server error pages, and we all hate it. Good SPA/PWA with smart service workers and synchronization logic actually bring back this feeling of resiliency and trust that we take for granted on native apps, but not on the web. Once we experienced it, MPA just looks too fragile in comparison. I wish server error pages and the browser refresh button to disappear in the future.
We are at a time where connectivity, latency, bandwidth, browser compatibility and device performance are magnitudes better than a decade ago. Why are we still having a hard time delivering consistent experiences? There's so much effort spent on creating tools and frameworks, to the point where doing things that are supposed to be simple and straightforward are ridiculously complex. Why is web application development so much more painful than they were, when the main problems back then no longer exist now?
@@imnoodlehaus I mean fundamentally the question would be why haven't you gone an developed an app that is providing a consistent experience without a modern framework? Every time someone starts down this road they run into a litany of issues with all of those aforementioned issues and end up creating a new framework. Complexity exists because delivering an application that works as well as it does on a train in East Sydney as it does on a desktop computer in sub saharan africa is extremely complex.
I'm not anti-Javascript, but the massive bloat from Frameworks makes me want to scream. JS can be small and efficient, all that goes out the window with frameworks.
You should seriously consider having a look at Svelte. Rich pretty much built the framework on that ideology.
Most issues you mention are already solved, and many of them have been for years. Most (if not all) SPA frameworks overrides the browsers forward and backward button. Most (if not all) can persist states between navigation, even between refresh and visit to other websites. The only real issues you mention are initial download size, yes 4-5mb is a lot, but is it really with internet speed today. And JS dependency, no JS no website. But really, who has a browser that doesn't support JS today. The real problem is the old technology the internet is
i dont think internet as a technology hinders anything web related at all, i think the real problem is that we want websites to be extremely dynamic, and javascript is just a reflection of that need, and that unfortunately means we have to deal with frameworks that enable us to have such diversity
@@WrittenInFilm But it does as you say yourself. We want dynamic apps, and HTML isnt build for that. Its like 50 years old technology. Css is so out dated, we have SASS and other Css frameworks to compensate. SPA is like a hack, to make web feel more like native app. We are constantly constrained by the old technology and try to find ways around it
@@diligencehumility6971 HTML is old, but HTML5 is not, html has come a loooong way since it's conception, in a good way, you can pretty much do anything in the browser now days, native apps still use tags very similar to HTML5, also modern css isnt really holding anything back in terms of development, these frameworks like SASS haven't been used long enough to receive universal support, CSS standards change over time when the world can see that certain concepts stand the test of time. In my opinion the only thing holding back SPAs and similar concepts from completely overthrowing many native apps is the fact that big tech companies like apple and google don't want the browser competing with the app store. Browsers could simulate an extremely native feel by default if OS designers allowed it.
If the URL could be guaranteed to represent the state of the page, then I wouldn't mind SPA's as much, but as you demonstrated on current, live sites, this is a foolish thing to assume!
Interesting video suggestion. Seems like a great part of UA-cam. The reality is that 1MB of compressed JavaScript is not a lot... not even close. SPA that implement even a slightly intelligent caching model are effectively installing on the first page visit. The speed to first user interaction debate rarely is honest about this fact. A SPA with a 10MB of JavaScript and basic caching will still load blazing fast the second time.
yeah seriously i don’t get what he means. that’s not a lot of memory at all. considering a lot of native apps on ios function through “app clips” or are offloaded from device when not used for awhile this seems to be the future
That depends entirely on internet connection and phone model
@@sigmachadgigamale True. But the unbounded scope fallacy is what a call what you just did there. I can win ( derail ) any discussion by focusing on the fifth 9. Yes you are technically correct. But your comment isn't helpful imo.
Depends on the country you are in, sounds like you are in a first world country and don't understand the issues people in 3rd world countries face.
@@mangelozzi Lol, I never said anything about what the right answer was. Just that it needs to be evaluated and define before a productive conversation can happen. Don't put words in my mouth.
Don't know why I got this recommended to me but it's pretty cool stuff! :)
EDIT: Oh wait... yesterday I was talking about HTML and CSS... I guess my android phone listened and now I get these recommendations here on UA-cam. That's quite scary to be honest... :-/
Follow IETF standards on URL structure.
Have a data layer.
Accessible so you / the entity your working for doesn't get sued.
Very helpful if custom events are thrown by the SPA upon the users Primary CTA, rather than a series of listeners.
All I ask, but these seem to be HUGE asks.
I don't get it: I went to Pinterest, visited some image A, then clicked to an image B there. I clicked the Back button, and I was on image A as I expected. Why would you say this doesn't work?!
Lot of good stuff in this talk, but a few issues as well. Regardless, I'm not going to spend development time implementing progressive enhancement for users who opt to turn off JavaScript. They're just going to have to enable it if they want to use the web.
How to tell me you're a terrible web developer without telling me you're a terrible web developer )
@@custardcream2226 Supporting users who've disabled JS only matters for things like big time news and blog sites and should be filed away next to IE10 support in the list of priorities. Ironically, if you weren't aware of that, you're probably not a very good (or at least very informed) web developer yourself.
Btw, you did the meme wrong. You don't need the "how to" at the beginning.
"here's something you can't do in a traditional app: you can't navigate from one page to another while playing music"
Use frames
I think we can do it with the new picture in picture api too, but never tested it. :)
Why is it hard/impossible to return to where you where scrolling on a list with multi-page apps? For example scrolling through some posts, you click on one but when you navigate back a page, you are sent to the top of the posts list, rather then where you where moments ago. I always assumed you could just cache some value of where the user was on the page.
I think some of the failings in SPAs you are highlighting are due to poor design and implementation by the developers than the technology itself. However, you do make some good points.
I agree with this
exactly
At what point is the massive complexity of the technology itself partially to blame for developers failing to implement it well?
@@jacobstamm there is also the problem that, the more complex the web page, the harder it is to keep it consistent. More bugs, more use cases not covered, etc.
so, even if the technology is simple, the software to build may be the complexity that ends up bringing the end product to a bad implementation.
Just the amount of paperwork to keep it all consistent leaves error margin
What's old is Transitional again. We already used this around 2000.
SPA is better at reducing server costs, and SEO works great with it these days. With code splitting you can get the initial load to be pretty fast, not ssr speed but not so bad. Most users wont even notice the difference.
As for your "terrible things about SPAs" list, doing SSR doesnt get rid of those things, it just moves it to a server that you have to pay for. I have made fully accessible sites with SPAs without any problems, so I just feel you are grasping at straws with this list...
i freaking hate middleclicking a link and it does nothing or opens an essentially empty tab
Wait how did the Todo list continued to work without javascript ? I didnt get it
It's worth mentioning that a SPA can have great performance and accessibility. Some peoply probably think that that's not possible.
Definitely possible, but it takes effort. To echo what was said in the keynote, if people are forced to think deeply and make choices about something then it will frequently not get done, or will be done wrong. If we can reduce the effort or eliminate it then it will be the best for devs and users.
@@captenK I disagree. The performance problem of SPAs mainly comes from too much JavaScript. It's probably a lack of awareness and/or care from the developer. It shouldn't be too much of an effort to pick small libraries such as Preact.
On the other hand, implementing progressive enhancement, that's what takes effort. You have to create a base experience, test it, make sure that it works and is accessible, and then on top of that, you have to implement the enhancement, and again, test it and make sure it's accessible. I'm not saying "don't do this", but it takes effort.
That base experience is O in SOLID and u need to have codebase that u can swap on fly, and locking with something like react, preact whatever crap u just monkey patching, doing nothing. web is sick at sea for years and years to come...
yeah with like 8000 libraries and plug ings...
@@BobbyBundlez You can make a SPA with Preact and Preact Router. You don’t really need anything extra for accessibility.
How come no one is talking about web assembly anymore? I am not a web dev, just curious were that thing went.
It's useful for CPU intensive work. E.g., games (Unity).
It's still around but I think the hype has died down cuz its not a new thing anymore.
no. heavy ads did.
2:08 - "I could be wrong..." - I think you are. Multi-language development has been the norm for 20+ years. Today, we have lots of Python and Go and some kind of traditional language (Java, C#, etc.). The server-side code will almost certainly have a lot of SQL - the native language of databases. I've heard the song of "One Language To Rule Them All" too many times. I think you are wrong on this.
One language to rule them all... and yes, let's choose the one that was witten in 10 days. Sure, what could go wrong.
I am confused about the About site. If I click on it, every other client site state will be lost, because it is like a traditional navigation by requesting a new page?
2:45 - seeing the list of SPA drawbacks, all of which are mitigated by a certain compiler - Svelte ad incoming!
8:02 "We already have a sea of acronyms." No, you do not. Most of those are initialisms. SSR, for example, is not read as "sesser," so it is not an acronym.
Yep. This explains the problem pretty well and why fighting the javascript stack is simply impossible without google doing the work DIRECTLY in V8
so good! love the evenhanded approach Rich
I feel he could speak eloquently about anything tbh - what a guy.
thanks for creating and sharing this video. A bit too techy at the end for me but the beginning was very usefull in understanding the pro's and cons of MPA vs SPA.
"Web is the only place that is considered normal" Hate to break it to you but that is very normal in desktop applications. VB frontends with C/C++ backend libraries and engines in Windows in major apps like Office, and Mac has its own versions of this model.
If you go back in time far enough, terrible practices will always be the norm. I think it's safe to assume he was talking about modern clean codebases and not some VB code from 20 years ago