Live data from Hacker News

Things I Regret About Node.js [video]

youtube.com

461–470 of 502 posts

Re: Things I Regret About Node.js [video]

#461
post #344

Earlier quoted context omitted.

It's interesting to place today's techs on the Java maturation timeline - each became what they thought they hated but realized may have existed for some necessary reasons. New platforms bring exciting and meaningful evolution often at the cost of what techs like .net and Java have a few decade advantage in. It's also interesting to see what Java devs are innovating with themselves, Scala, Kotlin both have good thing…

The biggest problem i see is the weird hole circa 2006 that arranges with Sun selling to Oracle, that kind of still-birthed Java as the next great language. That hole I can credit as giving C# the advantage in that tight niche, and stilling the development of the JVM platform in general. By the time that the rust on JVM improvements were dusted off, all initiative was lost. Java was playing catchup to the competition…

As we're seeing with WhatsApp, guardianship and supporting the direction of a project isn't easy. I'm not sure where Java would have ended up if someone else took it.

Re: Things I Regret About Node.js [video]

#462
post #338
post #298

Earlier quoted context omitted.

Have you tried Luminus? It comes configured with Buddy for auth though the docs for both Luminus and Buddy could do with some work.

I haven't. But I definitely will try to use it, I'm really eager on getting to the same level of productivity in Clojure that I have in Java with Spring. I have a huge hope that Clojure + something like Spring Boot for it could make me even more productive. Some of the stuff that we have in Clojure really is wonderful, hugsql for example.

You'll never get anything close to Spring Boot for Clojure. Spring grew out of J2EE and Clojure's culture is diametrically opposite, favouring curated libraries. Clojure's main/(only?) web framework - Luminus - has a very small team behind it, though it does a fine job.

Re: Things I Regret About Node.js [video]

#463
It's wild to see this after having been around in the early days of Node, and now having also moved most of my attention to Go as well.

Ryan has always had, IMHO, excellent taste and good instincts and guts to make things simpler. A lot of the accidental complexity in our industry persists simply because people tolerate it, and it's great to see that he hasn't lost his fire in that area. Looking forward to see more about Deno.

The point about promises was an interesting one for me personally since I was one of the people at the time who argued in whatever small way for taking promises out, in the hopes that the language community would come up with something better.

I have mixed opinions on the topic now, but it's interesting to speculate about what might have been. The Node.js ecosystem was weakened by having different ways of handling the async question, and by a lot of developers not knowing the best practices in using callbacks effectively and leading to "callback hell", which is totally unnecessary. It's possible that having promises baked into an early Node would have constrained or even fragmented what we ended up with in the language, and that would have been worse. I'm still a little disappointed that we didn't end up with anything more elegant than promises in the language itself.

It's interesting to compare package management in Node and Go. NPM got the early adoption and became the de-facto package manager at a time when JS had no such thing. In Go, the package manager question has been unsettled for a much longer time and there are more chances to experiment. Package management is simply difficult, and it seems impossible to design a good programming language and resolve the package management questions at the same time. It's sad to see some of the criticism against NPM... it's much easier to criticize than to build a better system.

Re: Things I Regret About Node.js [video]

#464
post #194

Earlier quoted context omitted.

Performance.

That seems highly unlikely. I'm going off of what I've seen myself, and what I've seen in the xi editor: https://github.com/google/xi-editor "The protocol for front-end / back-end communication, as well as between the back-end and plug-ins, is based on simple JSON messages. I considered binary formats, but the actual improvement in performance would be completely in the noise. Using JSON considerably lowers friction…

"Performance" in a text editor means latency, and it's not going to matter there when the text editor also has to edit the text, update the display, etc.

"Performance" in a server also means throughput. There's a reason why protobufs exist and it is all about performance (and type safety which is related) and there's no way JSON serialize/deserialize overhead, in both directions every time, is going to be a good choice here.

Re: Things I Regret About Node.js [video]

#465
post #434

Earlier quoted context omitted.

> but the only reason for doing so was "my code doesn't look like it does in other languages"... As much as I beat the FP drum these days at work, I find the class syntax a much nicer way of organizing solutions to certain, pardon the pun, classes of problems. Whether or not you find this to be semantic diabetes is a matter of taste, I suppose. I'm curious what, specifically, you find to be the major issue that makes…

