Комментарии:
Enginee Over Red b/s
Ответить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!
ОтветитьWeb development has become over complicated.
ОтветитьYep. This explains the problem pretty well and why fighting the javascript stack is simply impossible without google doing the work DIRECTLY in V8
Ответить"I want to be free of design constraints!"
"I want predictable browser behavior!"
Think a bit deeper.
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.
With that hairstyle when he says "come to jesus moment", I am sure he is referring to himself.
ОтветитьThis mans talks are 🔥
Ответить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)?
Great. Loaded with great analysis, rhetoric, and... empathy :).
Ответить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
ОтветитьBrowser Applications Supplying Thorough Usability?
ОтветитьErlich Bachmann created Svelte?
Ответить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 :-)
ОтветитьHOTTUB, SAUNA, JACUZZI...you are a genius 😂
Ответитьwho says you need js framework
Ответить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
ОтветитьIdk, but spa with svelte-spa-router is just awesome
ОтветитьHTMX or UNPOLY came to our rescue 🙂
ОтветитьOne more hitch that was frustrating is that extending the Locals interface from /app.d.ts did not work, it kept complaining that properties I just defined do not exist on App.Locals, after a good hour of googling I found that I need to wrap the App namespace declaration in "declare global {...}" and it magically worked. Not sure why that is needed, but it would probably be a good idea to have it wrapped in "global" by default as many might give up on Svelte when they encounter this.
ОтветитьI like this guy.
ОтветитьThat was brilliant
ОтветитьIs this Chris from common creations Dick's sporting goods sponsor because he's all starting to make sense now you guys threw me out of the company and then you tried to say because we were partners caught on quote they give you the right to the access to things that you did not know were government and federal bound... Can't wait til they go down for their actions
Ответить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.
very nice, I like.
ОтветитьBrilliant 👏
ОтветитьBeen thinking of this, interesting
ОтветитьAlso I don't understand the random hate for JavaScript? I get it's still not seen as a "grownup" language like Python or Java, but the flexibility and versatility of what you can do with a good grasp of JavaScript are astounding, and not just in web development.
Ответить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.
ОтветитьNice to see Erlic Backman take time from smoking opium in china to give us a tech talk
ОтветитьJìan-Yàng!!!
ОтветитьExcellent.
ОтветитьI could find you so many badly designed ‘traditional’ MPAs. You just picked out a few oversights and badly implemented features of specific SPAs. ‘Ruined the web’ lol stfu man. You’re also so pompous about i urgh cringe
ОтветитьErlich ???
ОтветитьAnd how about no freaking framework??? Just build something tailored to your app's needs with what's available in HTML, CSS and JS/TS, that's a new (old) idea.
ОтветитьAnd WASM?
ОтветитьImagine if the universe said... "this matters".
ОтветитьSo much talk, this is a waste of time. Just use whatever you need to satisfy your clients. Its a free world.
ОтветитьThis guy. Listen to this guy, he's an arch mage.
ОтветитьWhat if we do webapps like android apps? Let me expand: binary files, they use the browser GUI lib (jetpack compose like API) any language can compile to this binary format (webasm) and thus we get faster to download apps, we can use any toolchain we want (more tools available in any language!) and thus better web!
ОтветитьWhen "webmasters" became "engineers" and "engineers" decided that "front end" and "back end" were two separate things some butthurt little boy got tired of the "back end" people picking on him for making things look pretty and set out to make the "front end" more complicated and convoluted than device driver development in retaliation. That butthurt little boy still doesn't understand CSS so he keeps on inventing new ways to avoid having to learn it or use it properly.
Ответитьawesome. I"m sold.
ОтветитьI liked the video, and I prefer Svelte over all the others frameworks I now… but it’s true that most of the evil in modern webs has something to do with Javascript.
Ответить