Live data from Hacker News

The melting pot of JavaScript (2017)

increment.com

61–70 of 200 posts

Re: The melting pot of JavaScript (2017)

#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 :)

Re: The melting pot of JavaScript (2017)

#62
post #24

Earlier quoted context omitted.

npx create-react-app my-ts-app --typescript takes about 30 seconds from command to running app. Maybe the issue people have is there is no 'js-lang.org' with one tutorial site and getting started. It's a huge community, so of course random blog posts will be a mixed bag of quality.

It takes about 30 seconds since last week 'till the end of the next month. If you read older tutorials, you won't figure it out. By March, current tutorials will probably be out of date. That's my issue (one of many) with the JS ecosystem. Things move so fast that just keeping up feels like a full-time job. I remember giving up on my first approach to React after I followed Swizec's tutorials and quickly hit into som…

This is why I refuse to use create-react-app. I can appreciate the convenience and have learned a few things from reading its source, but I need to understand the entire application I'm building from the ground up.

Re: The melting pot of JavaScript (2017)

#63
JavaScript was designed to be a glue language - to connect output of one native function with input of other native function. And do all of this in UI event handlers.

And it was almost perfect (modulo hoisting, semicolon omission) for that.

The trouble has started when Web, as a platform, has failed to provide safe alternative to JS aimed for extendable way of delivering and running high-performant code on the client.

Ideally we should have something like with something close to JavaVM and HTML DOM exposed to it. At least 15 years ago. So we would have a lot of compilers, static compilation and code analysis.

Instead we have tons of weirdest possible solutions: Web "threads" with code that need to be downloaded and compiled before running, that ugly WebAsm, transpilers-of-something-into-JS. C++ code "transpiled" into JS, in whose nightmare that bright idea was born?

Yet we have crowds of talented people wasting time of writing about how to really HACK the platform that was not meant to be used this way.

Create bunch of problems to ourselves just to overcome them heroically. Far from being productive.

Re: The melting pot of JavaScript (2017)

#64

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…

> Java, C#, Rails, and to some extent Python are much saner choices. Python not as scalable, Rails is stagnating, the ecosystem doesn't evolve anymore/dying, doesn't play well with SPAs, C# weak to none ecosystem outside of Windows and devs earn a fraction, Java verbose and dev productivity subpar (there was a reason people came up with Scala), Java devs also suffer lower salaries

> Python not as scalable

Not scalable in what way? Every aspect of scalable that I can think of is in no way limited by choosing python as your language.

Re: The melting pot of JavaScript (2017)

#65

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…

> Java, C#, Rails, and to some extent Python are much saner choices. Python not as scalable, Rails is stagnating, the ecosystem doesn't evolve anymore/dying, doesn't play well with SPAs, C# weak to none ecosystem outside of Windows and devs earn a fraction, Java verbose and dev productivity subpar (there was a reason people came up with Scala), Java devs also suffer lower salaries

"Rails... ...doesn't play well with SPAs"

Huh? Rails ships with built-in, no-config webpack support (https://github.com/rails/webpacker#installation) as well as install tasks for the most-popular front-end solutions (https://github.com/rails/webpacker#integrations)

Re: The melting pot of JavaScript (2017)

#66
post #63

JavaScript was designed to be a glue language - to connect output of one native function with input of other native function. And do all of this in UI event handlers. And it was almost perfect (modulo hoisting, semicolon omission) for that. The trouble has started when Web, as a platform, has failed to provide safe alternative to JS aimed for extendable way of delivering and running high-performant code on the client…

> something close to JavaVM and HTML DOM exposed to it

> ugly WebAsm

WASM isn't fully functional as a standalone alternative to JS in the browser, yet, but you can essentially use it that way with things like wasm-bindgen in the Rust ecosystem. And it performs essentially what you're describing, being a VM running bytecode in a sandbox.

Re: The melting pot of JavaScript (2017)

#67

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, these will become obsolete too.

Re: The melting pot of JavaScript (2017)

#68
post #47

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…

> Can you explain what Java offers with regard to reflection that JS doesn't? Among hundreds of other things, getting the return type of a method and getting the input parameter names (+ types) in a way that doesn't revolve around literally parsing the functions toString() representation. Oh, and typeof checking that isn't disgustingly broken.

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

Re: The melting pot of JavaScript (2017)

#69

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…

Just to be clear, Reflect exists to be direct interface to JS's Module Object Protocol (MOP). Every "primitive" operation you can perform on an object in js, (such as adding a property or getting the value of a property), is exposed via Reflect.

Re: The melting pot of JavaScript (2017)

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