Live data from Hacker News

Hard-won lessons: Five years with Node.js

blog.scottnonnenberg.com

281–290 of 365 posts

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

#281

Earlier quoted context omitted.

a compiled language, yes. But the function of a compiler, between a compiled language and an interpreted language, remains the same. It translates code from one representation to another.

This is really simple. Do you use V8 to compile your code or to run it? Just because V8 has a compiler, doesn't make it a compiler. Do you see the difference?

V8 compiles code into bytecode and runs that. This is really simple.

V8 is a JIT compiler. It both compiles code and runs it. For your original complaint about not being able to compile JS up front, you're talking about Ahead-Of-Time (AOT) compilation. You don't seem very familiar with the relevant terminology.

In fact, I just looked it up and apparently V8 compiles JS directly to machine code rather than bytecode: https://en.wikipedia.org/wiki/Chrome_V8.

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

#282

This looks like how I used to work with BASIC back in the 80s: > I finally added extremely verbose logging ... started adding logging ... Verbose logging to the rescue ... I had the right logging in place ... My first step was to jump in and add some key logging statements ... added extremely verbose logging Weird to see people happy to be limited to such stone-age work-flows when fully capable debuggers have existed…

> Based on this, it's hard not to state that current Node-developer are the new PHP-developers: Unsophisticated, completely unable to see when the tools at hand are lacking, and happy with a with whatever they can get running. Comments like this are not the problem with HN. The fact that they get voted, literally, to the top, is.

It's not a bad comment, it's just blunt. I also have a similar stories as the parent commentator, 8-10 years ago when you had even more awful programmers I would sometimes agree to fix something for someone desperate as their own coder had disappeared/failed/etc.. Sometimes even in a language I'd never even used. I'd open some random PHP project, or VBScript, or whatever and find loads of commented out print statements surrounded by some godawful code.

And it'd often be quite a simple logic bug that I could see straight away.

Regularly using logging for debugging is often an inexperienced developer's crutch. It's a red flag, the sign of the desperate, that they can't comprehend their own code or don't seem to understand the business logic.

It can be a bad substitute for replicating the problem, reading the code + using a debugger.

Sometimes it really is justified. The author seems to have relied on it a lot though.

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

#283
post #207

Earlier quoted context omitted.

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.

It's not just the types, it's the whole APIs, culture etc. Java, for example, is no picnic, whether it can now infer some types or not. In Python I don't even need a main().

How is

    if __name__ == "__main__":
        main()
different from a main()?

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

#284
post #81

Earlier quoted context omitted.

My reasoning: all of the dynamically-typed languages are more or less the same on the server for CRUD apps, so I might as well use Javascript.

I find there are really big differences between the dev experience in Python, Node, Clojure and Erlang. JS doesn't trap errors[1], so it's tedious to debug or to have confidence in correctness, and the callback hell APIs are high friction in interactive/REPL development. Node is a fine vessel for running ClojureScript though ;) [1] See eg the bit about NaNs in the article.

I agree that Node once felt tangibly worse. I used Clojure for three years to avoid Node until I had to use Node at work (nobody was going to learn Clojure) and I discovered Koa when it just released.

Even back in Koa 1, co/yield/function* closed the gap for me. Nowadays it's much better with ubiquitous promise usage and async/await.

I miss various things about Clojure like the editor-as-a-repl development cycle, but in my opinion, they still amount to small technical differences that play second fiddle to business concerns.

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

#285

Earlier quoted context omitted.

> Based on this, it's hard not to state that current Node-developer are the new PHP-developers: Unsophisticated, completely unable to see when the tools at hand are lacking, and happy with a with whatever they can get running. Comments like this are not the problem with HN. The fact that they get voted, literally, to the top, is.

It's not a bad comment, it's just blunt. I also have a similar stories as the parent commentator, 8-10 years ago when you had even more awful programmers I would sometimes agree to fix something for someone desperate as their own coder had disappeared/failed/etc.. Sometimes even in a language I'd never even used. I'd open some random PHP project, or VBScript, or whatever and find loads of commented out print statemen…

>Sometimes it really is justified.

Like in the situations in the article. That's why the comment in question is not just blunt. It's a bad comment.

A good comment would take a specific instance of using logging and said why setting a breakpoint / using a debugger would have solved that particular mystery faster.

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

#286

Wow, working with Node sounds like a huge pain in the ass.

This is always my take away. Quoting from an above post

>>Ie. Be okay if a syntax error crashes your server.

Really? I need to set something up to stop a syntax error not crashing the server

These rapid prototype arguments don't hold either imo. I can knock out quick and dirty java / c# apps plenty quick enough that work fine for their needs. In my forays into dynamic languages there is no rapid development due to all the errors, the lack of IDE capability, the compiler replacing tests I have to write

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

#287
post #203

Earlier quoted context omitted.

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?

A lot of projects my team did at my last company were of the "You've got 2 or 3 weeks to build this awesome thing for a launch event that will have a crushing wave of usage for about 3-7 days".

It was really fun work, because even the 'simple' stuff we built had to address some of the big traffic issues you'd normally have at a much larger scale and the work was usually very high concept or cutting edge. It would've been a nightmare to maintain for longer than a week though.

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

#288

Earlier quoted context omitted.

> The edit/refresh cycle starts to slow IDEA and Eclipse compile your code as you write it. And with Hotswap, you don't even need to redeploy anything. They also all offer REPL's that are much more sophisticated than anything Javascript has to offer. I think you haven't used a JVM language and its ecosystem in a very long time.

I use Java today daily, and came from Node. It is slower to have the compile step, even on very powerful machines, dynamic types are faster to change, and there are many caveats to hot reload. The repl comment was about is about speed, not sophistication. When something happens instantly versus a tiny pause, you don't think about seeing your change immediately on save, versus batching many changes together and then t…

I've found myself getting much better at making testing changes in such a way they can be hotswapped, then batching them up into a change when it's necessary to do a JVM restart. Sometimes I impress myself with how long I can go with just hotswaps, kind of like a code golf, but it's absolutely the biggest time suck of a Java developer's day. Besides meetings.

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

#289
post #221

Earlier quoted context omitted.

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

I don't think so. Npm is included with node and is very simple to use.

Knowing how to use npm and what packages are useful isn't something that is flashed into your brain when you click download on the Node website.

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

#290
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…

> mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

Ah, I can see how this is much more complicated than the good old

    npm install webpack babel-loader babel-core babel-preset-es2015 babel-preset-react --save-dev
Post reply on HN