Nice video. I really like the developer experience of a JavaScript framework (I’m most comfortable with SvelteKit). But I dislike the ecosystem. If I compare it to not-JavaScript environments, the number of dependencies is a tenfold, if not more. Therefore, the amount of updates is high as well. And if you make use of all these cloud services, you have external dependencies as well. It’s not easy to really know what’s going on in your application with all these pieces that are stitched together. That makes me a little uncomfortable. How do you feel about that?
You're right, I also mentioned this at the start of the video. Stitching a lot of disparate services together is a hassle -- there are multiple dashboards, logins, etc... and if one service goes down and others don't, part of your application dies and users get a bad experience (vs if the whole thing just died, they don't get an experience at all I guess). The flip side of that coin is the vendor lock-in. Going with one vendor and depending on their infrastructure means that if they have a problem, you have a problem. Gotta strike a balance somewhere... =)
@@deployanddestroyTrue, but it’s not just the services. It’s also the packages on which a JavaScript framework is built. 300+ dependencies in the node modules folder is not an exception. I hope to see a shift to a more stable ecosystem one day. I like what Deno does with the @std namespace in JSR (their registry). It acts as a standard library like you see in other programming languages.
The 'heh just kidding' snark for some of the products was irritating and not in the least bit helpful in a video like this as it implies we know about those products and why they're not worth considering.
Nice video. I really like the developer experience of a JavaScript framework (I’m most comfortable with SvelteKit). But I dislike the ecosystem. If I compare it to not-JavaScript environments, the number of dependencies is a tenfold, if not more. Therefore, the amount of updates is high as well. And if you make use of all these cloud services, you have external dependencies as well. It’s not easy to really know what’s going on in your application with all these pieces that are stitched together. That makes me a little uncomfortable. How do you feel about that?
You're right, I also mentioned this at the start of the video. Stitching a lot of disparate services together is a hassle -- there are multiple dashboards, logins, etc... and if one service goes down and others don't, part of your application dies and users get a bad experience (vs if the whole thing just died, they don't get an experience at all I guess).
The flip side of that coin is the vendor lock-in. Going with one vendor and depending on their infrastructure means that if they have a problem, you have a problem. Gotta strike a balance somewhere... =)
@@deployanddestroyTrue, but it’s not just the services. It’s also the packages on which a JavaScript framework is built. 300+ dependencies in the node modules folder is not an exception. I hope to see a shift to a more stable ecosystem one day. I like what Deno does with the @std namespace in JSR (their registry). It acts as a standard library like you see in other programming languages.
The 'heh just kidding' snark for some of the products was irritating and not in the least bit helpful in a video like this as it implies we know about those products and why they're not worth considering.
Thanks for the feedback! I’ll keep it under control next time.
@@deployanddestroy I had a good laugh with MAUI