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

The melting pot of JavaScript (2017)

increment.com

Post reply on HN
Print view View original

121–130 of 200 posts

Re: The melting pot of JavaScript (2017)

#121

Post by stickfigure »

lopatin wrote: post #112
pitaj wrote: post #68

Earlier quoted context omitted.

> getting the return type of a method and getting the input parameter names (+ types) Type information literally doesn't exist at runtime, though. Isn't it kind of ridiculous to compare languages like that?

> Type information literally doesn't exist at runtime, though. Correct if I'm wrong, not all types get erased in Java. Doesn't type erasure only happen for generics? Say I have a non generic, plain Java class and want to inspect one of it's method's return types at runtime to see if it returns class A or class B. I can do that, right?

Yes, you are correct. There are also a number of circumstances in which you can get generic type info - it isn't erased, for example, if you create a concrete subclass of a generic type.

Re: The melting pot of JavaScript (2017)

#122

Post by spricket »

TeMPOraL wrote: post #55
spricket wrote: post #44

Earlier quoted context omitted.

I find it's not an issue as long as you're using a decent "object shipping" layer like gRPC. Really greases up the transition point between different languages. I guess you could hire less proficient engineers which is a sell for startups, but I don't think it's worth the downsides of the current js ecosystem

It's not about RPC, it's about a way of DRYing code between the backend and frontend, using libraries as your copy-paste engine. You pull in the same library (or extract common code to a library) both on the page and on the server, and assume they're both identical. I have mixed feelings about this. I don't feel comfortable with assuming that just because I use the same library in backend and frontend, I don't have t…

Needing to copy code around is largely a JS thing IMO. Java has such good standard and third party library support that I don't see what would be that reusable between the front and backend. Except maybe validators, gRPC doesnt support even basic field validation its annoying.

Re: The melting pot of JavaScript (2017)

#123

Post by spricket »

kangoo1707 wrote: post #72
spricket wrote: post #44

Earlier quoted context omitted.

I find it's not an issue as long as you're using a decent "object shipping" layer like gRPC. Really greases up the transition point between different languages. I guess you could hire less proficient engineers which is a sell for startups, but I don't think it's worth the downsides of the current js ecosystem

JS on both backend and frontend is all about reusability, less context switch and unified toolings. And don't associate less proficient engineers with Javascript dude !

Sorry, it's a stereotype, but in my experience JS is a super common first language devs that know JS and nothing else are less experienced.

Re: The melting pot of JavaScript (2017)

#124

Post by spricket »

me551ah wrote: post #67
spricket wrote: post #26

I really like the kind of sanity that TypeScript brings to JS, super well designed and usually a pleasure to work with. That said, I've worked in many languages and I can't see any reason you would willing write your backend in JS or TypeScript. Java, C#, Rails, and to some extent Python are much saner choices. The massive churn of the JS ecosystem bleeds through to the backend, hard. JS could use a little more of th…

You never really learn javascript, you learn frameworks. I was a js developer about 7-8 years ago and dabbled with jQuery , dojo and the likes and then moved over to backend and mobile development. I tried getting back into javascript again and realized that I just could not get in and start coding. There are a lot more frameworks now that I have to learn to get started and I'm sure that a few years down the line, th…

Highly recommend TypeScript. It brings so much method to the madness. Build tools are another clusterfuck but at least with TS you have a decently structured language with "standard" ways of doing things

Re: The melting pot of JavaScript (2017)

#125

Post by spricket »

2trill2spill wrote: post #98
BigJono wrote: post #97

Earlier quoted context omitted.

> Besides were using Typescript, have automated tests, code reviews and Manual QA, I'm not worried about the code not being solid or robust. Oh god... Yeah, no. None of this stuff is a substitute for actual code quality. Give me a good engineer that refuses to write tests over a mediocre one that does TDD any day.

What kind of "good engineer" refuses to write tests?

I don't write many tests. I've found with experience and heavy linting you can avoid the vast majority of bugs. Not much point to spending a ton of time on tests if they hardly ever break for nontrivial reasons. My normal setup for java is:

Linters: ErrorProne Checkstyle PMD SpotBugs Nullaway

All with highly customized settings

All warnings enabled on javac

Google-java-format to autoformat everything on build.

For runtime analysis: LeakCanary to find memory leaks

Hibernate with interceptors to find long queries

Rest framework or gRPC with interceptors for long calls

Proxied JDBC connector to find long or N+1 queries

Opentracing/Zipkin integration to make debugging crazy stuff easier

NewRelic for projects where the $ makes sense

And I'm always on the lookout for more of these tools. In the long-run they save enormous amounts of time by preventing buggy code and keeping most shitty hacks out of the codebase.

Unlike tests, they don't break constantly and add more maintenance burden to the codebase. And it's less work, one time setup vs ~50% codebase bloat to add tests.

I see project leads call for more tests all the time to "fix" an unreliable codebase where there's zero linting. It won't save you from everything but I swear it's like 95% bug reduction. You should have most/all of these tools in place before you consider writing the first tests

Re: The melting pot of JavaScript (2017)

#126

Post by stickfigure »

