Видео

Thank you!

Right into the feels! 💔😄 Wear whatever you want 😉

What a crazy complement! Thank you very much! 🙏

Absolutely! But it will take a few months, I have a bunch of other topics planned first. Thank you for the compliment and the suggestion! 🙏

Appreciate it! I like shooting outside because we are inside enough as developers haha

You're welcome! 🙏

Thank you! 🙏

I have the privilege of working with the best when it comes to style 😉 Thanks!

Thanks so much!

A few of me were, yes 😉

Absolutely agree. I said at the end of the video that the examples in this video are contrived and optimized to be understandable. I disagree that OOP coder is easier to test because by default class inheritance is the tightest form of coupling and frequently requires mocking. But if you have good examples for OOP code that is easier to test than pure functions, please kindly point me to it 🙏 And regarding performance, IMO you should favour readability over performance UNTIL performance becomes a bottleneck. I can't speak to those other languages you mentioned because I'm specialized in JavaScript.

​@@JanHesters Easily testable OOP code honestly follows the same guidelines. Given the same input, you should get the same output. The thing that tends to get people thrown off is that with OOP and stateful classes, you'll have adjusted one of the inputs if you run the same method twice. In order to replicate the same thing you also need to replicate the class instance. Just with a really basic class (pure garbage I'd never write normally, so sorry about it being a bad example): class Addition { value; constructor(initial) { this.value = initial; } execute(value) { this.value += value; return this; } } assert(new Addition(2).execute(2).value, 4) would be 4, every single time you run it; same as FP. If you chain it like new Addition(2).execute(2).execute(2).value then you've fundamentally changed what it does, just like FP. Same principle, different execution. The class example is extremely stupid though, wouldn't write code like that normally, state is best stored in DB regardless. One of the benefits to using classes in JavaScript is that while it looks as if the objects all have their own methods, they are all only allocated once, which is a major benefit to anonymous functions added to objects which need to be allocated every time. This is not as important now with imports and exports being a thing, but look into how stupidly much memory is used in a regular application due to all of the object nonsense JavaScript injects since it needs to treat everything like a nondescript object. That's not the case in Java or C# for example, where they only keep the bare minimum to identify the class. As for why I think a lot about performance, it's because I work with larger datasets frequently, so I have to walk the tightropes of readability and performance a lot. This is true for both backend and frontend things; where updating/inserting 50k DOM elements is hell and takes ages even in a best case scenario, whereas remaking the entire HTML structure as a string and replacing all of it takes a few seconds. However, it only takes a few seconds under the assumption that I reuse memory through not allocating anything extra. This means reusing variables and pre-allocating memory as much as possible. I do enjoy FP though, I reach for it whenever possible, but only when I can afford doing so. I never do anything particularly crazy with it either, but the idea of passing functions to other functions is something I use regardless of FP or OOP. Command pattern is just that. The Addition class I gave as an example would be one of the classes one would pass to something that processes it. Somewhat unreadable, but with enough complexity in the business logic, it's totally worth it. Sorry about the long reply, not sure if you're going to read it either, but I hope my sleep-deprived brain didn't spew out too much nonsense.

@@CottidaeSEA Thanks for the long reply! I for sure read it 🙏 Got it. As you said, the code you gave as an example is different from how you'd write it, but let me still address it because it demonstrates one of the problems I had with testing (and reading / understanding classes) as opposed to FP - even in production codebases with "real" code examples: You need to set up the internal state to run the different functions, and it's hard to understand a method in isolation. For example, if you had another method on that class, that would only do something if `value` was three, you'd need to either call `execute` three times, complicating the test. Or you'd need to manipulate the class directly, which then would obfuscate the test so it resembles the real usage less. With FP and pure functions, they usually map one input to an output, making it trivial to write tests for them and truly test them in isolation. And thank you for clarifying where you come from. Totally makes sense that you think about performance so much! 👍 I've been a fullstack dev for most of my career and over time I learned the best approach to browser performance is "fix it if it breaks, otherwise favor good DX (testability, readibility etc.)". (Most) Browsers are so fast nowadays that it doesn't matter if you take up extra memory. > I reach for it whenever possible, but only when I can afford doing so This pretty much sums it up! 😊 And in my experience, in most JS server and browser codebases, you don't need to optimize for performance so granularly. (Especially on the backend, if performance mattered, the teams switched to Rust or another fast language haha) Thanks again for your thoughtful reply!

The examples in this video are NOT meant to be production code, but just to teach the concepts of FP. (I mention it at the end of the video.) But your comment is good advice, I hope more people read it!

Thank you for the kind words! 🙏 That's exactly the target audience. So far, this video received less views than my other ones, but I hope people who really need to find it, find it through SEO :)

Thank you for the kind words! And I agree, always choose the right tool for the job and take into account what your team knows! 👍

Thank you!🙏

Thank you and you're welcome! What topic would you like to see covered next?

Absolutely! Basically: Readability > Cleverness > Performance as long as performance doesn't matter. As soon as it does, the order switches.

Avril 14th - all day!

I see what you did there lol

I mostly agree! But I disagree in certain circumstances. If you cannot train the team for whatever reason, then "yes," you should go with the best solution that everyone understands. Or if functional programming would objectively be the worst solution, then also "yes," you shouldn't use these techniques. But, if you have a team with a culture of mentorship and functional programming is the best solution, you should definitely level the team up and implement the cleanest solution.

