Live data from Hacker News

Things that used to be hard and are now easy

jvns.ca

311–316 of 316 posts

Re: Things that used to be hard and are now easy

#311
post #237

Earlier quoted context omitted.

I think async/await is kind of a didactic mistake. It’s marketed as a way to not have to think about the underlying abstraction, but lack of the understanding about how it works under the hood will almost certainly bite you in this ass. This I find to be especially true when people are writing mixed async and sync code. The best way for me to learn was writing all of the code before the async/await sugar existed (sca…

I think the intent is that you don't have any sync code at all.

Yeah but in practice it doesn’t work like that. There’s a ton of sync code that already exists and people know how to write sync code.

Re: Things that used to be hard and are now easy

#312
post #56

Earlier quoted context omitted.

> The number of times I've been bitten by the very specific semantics around async/await in JavaScript makes me wonder if I've hit some kind of a ceiling in trying to grok it. Got any examples? I've mucked around a fair bit with JS's async and never felt like it got in the way. (Other than the whole function coloring ordeal)

> I've mucked around a fair bit with JS's async and never felt like it got in the way. When functions return more than one Promise , or when one chains async functions calls, it isn't really clear Error s from which functions are likely to break out and result in an unhandled exception (read also: https://archive.is/ULT7P ). For example, does trapAllErrs() below trap 'em all? Not really. Why? The answer involves unde…

Why not use Promise.allSettled...?

Re: Things that used to be hard and are now easy

#313

Earlier quoted context omitted.

> As someone who leans frontend > I would second guess SaaS startups that start by building the infra/data models unless they’re going for a highly technical play Do you not see the problem with these 2 statements. Of course not dealing with non JavaScript is easier for a JavaScript developer. > You can get something in front of your users tomorrow. This is something we’ve been able to do with Rails or Django for nea…

In my experience, if you're not using Heroku, getting a Rails/Django app launched requires at least a day or two dedicated to devops faffing about (creating server instances, setting up CDNs, making sure the database is minimally correct, having some kind of deploy script or something). This won't even get you nice to have things like multiple environments with CI and deploy previews. Switching over to serverless can…

I’m not arguing about setting up your own infrastructure. Heroku launched when rails was 2 years old. What’s the point of this comparison if you arbitrarily handicap the most common rails deployment environment?

Re: Things that used to be hard and are now easy

#315
post #231

> Things that used to be hard and are now easy: > Concurrency, with async/await (in several languages) The number of times I've been bitten by the very specific semantics around async/await in JavaScript makes me wonder if I've hit some kind of a ceiling in trying to grok it. Coming from the world of threads, I've found Kotlin's structured concurrency approach the best of the lot I've used so far, even if it isn't wi…

Oh yes. I hate async/await so much. If I could uninvent one thing in programming it would be async/await. I wrote async/await code in C# for about a year. I did really try to learn it. I invested a lot of time. I did read Stephen Cleary. It often made sense for a split second only to fade away immediately. Usually the software would work, but i didn't understand what was going on in my own code. And others don't unde…

You can't add async programming to a blocking language like Java or C#. It doesn't mix well, and will fragment the ecosystem with libraries that mustn't be used together.

Re: Things that used to be hard and are now easy

#316

Earlier quoted context omitted.

The step backwards is that before, you couldn’t upgrade jQuery because the CDN script tag was on thirteen different partials, and you weren’t sure which were still in use, and now you can’t upgrade React because it depends on v4.3.2 of chalk-babel-duster-pack-plugin and that’s insecure but it has a breaking change in v5 you don’t know how to fix, so you’re just waiting for a total rewrite of the app to pull out CRA a…

Or you can avoid CRA in the first place. CRA is frankly a hot mess. But React itself, and for the most part even Webpack are quite reasonable.

What are your issues with CRA?
Post reply on HN