There's very few things JS classes can do that ES6 modules/named exports along with closures returning plain objects can't do better, in term of code organization, isolation, and extensibility. For the 6 times a year where I need an actual class (it does happen!), I can write the prototype code. The main issue with adding classes is that they're very, very complex if you want to make them useful. The initial version…

>In the typed flavors (Flow, TypeScript), I can analyze the interface of plain objects, but not in vanilla JS.

I've found that developing JavaScript in an IDE that reads and validates type information from JSDoc allows me to introduce strong typing while maintaining the flexibility and simplicity of vanilla JavaScript without getting as bogged down as I get with Typescript.

Re: Things I Regret About Node.js [video]

#466
post #320

Earlier quoted context omitted.

I’m super bullish on rust. I feel like it was designed with the right intentions.

I love rust, but the standard libraries are nowhere near the same abstraction level of nodejs. All services I've deployed built on rust pulls in a kitchen sink of deps. Granted. I get a static binary as my end result, so maybe it's fine.

Rust is designed that way, to be fair. They expressly did not want to be batteries included like python is. The reasons are what they are and not particularly relevant to the conversation, but pulling in well designed third party crates is the point.

Re: Things I Regret About Node.js [video]

#467

Earlier quoted context omitted.

Is it synchronous? Does it follow redirects? What happens in a 404 situation? Does it obey cache headers? What happens when a timeout occurs or the resource isn’t code? What happens with recursive dependencies and other edge cases as a result of not knowing the dependency tree until runtime? What about error handling and recovering from these failures at runtime or compile time? Should all resources be secure? How do…

The Web has all of these issues and yet importing JS libraries this way has worked just fine. Obviously it's not what you should do if you are publishing a library for others to use, but for local use, and the kinds of exploratory scientific computing he was talking about, it sounds perfect.

It has _not_ worked "just fine" which is why we have bundlers, minifiers, and other build systems.

Re: Things I Regret About Node.js [video]

#468

Earlier quoted context omitted.

I don't see it. Any old idiot can learn a programming language. The difficulty doesn't come from the language, it comes from the environment and tooling.

So what's your alternative? I don't know of any environment easier than installing Node. I type 'n latest', and yarn add/install. Done. Ruby? Laughable. PHP has a zillion dependencies. Go with all of its system paths. Java VM, no thank you.

You completely missed the point. My point isn't that node is better or worse than any of them, my point is that if you're starting from scratch with no back-end knowledge, then the benefit of already knowing the language you're going to use on the back-end is dwarfed so heavily by the other stuff you have to learn that it's inconsequential.

Re: Things I Regret About Node.js [video]

#469
post #434

Earlier quoted context omitted.

There's very few things JS classes can do that ES6 modules/named exports along with closures returning plain objects can't do better, in term of code organization, isolation, and extensibility. For the 6 times a year where I need an actual class (it does happen!), I can write the prototype code. The main issue with adding classes is that they're very, very complex if you want to make them useful. The initial version…

>In the typed flavors (Flow, TypeScript), I can analyze the interface of plain objects, but not in vanilla JS. I've found that developing JavaScript in an IDE that reads and validates type information from JSDoc allows me to introduce strong typing while maintaining the flexibility and simplicity of vanilla JavaScript without getting as bogged down as I get with Typescript.

For sure, though my comment referred more to analysing code for things like automatic transformations at scale (like codemods) than during development. Like, figuring out that a stateless function component is a component is hard.

You can do almost everything with jsdoc comments in flow and TS, of course. It's awesome.

Re: Things I Regret About Node.js [video]

#470

Earlier quoted context omitted.

My head can't wrap itself around: import { test } from " https://unpkg.com/deno_testing@0.0.5/testing.ts" There is so many issues with that I don't even no where to begin.

But this is exactly the way the Web works. Right? And that platform seems to have done alright for itself. For libraries or professional projects, ship your dependencies or use a build system. But for one-off projects, being able to pull in a utility library without needing any tool but the interpreter you're using or some extra build step seems like a big win.

The entire world moved out of inline dependencies in the HTML page to a package managers. We invented bower or npm __because__ of it.
Post reply on HN