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

151–160 of 502 posts

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

#151

Post by bronson »

overcast wrote: post #125
TheOtherHobbes wrote: post #62

Earlier quoted context omitted.

I've never understood why this is a benefit when the one language is - let's say - suboptimal in many ways. The interfaces between server- and client-side code should be well-defined and language-independent. You don't want the same people writing both, because it's harder to check that your API is working to spec if it doesn't get fully independent testing. There's also a lot of useful server-side optimisation and s…

You don't see how having to know only one language, is easier/faster than having to know two languages? A lot of people are doing both front and backend work. Often times it's a single person running the show. I'll tell you right now I use node for ALL my web projects, because I only have to focus on a single language. When I wear every hat managing the domain, server, databases, mail, user questions, and everything…

Half my Rails apps end up with JS code executed server-side by TheRubyRacer. It's odd, but significantly better than having to keep duplicate logic in sync, some written in Ruby and some in JS.

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

#152

Post by ChicagoDave »

sametmax wrote: post #24
mromanuk wrote: post #4

I was thinking, watching the video "Ryan should fork it, or start over"... until he revealed it: https://github.com/ry/deno :)

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.

I'm not a huge NodeJS developer, but have done enough (and other development) to think this is not a good solution to the packaging/dependency problem.

My experience with npm issues were usually that some dependency had its own build process.

There are so many inconsistencies in how JS libraries are packaged and downloaded. I think scripting in general leaves the whole dependency thing out in the wind.

Now. If we could turn packages into testable objects, that would be cool.

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

#153

Post by mschuetz »

brlewis wrote: post #137
mschuetz wrote: post #75

Earlier quoted context omitted.

> performance and security from running JavaScript outside of a browser. I'm just now building a node app to filter point clouds, so lots of number crunching. In two days I've got something in javascript that's faster than the C++ solution I've been working on for a week. Mostly because javascript/node makes it trivial to parallelize file IO while doing work in the main thread. This app reads 13 million points from 1…

Did you use typed arrays, or did the benefit of async I/O outweigh the cost of using double-precision floats for everything?

I'm reading the values directly from the Buffer object that is returned from fs.readFile using buffer.readUInt32LE and buffer[index], then convert the values to doubles to do the hit-test and if it succeeds, it's immediately written to the output buffer. The nodejs Buffer object is a subclass of Uint8Array as far as I know.

On writing, the double coordinate values are transformed back into a fixed-precision integer format and stored in the output Buffer object.

I'm not generating an intermediate buffer since that does decrease performance a bit. It's directly from input buffer to output buffer. Output buffer is initially allocated with the same size as the input, and before sending it to the output stream it's cut to the actual size.

One thing I've previously learned and which has shown to be still true is that writing individual bytes to a buffer is faster than writing integers.

So originally I did this:

    outBuffer.writeInt32LE(ux, outOffset + 0);
But this turned out to be significantly faster. (~20%)

    // do once 
    let tmpBuffer = new ArrayBuffer(4);
    let tmpUint32 = new Uint32Array(tmpBuffer);
    let tmpUint8 = new Uint8Array(tmpBuffer);

    // do many times
    tmpUint32[0] = ux;
    outBuffer[outOffset + 0] = tmpUint8[0];
    outBuffer[outOffset + 1] = tmpUint8[1];
    outBuffer[outOffset + 2] = tmpUint8[2];
    outBuffer[outOffset + 3] = tmpUint8[3];

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

#154

Post by repsilat »

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.

I've never looked into server-side react, can you explain a bit about the requirements? Does the server keep a lot of session data around to maintain a shadow DOM for each connected client? How far is it in practice on the continuum between a fancy templating language and a full app framework? Does anyone put server-side React on server-side Redux?

Whatever the case, if people write clients in react to talk to Ruby backends, can't they do the same to get "server-side react clients" that run in front of their backend app? Or does that go against the programming model somehow? Would it enforce too much of a barrier between "the view" and the model than is traditional these days?

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

#155

Post by notdonspaulding »

chrisco255 wrote: post #109
maerF0x0 wrote: post #104

Earlier quoted context omitted.

This fails from the false dichotomy of speed of execution vs speed of development (which includes fixing bugs). Well written languages optimize to a certain weighted preference of the two and some languages deliver more of _both_ than others. For example; Typescript is fast to write. and Golang is reasonably quick to write, _and_ execute. Both should have ~15% less bugs than javascript, potentially making them faster…

