Have Single-Page Apps Ruined the Web? | Transitional Apps with Rich Harris, NYTimes
HTML-код
- Опубликовано: 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.jamstackconf.com 
Наука
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.
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.
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.
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
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.
JavaScript to the internet is the equivalent of building your home on quicksand
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?
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.
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
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
What a terrific talk! Very well-balanced and even-handed.
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
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.
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.
Great video! I was talking about how awful SPA was 5 years ago when I was looking at companies for private equity.
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'm only 5 minutes in and it's rare that I actually feel thankful for information in a video anymore. I appreciated this
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.
Everything you say feels perfectly obvious after hearing it. There’s something magical about that
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.
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.
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.
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.
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.
Pretty sad all this human talent and resources is being wasted on all this stuff that is largely unnecessary.
Great talk Rich. Clear, even-handed and good acronym jokes.
What an awesome presentation, well done Rich Harris! 👏👏👏👏👏
Can we have continuous audio playing along with page navigation using svelte framework? If it's not possible, then it's a bummer.
Man, you speak so well. It's so Zen like. I forgot that I was watching a video about web apps😂
Does anyone know if there is anything remotely similar happening in angular dev? I have been looking a good partial hydration solution for years.
HOTTUB, SAUNA, JACUZZI...you are a genius 😂
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
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.
Great. Loaded with great analysis, rhetoric, and... empathy :).
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.
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.
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)
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.
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.
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 RUclips. That's quite scary to be honest... :-/
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.
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?
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 :)
6:25 Doesn't that depend on where the javascript is executed? Like in the header or at the end of a page?
to a point, but if your site needs interactivity the page still doesn't finalise loading (for instance if you have sockets, or ajax requests etc) until all the scripts have run, so it doesn't make much difference.
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.
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.
When I see SPAs I think this can't be what Tim Berners-Lee had in mind when he created hyperlinked documents.
Hell yeah, I loved this talk, I've been building a todo app with Svelte and I absolutely love it. Everything you build just makes sense. Slotting components, it all feels amazing :3. It all just works too well and is by far my favorite tooling for building "transitional" apps :)
Svelte is nice but no Observable built in natively just feels outdated.
@@LarsRyeJeppesen isn't store API basically compatible to observables?
@@LarsRyeJeppesen isnt anything starting with $ an observable ? . And, you can code your own observables if you want ?
I can't hit the Like button hard enough on this video. I agree with this whole-heartedly. Great point of view!
Interesting talk. I fully agree with the importance of edge computing. But why Sveltekit still doesn't have a lambda, or even better a lambda@edge adapter?
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.
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.
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.
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.
so good! love the evenhanded approach Rich
I feel he could speak eloquently about anything tbh - what a guy.
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
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.
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.
Wait how did the Todo list continued to work without javascript ? I didnt get it
well said :) framework fatigue as well
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)?
what theme is Rich Harris using for his VS Code!?
Does anybody know whats the vscode theme he is using?
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.
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.
This talk it's really close to what I'm actually thinking in term of green computing
"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
why is the production build contains only a JavaScript files (no html at all)?
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.
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
What would you pro guys recommend for online shops with around 200k products?
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!
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.
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 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!
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.
2:45 - seeing the list of SPA drawbacks, all of which are mitigated by a certain compiler - Svelte ad incoming!
Many thanks Rich for such a thought-inducing tube
yeah rich nice tube
I wish it had more slides to help following some points
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.
Amazing talk Rich! Now excited to explore Svelte Kit. #transitionalapps
dude did you film it on siemens?
18:09 wondering what is `progressively enhance form submission`
Progressive enhancement refers to when a webpage is designed to work properly without javascript, but then adds additional client-side features when javascript is enabled.
JEa, i made my first webpage that went to production back in 1995, worked like a charm. Lately i made 1 page app, took about 200kB. Maybe there is some optimizations learned from C64 coding. And now i'm back doing some oldskchool thingies for money, daemn, i would like to do something new :D
And yeah IMO js bloat is because people who do javascript coding do not know how computers work.
"js bloat is because people who do javascript coding do not know how computers work." - Truer words have never been spoken. I really wish we could get people to stop hating Javascript for not being Java or Python, and get them to actually *learn* how to use the language correctly. It really is the best solution for the problem it solves.
Too many SPAs fail to implement route serialization.
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
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.
That was a really great presentation!
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.
Definition of TA: An TA is a MPA that looks like a SPA.
Umm, so the best website is a SPA because those who do MPA want to look like a SPA and a TA is just a substitute for a SPA.
I have to keep thinking about your idea a bit, but for now I will continue doing SPA for the next five years ...
Which does not mean that I change my mind in the next five years;)
Loving the video
Damn you might have just got an another Subscriber
Got my sub. I haven't dev'd in web since we used tables to lay out windows, before css even, crazy. Now that I'm back, and intend to stay back for what could be the last few chapters of my career (I will die at some point...) the issues you bring to light are things I've seen in quite a few different flavors. And while some of it was over my head (I haven't started with JS yet, working through html/css completely first) I liked what I saw with Svelte. Case in point I set up a test bench today that utilized a full web (single page) interface to run the testing. There were quite a few cringes, and though I've got some time to work through ALL of the issues I could see immediately that some of them will just "be". Not acceptable. My intention is to specialize in apps (as opposed to web pages for marketing, etc...) and while I may land in the back-end (i'm a systems guy, for years) first I want to completely master the front end then I'll go from there. Anyway, great presentation, a lot to digest. Thanks!
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!