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

Hard-won lessons: Five years with Node.js

blog.scottnonnenberg.com

Post reply on HN
Print view View original

341–350 of 365 posts

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

#341

Post by lawik »

lmm wrote: post #206
rapsey wrote: post #158

Earlier quoted context omitted.

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 no…

I'm sure the tooling is useful and a lot of it reasonable. I've never approached a Java project that I did not find intimidating, either Android with all the Gradles and XML.

I've never seen a barebones project as you would when using just node+npm without all the extra tooling (webpack and friends). Node+npm is to me as simple as python+pip. Is there a natural counterpart, Java+maven or something?

And to be fair. All my attempts at approaching webpack have been even worse. And most JS-framework seed projects are similarly complex and automagical.

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

#342

Post by lmm »

lawik wrote: post #341
lmm wrote: post #206

Earlier quoted context omitted.

> 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 no…

I'm sure the tooling is useful and a lot of it reasonable. I've never approached a Java project that I did not find intimidating, either Android with all the Gradles and XML. I've never seen a barebones project as you would when using just node+npm without all the extra tooling (webpack and friends). Node+npm is to me as simple as python+pip. Is there a natural counterpart, Java+maven or something? And to be fair. Al…

I don't think you need anything other than java+maven. That's all my projects use as far as I'm aware. Android probably requires some additional stuff for its packaging but I just enabled the maven android plugin and trusted that to handle it - if there's any other config I haven't been touching it.

The grandparent linked to the maven getting started, https://maven.apache.org/guides/getting-started/maven-in-fiv... . That shows what the minimum looks like - a pom.xml, and application source code in src/main/java (under its package structure). (The unit test isn't strictly necessary but is good practice).

The pom's XML header and modelVersion are boilerplate, but the rest is pretty clear and self-explanatory (though admittedly verbose).

At that point for a library project you're sorted, for an application you can run your program via "mvn exec:java" which is adequate for development. To actually package up your application for distribution you probably want to use the shade plugin a la https://maven.apache.org/plugins/maven-shade-plugin/examples... , but that's something you'd do as part of "productionisation". (Back when I worked at an early-stage startup we had things running and serving user requests via "mvn exec:java")

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

#343

Post by lmm »

lawik wrote: post #339
lmm wrote: post #203

Earlier quoted context omitted.

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?

I'm surprised that you consider it controversial that a highly dynamic language can be considered fast to PoC something in than Java. There is just less typing/code that needs to be defined (I know IDEs help). Also easier to do quick and dirty stuff that I imagine would be more restricted in Java. No classes to define, just throw your values in there. I prefer python in general but for zero-to-simple-web-endpoint I m…

> I'm surprised that you consider it controversial that a highly dynamic language can be considered fast to PoC something in than Java.

Sure, but that wasn't the argument; GP talked specifically about async and websockets, which are areas where Java is particularly weak, but areas that I was surprised would be required for a PoC at all.

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

#344

Post by brlewis »

mattmanser wrote: post #333
brlewis wrote: post #326

Earlier quoted context omitted.

My comment about the NaN bug: https://news.ycombinator.com/item?id=14156595

I disagree with that assessment. Users reported the order was wrong, he simply had to look at those users and their live data to replicate it. Even in those scenarios, I rarely have to look at live data, reading the code is often enough to identify it or playing around a little bit. The patience to replicate a bug before trying to fix it. This is the essence that sets apart a good debugger from a bad one. A bad one r…

I have had times when I used logging and then realized I should use a debugger instead.

I have had times when I used a debugger and then realized I was never going to find the problem that way; I needed a larger amount of information that only logging could provide.

I've only been programming about 30 years so I probably haven't hit my peak yet, but my guess is that even with more experience I'll still want to use both tools.

Debug logging doesn't have to be litter either. Instead of commenting out use log levels like with https://www.npmjs.com/package/debug-logger

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

#345

Post by coldtea »

hota_mazi wrote: post #283
coldtea wrote: post #212

Earlier quoted context omitted.

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()?

It's different in that it's optional in Python.

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

#346

Post by rusk »

cookiecaper wrote: post #312
rusk wrote: post #191

Earlier quoted context omitted.

"if you don't stay up to date with your depends, things change fast and sometimes they change a lot." This, was actually one of the things I liked most about Node.js - npm allows a developer to specify all dependencies (`pacakage.json`), versioned, similarly to maven but not as clunky. I was able to get up to speed project very quickly and easily using just `npm install`. I had one or two versioning issues to iron ou…