@@JanHesters Have you ever tried to level up a team? Just getting basic automatic formatting, linting, and PR reviews implemented for the code that's there already is an absolute war of attrition. Well... I guess those are all boring things. There's probably a bigger market for people trying some new cool thing and feeling special about how smart they've become than doing the essential and tedious work of figuring out why core functions of the application are failing, seemingly at random, and any tiny change to something that changes the timing of database calls creates cascading failures... Of course, a big problem in the code base I'm thinking of is that they did use so much fp - but in all the wrong ways - using reducers to filter and create new objects, using maps to iterate over and mutate objects... most people aren't disciplined enough to use any of it correctly. They would be better of just sticking to for loops rather than creating things that no one else (or even they themselves) can read. You know what would be a really useful video? How to reset VSCode to a default working state after years of use. So many people disable all of the linting and other code tools and then things that should "just work" don't - because they've been disabled. If you're working with really next-level, hyper-intelligent people of a similar mindset I imagine that fp could be really fun and not hinder productivity, but we're at a state in technology where it's too much to expect people to get a contact form to work reliably. The hello worlds are failing. We need the simple for loops so that people can read what they wrote themselves. Most people need fewer tools, that they know how to use correctly, not more tools that they don't understand the nuance of. When I was young and all of that was being added to JavaScript, I used to think all those things were so cool and even used some of it correctly. Now... htmx is starting to look better all the time.

What tools do you have for leveling up a team? How do you approach it? How do you get people interested in quality and correctness over coolness and "if it fits it ships"ness?

​@@coolaj86 > What tools do you have for levelling up a team? In my opinion, one-to-many and one-on-one mentorship is the most important tool for any dev team. > How do you approach it? Make sure that you have regular mentorship sessions with your team. Lead by example. > How do you get people interested in quality and correctness over coolness and "if it fits it ships"ness? Show them your arguments. If they agree, your arguments are good. If they disagree, that might be because you have a blind-spot. To answer all of these questions, might take its own proper video. I'll put in my backlog. Thanks for the idea! But I hope this somewhat answered your questions. If you have follow up questions, let me know. And if you disagree, I'd also be interested in your view! 🤓

Sure! If you want, you can drop your question here, or DM me on X: x.com/janhesters

Don't forget the Sauerkraut! 😄

Implicitly yes, absolutely! A good understanding of the language helps you understand any JS framework better. And for React specifically, it can help you clean up your code in general. It'll also help you to understand higher-order components, selectors in Redux, and why thinks are rendering (closure).

​@@JanHestersThank you.

Let's go 🔥

Thank you for your feedback! I agree and this is one of the last points of the video at the end 👍 Many of the examples are contrived to be as easy as possible. The goal of this video is to learn FP as opposed to real world use cases.

I totally agree! Code readability and maintainability should always be a top priority. It's a balancing act between writing efficient code and ensuring that everyone on the team can understand and maintain it long-term. 1.) Sometimes, you want to use the best patterns AND teach the people who don't know them those patterns. (Especially in a mentorship-culture.) 2.) In other cases, you want to reach for the best tool that everyone knows. ("When in Rome, do as the Romans do.") My mentor taught me both.

Thank you for the kind words! 🙏

Thank you so much!

Thank you! What is unclear? Maybe I can help you after the fact! 🙏

@@JanHesters Maybe I just need to write a few examples and fail abit :D Thank you!

@@kaicooper9421 Let's go 🔥

Thank you! Really appreciate it. Did you learn something fun new?

Thank you! 🙏 Trying out things differently.

Will create many future videos with testing best practices. Stay tuned!

Thanks!

Reminds of Daft Punk saying "Around The World" 144 times lol

A detailed video on functional programming including currying is coming soon 👍

one could argue that hocs are kind of magic haha

😂😂😂

@@Leon_Andersen True!

Dropping soon 🔜

Thank you! 🙏

Let me explain to you the output of the given code step by step: 1. Initialization of the generator: When `moreNumbers(40)` is called, the generator function is initialized with `x = 40`, but no code runs yet. 2. First `next()` call: This starts the execution of the generator until the first `yield`. It prints `'x', 40` and then yields `40 + 2` (i.e., 42). The output is: { value: 42, done: false } 3. Second `next(2012)` call: This resumes the generator, passing `2012` back to it. This value is assigned to `y`. It then prints `'y', 2012` and yields `40 + 2012` (i.e., 2052). The output is: { value: 2052, done: false } 4. Third `next()` call: This resumes the generator again, but since no value is passed, `z` is `undefined`. It prints `'z', undefined` and as there are no more `yield` statements, the generator finishes. The output is: { value: undefined, done: true } The sequence of console logs from your code would look like this: - `'x', 40` - `{ value: 42, done: false }` - `'y', 2012` - `{ value: 2052, done: false }` - `'z', undefined` - `{ value: undefined, done: true }` The formatting here on YT might be weird, but you can copy paste it in a markdown file. Hope this helps!

@@JanHesters ahh thanks 🤟, so basically when we call next(value) it doesn't re-initialize the value of x, but assign this value to the variable that was assign to the last yield. and doing this const y = yield x + 2; // x = 40 doesn't assign the result (42) to y

Thank you! Coming soon 🔥

You're welcome!

You're welcome!

Unless you want to apply to a specific company that uses React Native, I would recommend to focus your efforts on getting very good at Vanilla React, Redux and Next.js because those are the most sought after.

@@JanHesters thanks, but i'm good at nextjs, i'm freelencing with it but i want to get a full time job at a company

Glad you liked it!

Thank you very much! Stay tuned for a future video about higher-order components, which breaks them down in detail. And if you have any topic that interests you, kindly let me know 🙏