Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things I Regret About Node.js [video]

youtube.com

Post reply on HN
Print view View original

451–460 of 502 posts

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

#451

Post by Jach »

p2t2p wrote: post #235
bartread wrote: post #169

Earlier quoted context omitted.

I think the problem with "bloat-free" is it's a fine ideal until you try to solve any kind of reasonably complex problem, and honestly it starts to creep in even when you're solving something that isn't particularly complex. Here's a concrete example. Your classic node.js or express.js sample app is something fairly simple like a hello world, or an IM server. A more complex sample probably looks something like that v…

This why I love Java so much. Take a look at what Spring Boot does for me: - Routing is done in two lines of code: @Controller @RequestMapping("/myroute") - Cookie and body parsing - no need to write any code to do that, I just have method parameters and all of the data flies in. Whant a validation? Only one keyword on a method parameter - @Valid. Custom validators are supported as well. - Session management. It just…

What are the barriers to using the Spring stuff through Clojure's interop capabilities?

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

#452

Post by jonreem »

davedx wrote: post #393
arenaninja wrote: post #305

One takeaway from this is how Microsoft is killing it currently: * Much-beloved TypeScript * Much-beloved VSCode * Much-beloved GitHub If they hire Ryan to flesh out his vision for deno we'd probably need a new acronym, MAFANG On a more serious note, I wonder if deno could support a lower level construct like Observables. As much as Promises are perceived to be an improvement over callbacks, they still have major fla…

TypeScript has async/await built-in, and Deno has top-level await too. Promises won't be necessary most of the time.

async/await is powered by promises

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

#453

Post by stickfigure »

tnolet wrote: post #118

Having worked with Maven, Gradle, Ruby Gems, Pip and the non-existing Go package management I must say I actually really like the Node / NPM combo. I guess artists are their own worst critics. edit: forgot Scala's SBT, admittedly a builder using Maven repo's but still an excellent example of how bad UX in this area can get.

I've worked with all of these as well, and npm is probably my least favorite. Above all else, I expect my build system to do ONE THING:

Exactly reproduce a build at a later date

