Відео

That's subjective and you have a right to dislike the look of the syntax, just as others have a right to like the look of the syntax. However objectively the type signatures are like that because they encode and pack a lot of information. Often time it boils down to familiarity, and it's no different to dynamic language users complaining that they don't like static types that have to be declared as it's too "noisy" or verbose.

I have an entire blog article dedicated to it: "So you wanna learn Rust?" link is here 👉 watthedoodle.com/tech/so-you-wanna-learn-rust/

@@watthedoodle Thanks!!

When I finally sat down and really got to understand how ownership and lifetimes work, I found it far mor easy to write Rust. Also go check out these resources: "The Rust Book" - Safe Rust guide "The Rustomnicon" - Unsafe Rust guide "Learning Rust, With Entirely Too Many Linked Lists" - This will help you understand how pointers work, and why LL is a shitty data structure, especially in Rust

Start with sync code. And switch to async later if at all.

i disagree. you should but not for production code, just for personal learning projects

​@@ballinlikebill8334doing it for production code is what "learning on the go" means. Else it's just "learning"

There is a *lot* of open source projects, while there maybe some FOSS communities that are not welcoming it's hard to generalise across *all* FOSS projects. Of course some level of communication is needed and this applies to *ANY* project or team you work on, so I don't understand why you're suggesting this is a problem? There are many internships from companies where you *do* not get paid, for companies this is a much lower risk with lots of advantages including the potential of hiring the intern at the end of internship because it would have given the company and the candidate time to learn about each other as well for the candidate to come to understand the companies codebase etc. Could the internship be exploited? yes, but at least you will know that it is a toxic company and you can just walk away, something that would be much harder to "walk away" if you where employed by that toxic company. Universities (at least in the UK) do NOT provide networking opportunities, I know because I've come out of academia into Industry and it was the *MOST* painful journey to cross, and my story is not unique.

I didn't recall that meme! if it is a meme that wouldn't have been pretty cool to drop an overlay on the video to pay homage to it 😁

At scale and at high RPS it does not scale sorry that's a simple fact. Given that SSR can mean having to re-render the entire page, this includes all the conditional logic and looping structures etc. Perhaps on the smaller scale it's negligible, but it really really isn't when you work at scale. And it turns out if you invert and delegate the computation to the client side that template computation goes to ZERO for the server side, and it's hard to beat zero.

​@@watthedoodleHow many are we talking about here? I need some valid numbers argument. Depending on the interaction it does not need to be fully server-side, it could just be when doing action that is only changing data (yes small js libs can be use for interactivity) and at that point i would argue the lifting is done more on the database side, which is another topic on itself. On the other side, most large application relies on microservices to run their API, this is scalable. But most SSR application mentioned do their scaling the same way using pods, replicas, load-balancing, etc. Why can't we make the same argument? Either way people seem to forgot the DevOps side of things, there no ZERO computation, you are always doing it somewhere, does not REDUCE the amount of computation in any way. The example shown is of course on a small scale where they are in one place, which should not be done on a large scale application (still, how large are we talking). Either way both are complicated, and i agree it should not be simplified.

@@zulfiqrysaadputra Because using client side rendering you wouldn't even **need** to scale the server side, that's entirely the point of CPU delegation.

even with more efficient languages it still doesn't solve the problem (it may buy you a little more headroom but that's it). Inverting the entire things does, because now you're essentially doing distributed computing by offsetting the computation over to *each* client, that means it doesn't matter how many extra clients requests you have your computation becomes (Computation * Zero) which is always zero!

@@watthedoodle I am not a designer or webdev by trait, I run that stuff. On a huge scale. And i do so since 20 years. I had customers, that moved to SPAs, and client side rendering. And guess what: The load difference on the servers where not measurable. But why is this so? Because rendering a HTML Template or crafting JSON from the same data does not have a large computational difference.

@@tbethenerd they're are *not* the same, one is transformation of data representation that is only minor structural changes (see XML -> JSON etc), while rendering full templates, include full on conditional elements based upon expressions all of which is infinitely nested along with loops etc, these are not the same. For simple templates and at small scale the difference will not matter, but the principle can not be avoided, whatever that computational load is *will* be multiplied with every client you add, and by scale I mean the total concurrent RPS.

​@@watthedoodlethis is where you start to go horribly wrong in your thinking Running data through a template to generate HTML is orders of magnitude less work than converting data to json The HTML template expansion can be done using no additional memory allocations. Transforming any data to json requires allocating strings for every element, converting numbers into strings, deallocation after use, etc You could roll out 100 HTML templates in the same number of clock cycles as doing 1 json payload

you don't need to "synchronise" state, http is idempotent. You simply "fetch" the client specific state that you need as and when you need it. All state is localised client side and is specific to each client instance. For you second point, yes while you *could* potentially have that strict segregation and use internal data "APIs", you still haven't the computation tax issue.

