Live data from Hacker News

Hard-won lessons: Five years with Node.js

blog.scottnonnenberg.com

201–210 of 365 posts

Re: Hard-won lessons: Five years with Node.js

#201

Earlier quoted context omitted.

> You're leaving out a lot when you say it'd take you "five minutes with a simple Maven/Gradle build". What's a maven? What's gradle? What's groovy and where can I learn it? You have similar concerns with node (What's npm? etc...) These are peripheral and necessary knowledge on both platforms. > Getting from zero to JSON api in node.js is fast by comparison It's only fast because you already have the knowledge. Two e…

> It's only fast because you already have the knowledge. No, when I said "from zero" I meant from zero knowledge. > You have similar concerns with node (What's npm? etc...) What's the "etc..."? Install node and you get npm with it. Writing a REST service IS simpler with Node when going from zero, I know because I have done (or at least attempted) both from zero in the recent past. > The idea that it's a faster to ach…

This is a classic case of you forgetting all the learning and concepts you needed to get to "zero".

Re: Hard-won lessons: Five years with Node.js

#202
post #141
post #133

Earlier quoted context omitted.

If only node had exception handling and functions!

Node has - for me - the same problem as C#. Unchecked exceptions on every corner. You don't even know what can explode until it explodes. And then takes your Node instance down. But I am one of these weirdos who likes checked exceptions in Java, so maybe this is not a problem for others.

The same problem as C#? You're fighting a very old position.

Exception handling in C# is amazingly good, you can't run C# production level apps.

It suffers none of the problems that are being discussed above. All you're doing is confusing the discussion with a view point I haven't heard in a decade.

Re: Hard-won lessons: Five years with Node.js

#203

Earlier quoted context omitted.

> yet I still turn to Node.js for proof of concept projects because certain things are just quicker to implement. Why? Writing Java is really very fast these days, especially with IDE's. I can get a small web site serving JSON REST requests and memcache up in ten minutes with a simple Maven/Gradle build and full IDE integration.

You know what isn't as quick? Websockets, non-trivial asynchronous code, boilerplate, and build times. The vast majority of my company is built on Java and we're not encumbered by legacy code, so we get to play with all the new stuff. I don't need to be convinced that Java (or even more specifically the JVM) is a good choice for many practical reasons. I live in IntelliJ and Gradle (and Maven too) all day, you're pre…

I agree that Java's async support is bad (haven't had to use it much since I've been primarily Scala for years now), but I'm surprised a PoC would need to be async in the first place? Conventional one-thread-per-request is fine for non-prod, no?

Re: Hard-won lessons: Five years with Node.js

#204
post #91
post #75

Earlier quoted context omitted.

NodeJS has a handful of things that tend to get brought up. Callback soup and difficult error handling. Both are resolved by promises. Once you get the hang of promises, you are capable of doing concurrent asynchronous tasks in a manner that would be significantly more difficult in any other language. On top of that, NodeJS is very, very fast. Compared to Python or Ruby, straight computing is significantly faster, bu…

> Once you get the hang of promises, you are capable of doing concurrent asynchronous tasks in a manner that would be significantly more difficult in any other language. What languages are you comparing against? It seems like asynchronous code is more difficult to write in NodeJS than in C#, Go, or Rust, and about the same as Java. I can write code in Java in a style similar to promises using ListenableFuture (Google…

that's a lot of text you wrote for something that will get automatically disregarded by anyone with a brain for having mentioned plaintext response benchmarks

Re: Hard-won lessons: Five years with Node.js

#205
post #170

Earlier quoted context omitted.

