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

171–180 of 200 posts

Re: The melting pot of JavaScript (2017)

#171

Post by com2kid »

_hardwaregeek wrote: post #116
com2kid wrote: post #100

Earlier quoted context omitted.

> I do think create-react-app is a good innovation in the JS world. However, I've never found a good equivalent on the back end. Setting up even the most basic CRUD REST API requires a whole lot of typing for very little reward. This is where services like Google Firebase Functions become useful. I went from having never written a REST API in my life, to up and running in under 20 minutes. First time I went to create…

Firebase is a dream. It's almost a shame they got bought by Google because it's such a fantastic idea. All of the things I used to dread setting up (auth, deployment, serverless) are automated and dead easy. The documentation is clear and caters to the common usecases. I managed to set up a Sendgrid email that sends on database writes within an hour or two.

> The documentation is clear and caters to the common usecases.

I wouldn't quite say that, but I'll agree with your other points. :)

(More than once the docs have been out of date, or just flat out wrong, costing me many hours of development time...)

Re: The melting pot of JavaScript (2017)

#172

Post by sonnyblarney »

Traubenfuchs wrote: post #162
sonnyblarney wrote: post #129

Earlier quoted context omitted.

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

> 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.

Re: The melting pot of JavaScript (2017)

#173

Post by lopatin »

pitaj wrote: post #168
lopatin wrote: post #112

Earlier quoted context omitted.

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

I was talking about JavaScript. In JavaScript there are no typed functions or arguments, so that information doesn't exist period.

Right, so I guess I'm not understanding your point about why comparing two languages like this is ridiculous. Java has a full blown runtime reflection system (it's "types exist at runtime"). JS doesn't. So Java wins in the reflection category.

Re: The melting pot of JavaScript (2017)

#174

Post by tracker1 »

lopatin wrote: post #173
pitaj wrote: post #168

Earlier quoted context omitted.

I was talking about JavaScript. In JavaScript there are no typed functions or arguments, so that information doesn't exist period.

Right, so I guess I'm not understanding your point about why comparing two languages like this is ridiculous. Java has a full blown runtime reflection system (it's "types exist at runtime"). JS doesn't. So Java wins in the reflection category.

But in JS, reflection is pretty much not needed... I don't need to use reflection to see if an object has a quack method, or that I call it with the right types... I just call instance.quack() ... It's up to you as the developer to keep your interfaces and composition in line.

It's actually WAY easier than with C# or Java. Since the use-case of reflection itself is largely unnecessary.

Re: The melting pot of JavaScript (2017)

#175

Post by tracker1 »

stickfigure wrote: post #136
hajile wrote: post #128

Earlier quoted context omitted.

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).

you can look everything over at runtime Correct, that's what you have to do in dynamic languages - look at what came in from the database and manually validate+convert it into the format you actually want. Also with pretty much every other form of input (JSON bodies, form posts, queue messages, etc). It's a lot of tedium. When working with node/python/ruby, I often find myself wishing I could just declare a type and…

Why do I need to manually convert anything? Even then...

    var results = (await sql.query`
      ...
    `).recordsets[0].map(rowToObject);
It's really easy... no need for complicated ORM/ODM tooling at all.

As far as the size... create a docker container from node:10-alpine to run a given node application, and create a similar container with any application running full Java. And compare the final size.

Re: The melting pot of JavaScript (2017)

#176

Post by tracker1 »

hombre_fatal wrote: post #75
orangeeater wrote: post #35

Earlier quoted context omitted.

> Js barely even supports reflection. This is a huge underrated shortcoming of js if you're doing anything complicated Can you explain what Java offers with regard to reflection that JS doesn't? My feeling is that reflection is almost moot in JS since you can inspect/mutate objects at runtime however you like. But maybe I'm missing the point of reflection. There is a Reflect object with a bunch of static methods on i…

One example would be a url router for a web server that turns the url variables into the handler's expected argument type and ignores requests that do not. router.get('/users/:id', (id: UUID) => ...) router.get('/products/:id', (id: Int) => ...)

That would be relatively easy to do something very similar with middleware for express/koa

    router.get('/users/:id'. skipNonUuid(id => ...))
You simply have a function/middleware that does the check.... or `compose(skipNonUuid, dbo.findUserById, ui.formatView('modelName'))`

You can do function composition that is nearly as simple and far more flexible in general with JS

Re: The melting pot of JavaScript (2017)

#177

Post by tracker1 »

2trill2spill wrote: post #76
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…

While I agree with you, I just started a new project and we need a decent amount of backend work done, and I wanted to do that in Golang, Java, or Rust, but no one else on the team knows Golang, Java or Rust, just Javascript and Typescript so it made sense to go with a language the team was good with. So far I'm liking typescript on the backend, especially because we use it on the frontend. Also my coworkers can give…

I find that beyond this, not having a cognitive disconnect in working on the frontend/backend is really nice. And depending on your data tier(s), can even go there (Mongo, Plv8, etc).

Compared to when I'd have to use ActionScript, JavaScript, VBScript, VB6, T-SQL daily... that was sometimes painful... then adding C# and VB.Net to the mix was ugly having to switch from one area of code to another.

Re: The melting pot of JavaScript (2017)

#178

Post by tracker1 »

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…

I can't speak for anyone else... but I learned javascript and even liked it for most of the reasons outlined before the Good Parts book came out.

Since ES6 it's even better.

Re: The melting pot of JavaScript (2017)

#179

Post by int_19h »

pdimitar wrote: post #148
int_19h wrote: post #135

Earlier quoted context omitted.

> Where we would be now if we were allowed to run Java bytecodes in browser directly from the very beginning? We'd be ranting at JVM for not having the features necessary to compile high-perf C code into it, for one. Which is why Wasm is fundamentally a better approach. It's that one case where it makes sense to go as low level as possible (while retaining cross-platform support), to allow as many future possibilitie…

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.

Re: The melting pot of JavaScript (2017)

#180

Post by BigJono »

adrianN wrote: post #133
spricket wrote: post #125

Earlier quoted context omitted.

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 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?
Post reply on HN