5 ms·
JavaScript errors only occur at runtime. It's very common, especially in legacy codebases, for issues to just fly under the radar, even if they are obvious to t
by dan_can_code 3y ago
JavaScript errors only occur at runtime. It's very common, especially in legacy codebases, for issues to just fly under the radar, even if they are obvious to the seasoned dev. There is a reason why one of the most popular JS books is called 'Javascript: the good parts'.
With rust, it's very refreshing in that it's idiot proof, which JavaScript is not.
CSS is not relevant, since it is not actual programming.
- oefrha 3y agoWe (at least the author and I) are talking about front end development here where most reloads are tweaking markup and stylesheets and shouldn’t introduce any error. And half a minute or longer reloads are unacceptable for those. I don’t need a lecture on the history of JavaScript, thank you. Especially since JavaScript/TypeScript has come such a long way that JavaScript the Good Parts is barely relevant anymore. > Rust… idiot proof That’s such a… interesting statement that I’m not going to respond further.
- spookie 3y agoCSS is actual programming. Nevertheless, he was just stating a common case where one iteratively checks if their assumptions, even if carefully accounted for, conform to their expectations. Another, very real "programming" situation could be the following: correctly parsing 3D mesh information in a multithreaded fashion and pass that to your preferred API of choice. Is one going to get all edge cases right the first time? Is your program's codebase large enough? Eventually it becomes kinda yucky having to wait. The compiler may know what is programmatically correct, not what your intention is. I think that's what the other person was trying to argue. I'm not too concerned about compile times myself, I'm used to them given I mostly dabble with compiled languages (I do a lot of CSS though!), but there's a argument to be made about iteration time and being fast in solving a problem.