No one cares how you wrote 6 years ago, today the way to do it (as I've been told by many people who write NodeJS applications all the time) is to use transpilers. And: > most ES6 features Most. Ugly word. Really ugly word.

That's a way to do it. It is not the only way to do it, even if some people do it that way all the time. I might add a transpiler for Typescript to my stack soon, if that language turns out as pleasant to work with as I've been hearing. If I do, it'll be the first time I use one. And I've been working with Node, in production, since 2013.

Go away. I've invested weeks to learn something which at least resembles NodeJS best practices and now you come along and say "nope, we do it different" ... :(

(That was a joke btw. Thanks for the info. The consensus seemed to be that Babel is the way to go, but if your variant works for you good to hear. I will still stay with it. I like ES6 imports in Node.)

Re: Hard-won lessons: Five years with Node.js

#206
post #158
post #138

Earlier quoted context omitted.

> huge complicated tools. Oh please. Let's be real, Maven is not even remotely more complicated than the typical package.json, webpack.config.json, .babelrc triple you need for any useful NodeJS project (though you can put the .babelrc into the package.json, I've heard that's the way to do it at the moment). I was so taken back that nowadays JS needs a build step too. But it's a "transpiler", not a "compiler" - cause…

No I want to use the command line. https://maven.apache.org/guides/getting-started/maven-in-fiv... Maven quick start first command: > mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false Then it generates stupidly deep Java structure. and next you have to write a verbose xml. They even say: > The POM is huge and can be daunting…

> Then it generates stupidly deep Java structure.

It generates enough structure to scale up to reasonable projects. The nesting is a price well worth paying for consistency. Every maven project puts its source in the same structure, with the result that you can jump into any project and know how its build will work and where to find the source.

> All of this stuff is verbose and built to be generated by IDEs. It's not clear, it's not concise.

Verbose is worth it for clarity, particularly in a file you edit rarely. It may not be concise but it absolutely is clear, as the example from your own link shows.

Re: Hard-won lessons: Five years with Node.js

#207

Earlier quoted context omitted.

You're just repeating the same claim without any evidence. Why is it faster to write code in a dynamically typed language? Most modern statically typed languages have type inference so you don't even need to write type annotations for the most part, assuming these extra characters were the reason. So what's that mysterious reason that makes writing dynamically typed language faster?

> So what's that mysterious reason that makes writing dynamically typed language faster? Less ceremony.

But no ceremony is necessary in the cases where types can be inferred - and in the cases where types can't be inferred you probably do want to to be explicit about them even in a dynamic language.

Re: Hard-won lessons: Five years with Node.js

#208
post #163
post #138

Earlier quoted context omitted.

> huge complicated tools. Oh please. Let's be real, Maven is not even remotely more complicated than the typical package.json, webpack.config.json, .babelrc triple you need for any useful NodeJS project (though you can put the .babelrc into the package.json, I've heard that's the way to do it at the moment). I was so taken back that nowadays JS needs a build step too. But it's a "transpiler", not a "compiler" - cause…

> So? Atom and Visual Studio Code did need to be installed too on my machine. This mentality reminds me of someone using an axe head as a hammer "I'd have to pull the hammer out of the toolbox" (install it) - that's too complicated, I prefer light-weight tools!" You misunderstand my point completely. I was trying to say the Java ecosystem is complicated and the only way it works is by using large IDEs. Saying how awe…

Most Java people I know use IDEs mostly just to edit and debug the code, and does the builds/runs/tests from the command line.

Re: Hard-won lessons: Five years with Node.js

#209
post #190
post #15

I can't imagine choosing to write Javascript on the server, but considering its popularity I'm wondering if I'm wrong. So I'm curious as to the reasons people chose Node.js and whether you would recommend it, anybody willing to share their experiences?

If you are using a web framework, and are considering switching to a systems language, and your developers already have a lot of experience in JavaScript, that's when you should consider NodeJS! I had a lot of JavaScript experience before switching to NodeJS, but it still was a huge step, you have to learn systems architecture, and distributed systems (async programming). I think JavaScript is easier then Java and C/…

I have a hard time really seeing this as a net win. There are huge upsides to having the same language on both sides - but the big downside is that javascript simply isn't a very good backend language. Node.js/v8 is incredibly impressive for what it is. But it still has "shoehorned" written all over it. (For the record: I wouldn't consider Java the Language a pinnacle either.)

Re: Hard-won lessons: Five years with Node.js

#210

Earlier quoted context omitted.

V8 is a world class compiler. Compared to ruby, Python, Erlang, php and that ilk it is lightning quick. (Pypy is a good match for it but it's not main street and you can't just use any module.) in terms of performance and popularity, v8/node stand pretty much alone as far as dynamic non-compiled environments. JavaScript has a lighter weight feel than Java and the jvm stack. Single threaded with a top notch event reac…

> V8 is a world class compiler. Compared to ruby, Python, Erlang, php and that ilk it is lightning quick. Not to nitpick details, but V8 is a runtime , not a compiler. A compiler checks your code and tells you if it contains errors before you run it. V8 does not.

V8 is a JIT compiler, which incorporates a runtime and a compiler.
Post reply on HN