Once you've paid the upfront cost of learning Golang, I might agree with you. But then again, in particular when building a full stack app (and not when on a team that has back end and front end specialists), it's helpful to use the same context (JS/NPM) when devving. People are bad at context switching.

I've heard this argument several times now and it finally hit me what I dislike about it.

If you aren't context switching between your backend code and your frontend code (even when both are JS), you're probably incurring technical debt in your architecture to be paid in even greater numbers of dev hours down the road.

When you are writing an all-JS full-stack app, do you really feel like you're only working on a single app, as opposed to two different apps which happen to share the same repo?

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

#157

Post by dnomad »

minitech wrote: post #149
dnomad wrote: post #144

Earlier quoted context omitted.

Watching the Javascript poorly reinvent the wheel has been very disappointing. Very simple mistakes like immutable, never changing build releases that Java developers understood 15 years ago are become recent front page news in this community. Ironically, even though all the code is open-source pre-existing knowledge does not get leveraged in the open source world. There's a kind of market failure at work here it see…

> Very simple mistakes like immutable, never changing build releases Can you expand a bit more? Not sure what this means.

[1] https://en.wikipedia.org/wiki/Npm_(software)#Notable_breakag..., [2] https://www.csoonline.com/article/3214624/security/malicious..., [3] https://news.ycombinator.com/item?id=16087024

And the list goes on and on IMO. What's disappointing is that these were lessons learned a long time ago and now they're being re-learned.

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

#158

Post by ex3ndr »

mschuetz wrote: post #75
thosakwe wrote: post #21

This was one of the more interesting software talks I've listened to recently. I like that it was very real - there are serious, serious problems with Node.js, and the fact that even the creator acknowledges these problems caught my attention. I'm also a long-time user of Dart, so when he brought that up, and compared TypeScript to its shortcomings, I definitely agreed. That being said, even with the Deno project, I'…

> performance and security from running JavaScript outside of a browser. I'm just now building a node app to filter point clouds, so lots of number crunching. In two days I've got something in javascript that's faster than the C++ solution I've been working on for a week. Mostly because javascript/node makes it trivial to parallelize file IO while doing work in the main thread. This app reads 13 million points from 1…

Can you share some sources? I tried to process simple CSV files in a very straight forward (but async) way and got reading 200mb CSV and just splitting it to columns (with simple split by comma) takes ~10 seconds.

Also simplest HTTP request in express is handled in several ms and that's A LOT in my opinion.

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

#159

Post by overcast »

LargeWu wrote: post #150
overcast wrote: post #139

Earlier quoted context omitted.

Because not everyone is using React type frameworks on the frontend? There is old fashioned javascript still, and because I know it on the front end, I know it on the backend.

But I know lots of languages, and just because I'm using JS on the frontend doesn't mean that's the best backend choice. Whether I'm using React or Angular or Ember or Vue or jquery or vanilla JS on the frontend doesn't have any impact on the code I'm writing on the backend. Because one is concerned primarily with handling UI, and one is primarily for data access. There's just naturally not a lot of overlap between t…

That's awesome you know lots of languages, well done. It's not necessarily about what's the best backend choice, it's about getting shit done as efficiently as possible. For the vast majority of projects, you're never going to reach any type of limitation in Node performance, that you may or may not be suggesting. I'm not sure why you're so hung up on the front impacting the back, it impacts MY workflow. I don't have to switch gears, and look up documentation on how to do x y or z in this language, when I already know it in this language. Do you use arrays? Variables? Any basic programming structures? There is plenty of overlap.

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

#160

Post by ex3ndr »

TheOtherHobbes wrote: post #62
rb808 wrote: post #46

Interesting that he's unsure about Go. Would be nice to hear about why. One huge strength about Node (&Deno) is having the same language and tools on the front end and back end. Its a huge benefit to have a team on one language, even if it might not be the optimal choice. I'm not sure if that is the problem he had with Go though.

I've never understood why this is a benefit when the one language is - let's say - suboptimal in many ways. The interfaces between server- and client-side code should be well-defined and language-independent. You don't want the same people writing both, because it's harder to check that your API is working to spec if it doesn't get fully independent testing. There's also a lot of useful server-side optimisation and s…

It is very useful if you want to make your devs not client or server but both. This works well in many organizations that i have seen: developer is responsible to build feature from ground to top - this speeds up things a lot.
Post reply on HN