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

181–190 of 200 posts

Re: The melting pot of JavaScript (2017)

#181

Post by beatgammit »

hombre_fatal wrote: post #79
ausjke wrote: post #30

I never got the idea of nodejs or javascript for backend, tried it a few times and eventually returned to python and java. It's much easier for python/java to add event-loop and/or restful framework than making javascript looks like python/java one day as far as backend goes. In 2019 I still have 0 interest in javascript/TS for backend, the thousands of modules under node_modules alone is enough for me, and not all r…

You don't get to just add an event loop and start writing async code in Python or Java. It opens up its own can of worms now that you're straddling the sync and async worlds. Compare working with Netty (async) to Jetty (sync). It's certainly not trivial. That Javascript is async-everything is one of its best and often overlooked features in these comparisons. I think this snippet encapsulates a lot of why Javascript…

I don't think it is overlooked. JavaScript doesn't scale, both in terms of code complexity (callback hell) and across cores, and the "gold standard" these days is microservices, which has a ton of issues.

If you want to look at bolt-on async working, check out C# or Rust. They've basically taken JavaScript's new async/await and added threading (at least Rust has, not sure about C#). You can write an async app and have it run in a thread pool without much fuss.

I don't know what the story is for Java, but seeing as C# is effectively the same thing, it's not hard to imagine adding async being easier than adding threads or performance to JavaScript.

Re: The melting pot of JavaScript (2017)

#182

Post by sonnyblarney »

pjmlp wrote: post #157
adrianN wrote: post #132

Earlier quoted context omitted.

JSON is how some data is passed today. It's certainly not the best way and might go out of style just like XML did a while ago.

It is already on its way out, thanks to gRPC and need for performance instead of parsing text all the time. It is only a matter of browsers getting native support for gRPC.

It's available now! Yay! [1]

With gPRC there's still a lot of binding code, and you need to map all of that in Java, but you do get some validation etc. out of it. It does make the 'data transfer' comparison a little less harsh.

[1] https://github.com/grpc/grpc-web

Re: The melting pot of JavaScript (2017)

#183

Post by pjmlp »

sonnyblarney wrote: post #182
pjmlp wrote: post #157

Earlier quoted context omitted.

It is already on its way out, thanks to gRPC and need for performance instead of parsing text all the time. It is only a matter of browsers getting native support for gRPC.

It's available now! Yay! [1] With gPRC there's still a lot of binding code, and you need to map all of that in Java, but you do get some validation etc. out of it. It does make the 'data transfer' comparison a little less harsh. [1] https://github.com/grpc/grpc-web

Not really, I meant as browser builtin API, implemented in native code.

Re: The melting pot of JavaScript (2017)

#184

Post by Traubenfuchs »

sonnyblarney wrote: post #172
Traubenfuchs wrote: post #162

Earlier quoted context omitted.

> doing JSON in Java is an ugly, ugly thing Why do you think so? Jackson and Gson work very well. Serialising and deserialising from/to POJO/JSON is trivial with them.

JSON and Javascript data objects are essentially directly interchangeable. In Java, you have to abstract the document and write a lot of code to access, add, remove things etc. - or - because there is no such thing as an untyped POJO in java, you have to set up a ton of things if you want to use real objects.

Instead of using a typed POJO you can deserialize/serialize a Map.

You could also use a POJO for the fields you know and put a map inside for the fields you don't know.

If that's not enough you can use JsonNode, or ObjectNode where you can freely add and remove json values.

Re: The melting pot of JavaScript (2017)

#185

Post by pdimitar »

int_19h wrote: post #179
pdimitar wrote: post #148

Earlier quoted context omitted.

Are you not forgetting something? Java is to this day several times faster than JS and sources for that abound on the net (including [0]). No, we wouldn't fight for how to compile C in it. We would very likely fight to make the payloads and bootstrap times smaller. [0] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Faster than JS doesn't make it fast enough. Look at how it fares versus C in those same tests.

Fair, but do we really need C levels of performance on the web? That's madness. They are mostly CRUD apps for God's sake. They don't have to be able to run liquid simulations at 200FPS.

IMO the level of Java / Erlang performance is, and should always be, plenty enough for the web.

Re: The melting pot of JavaScript (2017)

#186

Post by adrianN »

BigJono wrote: post #180
adrianN wrote: post #133

Earlier quoted context omitted.

I don't see how linting and experience prevents logic errors, missed corner cases, or misunderstandings of the requirements. In my experience integration tests are crucial to robust software.

I don't see how unit testing prevents that stuff either. How do you write a unit test for a corner case if you've missed it? If you're aware of it's existence, why not just update the code to handle it?

Quickcheck like libraries are reasonably good at finding missing corner cases in my code. It also helps if the person writing the test is different from the person writing the code and the person writing the requirement.

Re: The melting pot of JavaScript (2017)

#187

Post by sonnyblarney »

pjmlp wrote: post #183
sonnyblarney wrote: post #182

Earlier quoted context omitted.

It's available now! Yay! [1] With gPRC there's still a lot of binding code, and you need to map all of that in Java, but you do get some validation etc. out of it. It does make the 'data transfer' comparison a little less harsh. [1] https://github.com/grpc/grpc-web

Not really, I meant as browser builtin API, implemented in native code.

No, that's not on the roadmap and I doubt it ever will be.

It's a very specific technology, and as long as it can be implemented fairly efficiently 'up the stack' in JS, then it mostly belongs there. Aside from HTTP2 (which is a roadblock now, but not soon) it'll be fine in JS.

Re: The melting pot of JavaScript (2017)

#188

Post by sonnyblarney »

Traubenfuchs wrote: post #184
sonnyblarney wrote: post #172

Earlier quoted context omitted.

JSON and Javascript data objects are essentially directly interchangeable. In Java, you have to abstract the document and write a lot of code to access, add, remove things etc. - or - because there is no such thing as an untyped POJO in java, you have to set up a ton of things if you want to use real objects.

Instead of using a typed POJO you can deserialize/serialize a Map . You could also use a POJO for the fields you know and put a map inside for the fields you don't know. If that's not enough you can use JsonNode, or ObjectNode where you can freely add and remove json values.

Ok, touché, good point.

Re: The melting pot of JavaScript (2017)

#189

Post by johnwyles »

2trill2spill wrote: post #91
johnwyles wrote: post #89

Earlier quoted context omitted.

As I said above: hire someone new or invest the time to learn the language. Just because someone knows how to make a cute scarf using duct tape, safety scissors, and Elmers glue doesn't mean they should be building your backend driving the company 95 mph with seatbelts, airbags, and a chassis with crumple-zones.

Hiring someone is very time consuming, and requires paying another salary, benefits, etc. Also learning a new language takes time, yes a person can learn the basics of a language in a day or two, but it will be a long time before they are equally proficient with that new language.

You said nothing that wasn't painfully obvious. My point is to build the backend right so you don't have to rewrite it again later. The time investment in the beginning will pay dividends as you scale (unless you are just mocking up or making an MVP)

Re: The melting pot of JavaScript (2017)

#190

Post by sam0x17 »

pdimitar wrote: post #145
c-smile wrote: post #29

Earlier quoted context omitted.

I've architected Web Application that runs as in a) connected as in b) occasionally disconnected mode (LocalStorage + sync when online). For #b SPA is the only option.

Nobody is saying that SPAs using modern web technologies -- like offline mode -- do not have any use. The problem is that SPAs are shoehorned on many places where they are absolutely not necessary and only complicate things.

To me SPA = no server side page generation + an API server. Maybe I use the term too generally.
Post reply on HN