Things I Regret About Node.js [video] • Hacker News Board

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

#361

Post by lloeki » Thu, Jun 07, 2018, 8:10 AM UTC

jonny_eh wrote: post #131

lloeki wrote: post #92

Earlier quoted context omitted.

Being able to share code is really not that great because you don't share that much code between front and back in reality. Being able to share the paradigms , structure , mindset and tooling (like linters, formatters, code generators, packagers, whatever..) is what's awesome. You remove a whole lot of context switches and cognitive dissonance, smoothing the train of thought which greatly eases the expression of idea…

> you don't share that much code between front and back in reality Good luck rendering React server-side in Go or Ruby.

Turns out not every application needs, let alone require React.

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

#362

Post by danpalmer » Thu, Jun 07, 2018, 8:28 AM UTC

nojvek wrote: post #320

hshehehjdjdjd wrote: post #270

Earlier quoted context omitted.

Go has been out for almost a decade and they’re still working on the package management story.

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

Yep. There are some languages that start out trying to solve fundamental productivity issues in previous languages - some more than others.

I think we had a generation of ecosystems with Node, Ruby, Python, that tried to do solve the unapproachable systems around the Java/etc ecosystems and make them more open.

They succeeded, but the next generation seems to have been about solving the plethora of tools that came with those languages. Rust, Go, etc, having first-party tools are trying to improve upon that, and yes I think Rust is by far the best implementation I've seen.

I'm interested to see what the next generation is.

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

#363

Post by kjeetgill » Thu, Jun 07, 2018, 8:32 AM UTC

munificent wrote: post #85

pvsukale3 wrote: post #60

Can anyone explain why he called Dart a complete failure? https://youtu.be/M3BM9TB-8yA?t=19m55s ps: I am a junior developer. I am taking up Dart to learn Mobile apps development using Flutter.

I'm on the Dart team (but I don't speak for the entire team here). Dart had two initial goals: 1. Get a native Dart VM into Chrome and eventually other browsers. 2. Get a significant number of client-side web developers that were using JavaScript to move to Dart. It's probably not obvious, but these goals are in tension with each other. In order to motivate adding a giant new VM to a browser, you need to make the lan…

> 1. Get a native Dart VM into Chrome and eventually other browsers. > 2. Get a significant number of client-side web developers that were using JavaScript to move to Dart. > The Dart leads prioritized (1) over (2). ... That didn't work out, unfortunately.

That's what I remember hearing when Dart was just getting off the ground. So what happened? Script tags can specify text/javascript or text/dart. Did the the Chrome team just veto any integration? Did a prototype into chromium ever even exist? Google put out experimental quic stuff out before so why not a new interpreter?

I'm convinced if it was out there we'd have seen some use and some hype! I'm a little disappointed to hear Dart pivoted away. Such high hopes!

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

#364

Post by mirekrusin » Thu, Jun 07, 2018, 8:44 AM UTC

flukus wrote: post #348

pknopf wrote: post #274

Earlier quoted context omitted.

How do you break the loop?

I think vi -> vim -> neovim shows a pretty good model. Neovim is an effort to modernize and remove cruft from vim, so they get to keep all the good parts and throw out the backward compatibility. If it works out it can eventually replace vim, not to different to what vim did to vi. I'd like to see similar stuff done to much of the GNU tools. Make for instance has to worry about backward compatibility and posix compli…

Text editor and programming language are slightly different things, backward compatibility story is completely different.

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

#365

Post by logicallee » Thu, Jun 07, 2018, 8:49 AM UTC

Here is an amazing quote from a different interview:

https://www.mappingthejourney.com/single-post/2017/08/31/epi...

Apparently these days,

"Ryan: Yeah, I think it’s… for a particular class of application, which is like, if you’re building a server, I can’t imagine using anything other than Go"

!!

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

#366

Post by aphexairlines » Thu, Jun 07, 2018, 9:06 AM UTC

bschwindHN wrote: post #302

pan69 wrote: post #190

I've said it before and I say it again; NodeJS is an infrastructure component, not a general purpose application runtime environment. I totally recognise the IO problem in our connected world and NodeJS really does solve the problem around the "many simultaneously persistent connections", something that would be really hard to do without something like NodeJS. In essence (and in my humble opinion) NodeJS is basically…

> NodeJS really does solve the problem around the "many simultaneously persistent connections", something that would be really hard to do without something like NodeJS What part of it is really hard to do without NodeJS? You can do this easily in Go, Elixir, C++, Rust, etc.

The nice thing about Node.js's design is that (almost) all IO is non-blocking by design, so developers can't block their programs on IO by accident.

In other platforms developers need discipline to choose non-blocking APIs over blocking ones, or to wrap their blocking calls in async execution contexts like threads or coroutines.

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

#367

Post by kybernetikos » Thu, Jun 07, 2018, 9:07 AM UTC

lloeki wrote: post #92

mrighele wrote: post #82

Earlier quoted context omitted.

Having the same language allows to share some code between frontend and backend. This can be used to prerender your SPA on the server, for example, or to share some logic with the client to enable offline usage.

Being able to share code is really not that great because you don't share that much code between front and back in reality. Being able to share the paradigms , structure , mindset and tooling (like linters, formatters, code generators, packagers, whatever..) is what's awesome. You remove a whole lot of context switches and cognitive dissonance, smoothing the train of thought which greatly eases the expression of idea…

I'm working with a system that lets you develop code in the client, then gradually move it further back in the stack as needed. It's incredibly useful for testing.

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

#368

Post by fredsted » Thu, Jun 07, 2018, 9:15 AM UTC

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…

Doesn't Go use URLs? How did they solve all these issues?

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

#369

Post by rubber_duck » Thu, Jun 07, 2018, 9:21 AM UTC

ahansen wrote: post #247

manigandham wrote: post #228

Earlier quoted context omitted.

Yes, because the loop never solves the original problem. It's about organization and bloat, not pure speed and leanness. Rebuild from scratch but also recreate all the existing functionality in a much better standard library and finally the chain can be broken. But nobody wants to do that.

I believe this is what Microsoft is trying to do with .NET Core. It's been successful so far, though they aren't at feature parity yet.

C# is very verbose and tedious compared to more expressive languages - having to deal with CLR types/API at runtime while using a language with very limited expressiveness (C#) is not very productive. It's better than Java if that's what you're aiming at - but JVM has an incredible ecosystem of stuff that works - much larger than .NET core which is not very mature in many areas (recently had to revert to .NET 4.7 because some encryption method used by a government SOAP service we were talking to wasn't supported).

TypeScript and JS underneath is actually quite malleable - you can escape static typing at any point and revert to simple JS object model when things don't map cleanly in the type system - and then still have types at the boundaries - makes meta-programming trivial in some cases - where it would look like a monstrosity in C#.

F# is interesting and has a lot of advantages over C#, but few people seem to be willing to invest the time to pick it up in the .NET community.

So I don't really view .NET core as a superior alternative, I've worked in JVM land, they are more mature and while Java sucks there are other languages on top of it as well and are decent to use (Kotlin ~ C#, Scala ~ F#)

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

#370

Post by nicky0 » Thu, Jun 07, 2018, 9:23 AM UTC

iamleppert wrote: post #78

He talks about not to add in features you think would be “cute” because they are always a mistake.. Then a few minutes later says “I thought being able to specify URLs in import statements would be cute..” Uhh...Houston, we have a problem with this one.

whoosh!