Live data from Hacker News

The melting pot of JavaScript (2017)

increment.com

71–80 of 200 posts

Re: The melting pot of JavaScript (2017)

#71

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…

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?

Re: The melting pot of JavaScript (2017)

#72

Earlier quoted context omitted.

JS or anything that compiles well to JS has a backend advantage that can be hard to beat for an early stage startup and that is reducing the amount of context switching you have to do in changing between languages (especially if your code is isomorphic). At least, that is how I find it, my productivity shoots up when I don't have to be moving between two imperative languages that most likely share a lot of their synt…

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 !

Re: The melting pot of JavaScript (2017)

#73

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…

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

There's no easy way to inspect the runtime in js to find all functions or all classes that can be loaded/called.

There's no way to hook into the loading of modules in a standard way - you have to know how the modules are compiled and required.

Re: The melting pot of JavaScript (2017)

#74
post #61
post #22

Is it unfair to say that some of these problems are caused by a lack of awareness (or an unwillingness) to learn from other communities (like, Ruby, Java etc) that have solved these some of these problems already?

No. And that is also why JS is successful. Newbies with little oversight create new tools. Of thousands of them, one or two become popular because of non-functional reasons (right blog post, right fit, easy use, ..). Welcome to the mess :)

Tech pop-culture... Navigating these technology growth explosions is like searching for solid reference architecture in a booming shantytown. Some parts of these settlements eventually get things like running water, working sewage, urban planning.

Re: The melting pot of JavaScript (2017)

#75

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…

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

Re: The melting pot of JavaScript (2017)

#76

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 me much better code reviews because they all know the language. But we will see going forward, still very much a green field project.

Re: The melting pot of JavaScript (2017)

#77

Very nice points here. I've always been struck at how the JavaScript community never really adopted the Rails ideas of convention over configuration and optimizing for developer happiness. While it's easy to roll one's eyes at the marketing lingo, these principles do truly make Rails a charm to use. Right now, even setting up the most simple Webpack-Babel-Node config requires writing a whole lot of config and set up…

In JS there is a lot of convention but on a micro level. The times of monolithic Rails apps which have strict conventions are over and it's good: Too much magic and strict conventions often forced devs into patterns which didn't match the use case. Even experienced Rails devs tried to solve every problem the same way. You also confusing matters. You need Webpack, Babel etc for the frontend not the backend. And even i…

Simply not true. Rails continues to be the choice for many companies who don't base tech choices on what the latest bandwagon is.

JS is mess.

Re: The melting pot of JavaScript (2017)

#78
post #70

Very nice points here. I've always been struck at how the JavaScript community never really adopted the Rails ideas of convention over configuration and optimizing for developer happiness. While it's easy to roll one's eyes at the marketing lingo, these principles do truly make Rails a charm to use. Right now, even setting up the most simple Webpack-Babel-Node config requires writing a whole lot of config and set up…

Ember is exactly that. I love it and use it on my day job and on my side-project. But overall it doesn't have much adoption and no perspective to grow anymore.

I've wanted to use Ember, but I've never bothered to sit down and learn it. What ever happened to Glimmer? I remember it being hyped up as a crazy fast virtual DOM, but I haven't heard anything recently.

Re: The melting pot of JavaScript (2017)

#79
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 is actually very pleasant on the server:

    const results = await Promise.map(urls, (url) => process(url), { concurrency: 8 })
        .then((results) => postprocess(results))

Re: The melting pot of JavaScript (2017)

#80

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?

http://immutables.github.io/ makes great use of this feature in Java
Post reply on HN