@@watthedoodle I will agree to disagree. Firstly, http is not necessarily idempotent, but even in the case that it is, state is not localised on the client side since you still have a database on the server side... when you update the server side database with an idempotent http method (let's say you DELETE a product listing), that change will in many cases, also need to be reflected on the client side, hence the need for synchronisation

@@byrongibby that DELETE request can either succeed or fail. If it fails then no need to update the current client state, if it succeeds then you can safely remove that data point from the client side. In either case navigating between "pages" will automatically load the latest database state anyway. Unless you want 100% seamless realtime state view across all clients in which case you would need to either use WebSockets and push out an the latest data point upon edit/delete/new OR use something like long polling OR server push etc. But this reload will be EXACTLY the same for SSR, the difference being with SSR you would have to refresh the entire page, whereas with SPA you would only re-fetch the changed data set. So actually it still wins out in terms of overhead.

@@watthedoodle I buy the argument that front end frameworks distribute the compute making it a more easily scaled solution, but to the point you just made - if you're using something like HTMX you aren't doing full page reloads. On the question of state, it has been my experience that you have your server side database, but you also have an in-memory database on the client. The DOM/view is updated as the client database changes - that seems to be a solved problem, the issue as I see it is comes from making sure the client side database and the server side database are kept consistent with each other. If you're saying that this is easy for you to do correctly that's fine, but I think a lot of people find it quite challenging.

@@byrongibby why would it be challenging? as long as the database is the SSOT (Single Source Of Truth), then the Client is simply the presentation of that state. The client also makes request's *to* the database in order to request mutations. The data flow is well established here, there is nothing to "synchronise", at least that's how I approach the design and data flow.

Thank you for you kind words, I really appreciate it and it motivates me to create more stuff!

I literally provided the reasons as to why he is wrong, please re-watch carefully. I re-iterated the points throughout the video as well. Almost everyone else has understood the points I raised against Andrew.

Thank you! Absolutely agree the JS fatigue is real and I have found Vite to be a breath of real fresh air, and that's the positive direction the ecosystem needs to move towards, I think I may do the next video into vite!

Very good point here regarding SEO, that is indeed on key legitimate criticism of SPA, there has been some solutions in this area, as you may already be aware there are solutions such as Nuxt and Next which can do isomorphic builds, but that's another rabbit hole!

This video response wasn't to say we need a single solution, you're absolutely correct we *should* use the right tool fort he job, and what I'm arguing is that SSR for web applications is *not* the right tool (for all the points covered). If however you don't have a web application and your site is static, then I wouldn't even SSR or SPA is the right tool in that case SSG would be the right tool.

Might you be speaking too broadly? For my part, I lament that we are still locked into JS.

If I'm speaking broadly it's because it's broadly the truth. Sure there are exceptions. And we all know there are drawbacks with JS, I'll be the first to admit it. But the solution to that isn't going back to the same old design patterns we had 10-15 years ago and solved with JS component models. It would be like if we said "there are problems with cars" and the solution was to bring back horses. The reason it looks like such a convenient solution is because it's just regression.

I think current solutions like Sveltekit are basically perfect.

Single page applications are peak web dev.

JQuery or more specifically shitty jQuery has cost the business I work for about $2,000,000 in developer pay fixing bugs over 10 years and it's only 12 unique pages with the home page, product listing, search and product page being the most complex. Some members on my team were tasked with "updating" the existing product page built in 6000 lines of jQuery spaghetti. They had 3 months. It took 9 months until the defect list grew larger than the actual tasks, then 16 months until the project was scrapped and they were both fired. They handballed it to me, I rebuilt the page in 4 months using Angular. It's been live for 9 months without any critical issues after release. Sure you could make a nice enough webpage/site with HTML and jQuery, but I've never actually seen it in the wild. There are no standards for it's use so different developers do whatever they feel like at the time, some use the revealing module pattern if you're lucky, some global objects, most just free functions in a massive file, generally just hacking exponentially to make things work. SetTimeout's everywhere to deal with race conditions, functionality that overwrites other functionality. Events that are never unbound except occasionally you will see `$el.off().on() It's hard to debug so average developers just hack on whatever they need to get a story complete. Modular componentised code that follows single responsibility as much as possible is always going to be the best solution, but more importantly having standardised practices for average developers to follow and documentation they can read is the biggest benefit to modern js frameworks.

@@ivan.jeremic which is why everyone is so unhappy with them and the quality of most apps is terrible / rapidly declining? SPAs are "Peak" in the same way that server-side MVC frameworks were "Peak" 3-Tier. Both are bad ideas that caught on before the industry could actually evaluate the efficacy. By the time anyone realized they were bad ideas, everyone was doing them.

thank you for that clarification, I misinterpreted he's point in that particular case.

I partly agree however speed has to be seen in totality, meaning it is not just the speed in terms of the initial development time, but rather the overall "speed" aka time involvement over the course of the lifetime of the platform or solution that has been developed. You will find that a platform actually spends the majority of it's lifetime in maintenance and updates (newer features etc). And in that context having a more powerful type system that can more correctly mitigate a whole class of potential problems means spending less time on said maintenance and ease of rolling out newer features and doing refactoring to the platform. So it's *not* just about security there are other considerations and must be seen in the wider scope.

​@@watthedoodle I also agree with your point, well said!

Right, I choose htmx 😂

Thank you sir for the kind words, I'm happy you liked it!

Freudian slip? Is it "Fanatic" or "Fantastic"? Lol

Sure I hear what you're saying, however I don't fully accept the "added complexity" part as that was one of the points raised by Andrew and what I'm suggesting is that in actual fact one doesn't even technically need a front end framework and yet still be able to fully do a SPA with ajax that doesn't rely on mashing the data and UI code on the server side. In fact you can watch my earlier video where I pretty much do that using Hono + Deno that has ZERO JavaScript build tooling, dependencies (client side) and zero frameworks, just raw JavaScript etc. Having built many modern production sites, I don't agree with this assessment that it's complex to maintain, are *some* frameworks overly complex? Yes that part I will absolutely agree with (I'm looking at you React!). But we shouldn't tar all frameworks with the same brush as that is unfair and incorrect. I would suggest that using Vite + Vue will be dramatically more productive than doing SSR, I know because I've done *both* commercially multiple times, and I know which one I pick every time and it's *NOT* SSR.

90% of sites you use on daily basis are built with heavy frontends. What ppl was creating decades ago is not relevant anymore

Thank you I'm glad you liked it! 👍

my GitHub account is displayed in the video footer. It's github.com/watthedoodle/ If you mean the specific repo used in this video session then that can be found here: github.com/watthedoodle/toy-html-builder

Glad it helped

thanks Bob! we can create fork bombs in the shell, but that's because the shell can spawn a new process, sadly HTML is interpreted and static so we can't create the equivalent or at least to my understanding it can't be done! 😆

oh nice, not heard of that, thanks! I'll look into it

Thank you for you in depth comment! While I do agree documentation is important, the issue is the first build will always be guaranteed to be wrong, this is because the problem space is *not* initially understood and things evolve as we explore the problem space. Therefore focusing on documentation first is not the correct approach as that assumes one fully understands the entire problem upfront (which we do not). But for sure documentation *after* one has an actual working platform is indeed important. Regarding juniors running wild, that is a different topic about project leadership and developer management and a good lead would nip that in the bud, but that is one for another topic. Also "correctly translating a client's wishes" that right there is actually the issue, part of the original Agile manifesto explicitly states about "customer collaboration" meaning the distance between developers and customers/users should be zero, it is precisely *because* we have all these intermediaries that all the miscommunication happens in the first place, and no amount of "proper documentation" will ever solve that. You will learn so much more when you sit right next to your customer and observe how they interact with your platform then all the documentation in the world!

​@@watthedoodlesure the first build won't necessarily be right but I have always put documentation first and I have been able to actually document how the interface is going to work and put it in front of users and get feedback so that we build a better tool before we ever start coding. If you do good documentation and make sure that it's done in a way that it gets in front of users early so you get feedback to refine and perfect the documentation then you will spend less time coding and you'll get closer to the target on the first build. I have been building software this way for over 25 years and it works really well and I get things done really fast and you need to do good documentation first that way the build goes really fast and everyone understands it and it's clean code and it's closer to the mark the first time we all need to get away from this stupid dichotomy where it's only waterfall or only rapid code and it's nothing in between because it's the place in between where sanity lies.

@@aaronbono4688 sure I agree, however from your description that sounds more like system design than documentation. But we may be arguing semantics at this point! I absolutely agree regarding system design which is very important in any build so we're are on the same page here. What I'm against is the the endless documentation with the expectation for everything to be detailed down to the last dot before anything is ever built, I don't agree with that approach! I high level design, schema design, major building blocks those are all you need initially to get going in my view. For the record in total I've been building software for around 22 years (so just a few years fewer than yourself) 😄👍

@@watthedoodle so again it comes around to getting away from these discussions of the extreme waterfall versus the extreme dive head first into coding and start discussing the sane and effective middle ground. No matter what the topic these days we keep getting mired in discussing the extremes and we have lost sight of the fact that we live in a world of spectrum where there is plenty of middle ground.

@@aaronbono4688 Yes I agree there is a middle ground, and I think that is captured well in the original Agile manifesto, so it doesn't say "no" documentation and planning, because those are the values "on the right", it just advocates to try and focus more on the left (hence the spectrum). If others think "oh the left means no X" then that is also a false understanding of the original agile manifesto.

Thank you for you comment. With respect sir, that is absolutely *not* the conclusion of this video. In fact it's the complete opposite. This is clearly understood if one watches the full video.

ah yes you're correct because the function is a comparison which I didn't do. Yes thanks for the correction. Yes it's mutable and has side effects, I didn't want to tackle that in this session as I wanted to focus on the procedural vs declarative. But you're correct, it's best avoid mutations as far as possible, of course in some cases it's needed and certainly locally scoped mutations are fine.

Thanks for the feedback! noted. I will look into ways to improve the experience for mobile devices 👍

absolutely yes, I just wanted to add my "Yet Another Fetch" YAF 🤣

morning Bob! hope your day is going well! thanks for the kind words!

Loaded up on morning Coffee and ready to go! thanks Bob! 😁