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…
Things I Regret About Node.js [video]
461–470 of 502 posts
Re: Things I Regret About Node.js [video]
#462Earlier 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.
Re: Things I Regret About Node.js [video]
#463Ryan 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]
#464Earlier 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 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]
#465Earlier 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…
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]
#466Earlier 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.
Re: Things I Regret About Node.js [video]
#467Earlier 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.
Re: Things I Regret About Node.js [video]
#468Earlier 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.
Re: Things I Regret About Node.js [video]
#469Earlier 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.
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]
#470Earlier 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.