Not sure what your other experience is, but most dynamic languages have simple package management platforms similar to npm. As you note, Java has Maven/Ant and C# has NuGet, both of which are substantially more "enterprisey". It'd be interesting to hear a fair, modern comparison between npm, ruby-gems, LuaRocks, pip/PyPI/cheeseshop, and the other big ones I'm sure I'm forgetting. The JavaScript community has had a lo…

A "Battle of the dependency managers" if you will .. sounds great!

I mentioned NPM in particular in the context of this being a node.js discussion. I've seen a few comparable tools in my time but IMHO NPM may be one of the cleanest, considering this as a feature of node.js - it does add to its attractiveness as a development environment.

Yeah it took the JS community ages to sort this out, but in NPM there seems to be an answer.

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

#347

Post by lawik »

lmm wrote: post #342
lawik wrote: post #341

Earlier quoted context omitted.

I'm sure the tooling is useful and a lot of it reasonable. I've never approached a Java project that I did not find intimidating, either Android with all the Gradles and XML. I've never seen a barebones project as you would when using just node+npm without all the extra tooling (webpack and friends). Node+npm is to me as simple as python+pip. Is there a natural counterpart, Java+maven or something? And to be fair. Al…

I don't think you need anything other than java+maven. That's all my projects use as far as I'm aware. Android probably requires some additional stuff for its packaging but I just enabled the maven android plugin and trusted that to handle it - if there's any other config I haven't been touching it. The grandparent linked to the maven getting started, https://maven.apache.org/guides/getting-started/maven-in-fiv... .…

Appreciate the overview. It sounds similar to what I'm used to but, as you say, perhaps a bit more verbose. And some stuff is non-obvious to me, such as mvn exec:java instead of my-java-runtime main.java or whatever.

I've encountered a bit of this with most AOT-compiled stuff except for Go. Make or compiler-flags also requires a bit of learning to get going.

Most dynamic languages tend to be more straight-forward with this.

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

#348

Post by lawik »

lmm wrote: post #343
lawik wrote: post #339

Earlier quoted context omitted.

I'm surprised that you consider it controversial that a highly dynamic language can be considered fast to PoC something in than Java. There is just less typing/code that needs to be defined (I know IDEs help). Also easier to do quick and dirty stuff that I imagine would be more restricted in Java. No classes to define, just throw your values in there. I prefer python in general but for zero-to-simple-web-endpoint I m…

> I'm surprised that you consider it controversial that a highly dynamic language can be considered fast to PoC something in than Java. Sure, but that wasn't the argument; GP talked specifically about async and websockets, which are areas where Java is particularly weak, but areas that I was surprised would be required for a PoC at all.

Fair enough. I was mostly responding to the thread of discussion overall. I realise now that I was probably reacting more to the viewpoint of hota_mazi.

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

#349

Post by PerfectDlite »

jerryszczerry wrote: post #323
PerfectDlite wrote: post #321

Earlier quoted context omitted.

> because Java is unusable without them This is like saying 'Javascript is unusable without IDEs', you know.

And this is making Java look good how exactly?

This makes all programmers liking to write code with maximum level of comfort - e.g. using IDEs.

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

#350

Post by lmm »

lawik wrote: post #347
lmm wrote: post #342

Earlier quoted context omitted.

I don't think you need anything other than java+maven. That's all my projects use as far as I'm aware. Android probably requires some additional stuff for its packaging but I just enabled the maven android plugin and trusted that to handle it - if there's any other config I haven't been touching it. The grandparent linked to the maven getting started, https://maven.apache.org/guides/getting-started/maven-in-fiv... .…

Appreciate the overview. It sounds similar to what I'm used to but, as you say, perhaps a bit more verbose. And some stuff is non-obvious to me, such as mvn exec:java instead of my-java-runtime main.java or whatever. I've encountered a bit of this with most AOT-compiled stuff except for Go. Make or compiler-flags also requires a bit of learning to get going. Most dynamic languages tend to be more straight-forward wit…

> some stuff is non-obvious to me, such as mvn exec:java instead of my-java-runtime main.java or whatever.

That's kind of our way to do virtualenv-like functionality, which is mandatory rather than optional. (Or you can specify the classpath manually in the same way you would for the pythonpath, but no-one wants to do that). IMO that's the right thing - having libraries installed in my system python has only ever caused trouble in the long- or even medium-term, even if it makes "hello world" use of libraries very slightly simpler.

There's probably a way to get a shell with the classpath set up correctly, but I always found that kind of modalness more confusing than helpful.

> I've encountered a bit of this with most AOT-compiled stuff except for Go. Make or compiler-flags also requires a bit of learning to get going.

In my experience it does all work without any flags or extra knowledge. "mvn" is the entry point for all the things you want to do - you don't ever have to know that there's a "java" and "javac" underlying it.

Post reply on HN