Live data from Hacker News

The melting pot of JavaScript (2017)

increment.com

161–170 of 200 posts

Re: The melting pot of JavaScript (2017)

#161

Let's say you'd like to write front-end code in a language that hides as much of the problems with JS as possible, preferably one that comes with a standard library, has elegant (or at least ergonomic) JS to interop and bridging, simplifies async code, and has a simple, integrated toolchain for targeting JS (all these amongst other things), what would you suggest? Basically what's the best language to write Javascrip…

ReasonML

Re: The melting pot of JavaScript (2017)

#162

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

Re: The melting pot of JavaScript (2017)

#163

Earlier quoted context omitted.

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.

It is super easy to pick up, you can understand the whole concept quite quickly. Follow one the tutorial and you will be ready to deploy new apps in days. One of my fav free tutorial: https://www.yoember.com

yep, without www: https://yoember.com

Re: The melting pot of JavaScript (2017)

#164
post #130

Earlier quoted context omitted.

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

Linting is about so much more than code style and standards. Since we use auto format I have almost all the style checks off. What it does catch is hundreds of different types of potential bugs. Uninitialized variable. Missing null check. Deprecated or beta marked api used. Improper thread synchronization and double locking. Reassignment of parameters. Conditional check that's always true/false. This list is huge, an…

[deleted]

Re: The melting pot of JavaScript (2017)

#165
post #161

Let's say you'd like to write front-end code in a language that hides as much of the problems with JS as possible, preferably one that comes with a standard library, has elegant (or at least ergonomic) JS to interop and bridging, simplifies async code, and has a simple, integrated toolchain for targeting JS (all these amongst other things), what would you suggest? Basically what's the best language to write Javascrip…

ReasonML

Oh I forgot about Reason. Does it have a standard library that obviates the need for pulling in things like lodash, etc?

Re: The melting pot of JavaScript (2017)

#166
Unpopular opinion time: I understand why people prefer TypeScript/CoffeeScript but for me personally it just destroys the incentive of a scripting language and I am a fan of keeping deployment as simple as possible and to me transpiling is equivalent to compiling. Packaging is bad as it is.

True, maybe everything is different in large scale applications but I hate it if I find something interesting implemented in TypeScript and in 95% of cases I will just move on.

Javascript is not a beauty and any superset just seems like a facelift. The result looks like old and used car tires.

disclaimer: I am no web dev but somehow come in contact with JS frequently.

Re: The melting pot of JavaScript (2017)

#167
post #160
post #67

Earlier quoted context omitted.

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 vanilla JavaScript. With vanilla JavaScript you do not need any build tools. Instead of buying many different kitchen cutting and slicing tools - learn to use a knife.

I am quite decent at vanilla javascript, but building a website in vanilla javascript is like building a REST API in vanilla C. It's possible but will take a long time.

Re: The melting pot of JavaScript (2017)

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

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

Re: The melting pot of JavaScript (2017)

#169

Earlier quoted context omitted.

> I can think of Mayne that is your problem. Try new stuff. V8 is still one of the fastest and most optimized VMs.

That has absolutely no relationship to backend scalability whatsoever.

Docker/k8s

Re: The melting pot of JavaScript (2017)

#170

Earlier quoted context omitted.

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

Rails is so 2010 and SPA stuff is half-baken.
Post reply on HN