Part of it is technological (npm didn't have package-lock.json until very recently), part of it is organizational (the npm repository is surprisingly fluid), and part of it is cultural (the JS community likes zillions of tiny constantly-changing libraries). The net result is that I cannot walk away from a JS build for three weeks without something breaking. It breaks all the time. UGH.

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

#454

Post by allover »

kbenson wrote: post #322
allover wrote: post #237

Earlier quoted context omitted.

> You'll find much harsher critics of Node/NPM in these parts! They're ill-informed. GPP is correct that, for example pip is fundamentally inferior to npm [1], and those that insist on throwing shade at npm on HN should be corrected. They're wrong, and insulting a sound, well maintained project, without basis. [1] https://github.com/pypa/pip/issues/988

> those that insist on throwing shade at npm on HN should be corrected. Preferrably by giving them better ammunition, since I do see NPM as substandard in quite a few ways, which is inexcusable when there do exist examples to learn from (whether it be a positive or negative influence). First, it helps to clarify whether we are talking about npm the client or NPM the repository and ecosystem . Client issues are genera…

> Sure, NPM isn't all that bad compared to some of the examples that were put forth, but the problem is that those examples are a limited subset of what exists.

That was all I was responding to.

I definitely learned some cool stuff from your comment, and appreciate that, but my point was simply that the all the drive-by FUD that npm gets on HN is unwarranted.

> I frankly find the current situation somewhat disgusting.

This feels so hyperbolic though. The things you mention are cool 'nice-to-haves', to say not having them is 'disgusting' is a huge stretch in my opinion.

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

#455

Post by menor »

mikekchar wrote: post #208
bartread wrote: post #169

Earlier quoted context omitted.

I think the problem with "bloat-free" is it's a fine ideal until you try to solve any kind of reasonably complex problem, and honestly it starts to creep in even when you're solving something that isn't particularly complex. Here's a concrete example. Your classic node.js or express.js sample app is something fairly simple like a hello world, or an IM server. A more complex sample probably looks something like that v…

IMHO, the point of using a no-frills library/framework is because you want you write the rest of it yourself. The advantage of this is that it meets your requirements exactly and is therefore smaller/less complex. When doing a project that takes only a few weeks, I would probably choose a framework that has everything in the box. But if you are building something that is going to be developed over a period of years,…

I don't come from that era but couldn't agree more, every time one of my coworkers suggest using a library I tell them that is ok as long as they maintain it, I prefer to spend my time coding and like to understand as much of the codebase as I can, instead of having to learn and maintain tens of external libraries. Specially if we only need a couple of functions from that library.

I normally lose those debates though, and the thing reaches a point where the complexity of the code makes it impenetrable.

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

#456

Post by dozzie »

always_good wrote: post #420
dozzie wrote: post #349

Earlier quoted context omitted.

>> I was working with a system where server is written in Erlang and client (and another server) is written in Python. No problems with switching back and forth. > Yes, that's a cost your brain is paying. What cost? I said I haven't noticed any. > new devs [...] then need to learn and understand both Python and Elixir. No, they don't need to learn even a speck of Elixir. -- What you described is a trusim that one nee…

How wouldn't there be a cost? There are more things you have to remember. Workflows in both languages. Of course it's more stuff, thus more context. And you have to use both languages constantly to stay fresh in them. The syntax isn't the only problem, just the easiest one. Is it just as easy to maintain Spanish and English skills than just English? "I don't notice it" isn't a very strong argument. I bet you don't no…

> How wouldn't there be a cost?

How wouldn't there be a cost of switching between two languages? Normally. You could try, you'd know then. Though the prerequisite is a system that is designed, with clearly designated borders between the parts, not a system that has just emerged.

Proving something's non-existence is a little like proving that you're not a weapons smuggler. How would you expect to even start?

> There are more things you have to remember. Workflows in both languages. Of course it's more stuff, thus more context.

But this is irrelevant to switching between the languages. You have just as much to remember if you write unrelated things, each in its own language.

> Is it just as easy to maintain Spanish and English skills than just English?

"Just as easy than"? Really? In a thread about languages?

You picked wrong analogy. It is just as easy to write prose with every second paragraph in English and Spanish as it would be with just English. The prerequisite, obviously, is that you know both languages.

> And you have to use both languages constantly to stay fresh in them.

For some value of "constantly". It's not like people forget everything about a language when they don't use it for a week or a month.

> "I don't notice it" isn't a very strong argument.

Well, at least it's some argument. On your side is only "how wouldn't there be a cost?", clearly from a position of somebody who doesn't use many languages.

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

#457

Post by chriswarbo »

tome wrote: post #427
chriswarbo wrote: post #415

It's nice to see some recognition of the idea that interpreters are safe by default (excluding infinite loops/OOM), and we can avoid many security concerns (access to files/network/etc.) by simply not including that functionality in the interpreter (unless opted in via a startup parameter, as described). I'm also a fan of using env vars for configuration and locating dependencies, as mentioned in the talk. Much simpl…

> I'm also a fan of using env vars for configuration and locating dependencies O please just let things be configured by a single JSON value, built from smaller JSON values if necessary.

Sure thing. How do you get such a JSON value into an application though?

What I'm saying is to use env vars. You could put your JSON straight into an env var, or if you want a persistent JSON file on disk then put the path to that file in an env var.

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

#458

Post by elyobo »

nojvek wrote: post #321
mieseratte wrote: post #306

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…

ES6 classes were such a relief compared to the prototype bloat you had to right. I love syntactic sugar that makes my life easier. ES6+ flavors of JS & Typescript really made me take web programming seriously again.

I loved the classes at first, but as I've got more in to it I've found that classes and prototypes are redundant. Closures let me maintain all of the state that I need without the extra boilerplate.

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

#459

Post by rubber_duck »

ChicagoDave wrote: post #423
rubber_duck wrote: post #392

Earlier quoted context omitted.

Dynamic doesn't behave the same as JS typing, you're still using CLR object model and typing rules, you're just losing compile time checks - it gets complicated really fast if you want to do meta programming even with DLR and it's not really ergonomic in C# (like casting/boxing primitive types, etc.) Think about AutoMapper and then compare it to a TS solution using spread operator. How much boilerplate automapper cra…

This sounds like a personal preference for dynamic vs strongly typed. I could rewrite your entire comment in reverse about how I find C# highly expressive and readable while dynamic languages or Kotlin (blech) are a mess of inconsistent whack-a-doodle experimentation. But my opinion is useless. The value in any platform is productivity and if any given team can be productive, it doesn't matter if it's COBOL, RPG-3, P…

Actually I like static typing, I mentioned I rewrote a project in F# in like 1/3 of the code from C# solution.

It's more that C# is static typing done poorly IMO - a relatively limited type system that adds overhead compared to dynamic languages or more expressive static languages.

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

#460

Post by inimino »

iamleppert wrote: post #286
jonny_eh wrote: post #128

Earlier quoted context omitted.

I dunno, importing from a url seems really smart and practical to me. It divorces the run-time (Deno) from a package manager (like npm). I wonder how it handles dependencies though.

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.

Post reply on HN