Welcome to Jamstack Conf's RU-vid! A collection of video resources for learning about the Jamstack architecture and building modern websites and applications with better performance.
@@raccoons_stole_my_account If you are so sure SPAs are bad, don't worry about it, just ignore them and don't learn. If you are right it will have no impact on your career, but if you are wrong (which I believe you are) then you will struggle to get/keep a job.
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!
Really nice presentation. However I have been struggling a little bit setting it up. I am still trying to understand the structure of how Tina files and code parts are embedded in my Hugo project. What can/should edit and what not? This presentation shows that, the guy edits some code, but I cannot see the pattern of the structure of files.
About 15 years ago it was not clear that the web would survive native phone applications. The best options for truly interactive web applications were using things like Macromedia Flash or even Internet Explorer specific web extensions. Native phone applications provided far better platforms for fluid, interactive experiences, so it seemed like the web would die. In response, we developed SPA frameworks, AJAX and client-side dynamic JS-controlled rendering, starting with virtual doms and progressing to what we have now with observer frameworks. All these developments saved the web by transforming plain HTML into a medium that could deliver rich interactive experiences to rival native UI development. At this point, not only have SPAs in general saved the web, they've also taken over native desktop application development: many companies are rewriting their desktop GUI applications from Qt to Electron apps. And shockingly, far from becoming slower and more bloated they are often faster and more responsive despite the massive Electron overhead. I'm waiting for the talk where someone actually addresses the people in power: browser vendors, Google Chrome etc, and demands better accessibility and better graceful degrading from them, rather than demanding developers magically be able to change the way they have to write code to make a living. There's no reason why Google Chrome couldn't adjust to SPA's and JS-driven applications, and bring better accessibility to that world we've actually built.
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)?
Way too dismissive of the LiveView-style approach. The vast majority (and I mean literally 99%) of website needs are covered by it as it exists today. And there is no theoretical limit to the approach. Sorry JS devs, but we just need to get JavaScript out of the driver's seat here, and flip the script. Use as little JS as possible, push more into the statically-compiled browser core, and ship as little state as you can back and forth. LiveView is the way.
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
If anyone has had to work on pages at big businesses with multiple technologies going on, you can appreciate non-frameworks, where there’s no monolithic tyrant piece of JavaScript trying to control everything. Inevitably, no matter what it is, that thing is going to go on life support. And when that entire page oppressing tyrantscript dies, it is a painful process. When a web component dies, the pain is very manageable. That’s something I think every framework needs to ask is how easy is it for them to die.
I’m hitching my wagon to Lit web components because you can inject them into any framework and they are responsible for themselves. They’re like mini-sveltes and there’s nothing you can do about them. Not even blazor pages can prevent them
Lets face it I accept JS but the language design decision in it are terrible which is why we use duck tape it with frameworks. python and ruby are much better designed languages and if they were implemented by browsers we would see a sharp decline in JS. SPA are the way forward so JS will balloon. But please lets be real JS is not cool. Svelte however is a great step forward :-)
Yep.. I thought SPAs was the next biggest thing and all super efficient. Did my website with nuxt 2 and vuetify and BAM.. Shoot in the foot, was way worse then my previous PHP version. Thank god Rich Harris is making my knowledge on this usefull lol
if only the pricing model was a bit more affordable for B2B use cases, i definitely would have chosen Clerk. it is too costly right now to create a personal org for every user who signs up to my new app