kangoo1707 wrote: post #71
spricket wrote: post #46

Earlier quoted context omitted.

Java uses reflection and annotations to support all kinds of language extensions. Js has a lot of nasty issues with the "prototype chain" and annotation support is still experimental. For example, in java, scanning your classes and their annotations to generate code for them at compile time is a standardized feature. Maybe I'm just complaining that JS is too dynamic, but being able to generate code at compile time wi…

Do you have any concrete example for "For example, in java, scanning your classes and their annotations to generate code for them at compile time is a standardized feature"? Tip: in JS, I don't want OOP class. If you really want class, could you show me the intention behind it?

Every popular ORM uses reflection to determine how to map fields to columns. For example, what type of date or money object to use.

I automagically map some postgres JSONB columns to a parsed object form. Looks just like a regular typed nested object.

Re: The melting pot of JavaScript (2017)

#127

Post by austincheney »

spricket wrote: post #26

I really like the kind of sanity that TypeScript brings to JS, super well designed and usually a pleasure to work with. That said, I've worked in many languages and I can't see any reason you would willing write your backend in JS or TypeScript. Java, C#, Rails, and to some extent Python are much saner choices. The massive churn of the JS ecosystem bleeds through to the backend, hard. JS could use a little more of th…

The problem I have with Java is that its a tremendous amount of code to do tiny things. There is a cognitive load that comes from reading. The more code you have to read to perform the equivalent action the more tired you get and the more opportunity you have for errors.

There is something precious to being able to do more with substantially less code, which is why I avoid OOP all together. You can't do that in Java.

Re: The melting pot of JavaScript (2017)

#128

Post by hajile »

stickfigure wrote: post #126
kangoo1707 wrote: post #71

Earlier quoted context omitted.

Do you have any concrete example for "For example, in java, scanning your classes and their annotations to generate code for them at compile time is a standardized feature"? Tip: in JS, I don't want OOP class. If you really want class, could you show me the intention behind it?

Every popular ORM uses reflection to determine how to map fields to columns. For example, what type of date or money object to use. I automagically map some postgres JSONB columns to a parsed object form. Looks just like a regular typed nested object.

That's a solution looking for a problem in JS. You're thinking in types instead of in terms of a dynamic language.

You basically HAVE to do this in Java otherwise your program won't work. In JS, you can look everything over at runtime and dispatch from there (made much easier because first-class functions and closures are a thing).

Re: The melting pot of JavaScript (2017)

#129

Post by sonnyblarney »

spricket wrote: post #26

I really like the kind of sanity that TypeScript brings to JS, super well designed and usually a pleasure to work with. That said, I've worked in many languages and I can't see any reason you would willing write your backend in JS or TypeScript. Java, C#, Rails, and to some extent Python are much saner choices. The massive churn of the JS ecosystem bleeds through to the backend, hard. JS could use a little more of th…

Sympathies to your valid concerns ...

Though Java was 'designed', it was not 'designed' to be an http/web server.

JS, particularly Node.js has really adapted itself to that well.

And one small but massive difference: JSON is how data is passed and it fits seamlessly into Javascript, and doing JSON in Java is an ugly, ugly thing.

As soon as you compare not JS/Java, but Java/Tomcat vs. JS/NodeJS - then you get a different comparison.

I quite like using Typescript on Node.js over Java - development speed is faster, and this is a really important thing.

Re: The melting pot of JavaScript (2017)

#130

Post by luord »

spricket wrote: post #125
2trill2spill wrote: post #98

Earlier quoted context omitted.

What kind of "good engineer" refuses to write tests?

I don't write many tests. I've found with experience and heavy linting you can avoid the vast majority of bugs. Not much point to spending a ton of time on tests if they hardly ever break for nontrivial reasons. My normal setup for java is: Linters: ErrorProne Checkstyle PMD SpotBugs Nullaway All with highly customized settings All warnings enabled on javac Google-java-format to autoformat everything on build. For ru…

> I've found with experience and heavy linting you can avoid the vast majority of bugs.

No, you can't.

In fact, I can't even begin to see how "apply this specific standard to the code" (linting) is even remotely related to "know everything about this particular domain so you don't make any mistakes in creating an application for it" or "know everything about this particular system so that a given difference in configuration screws up your application at run time".

You seem to be primarily a java developer so I understand why you prefer avoiding tests (among the many things that Java makes absurdly difficult, writing tests is one of them) but you should still write tests .

Look at any serious open source project, most of them have hundreds, thousands of tests. It's almost presumptuous to think that one knows more than the community.

> I swear it's like 95% bug reduction.

The only situation where linting really causes that much of an impact, that I've seen, is in an application where a huge portion of the code was just connecting or boilerplate that should've been brought from third party libraries anyway, and was written only because of the NIH syndrome.

Mind you, having code style is necessary so that any given developer can quickly get up to speed and more easily review other developer's code, but it doesn't (nor it shouldn't) tell you whether whatever you wrote actually works.

Assuming otherwise is like pretending that a movie featuring state of the art special effects, cinematography, etc, isn't still Transformers or similar garbage.

Post reply on HN