Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Just Say No to JavaScript

infoworld.com

Post reply on HN
Print view View original

21–30 of 86 posts

Re: Just Say No to JavaScript

#21

Post by sureIy »

archerx wrote: post #11
iLoveOncall wrote: post #5

Earlier quoted context omitted.

> it's because it needs a compilation step, and I don't want that Why? The seconds it takes to compile even a large project are paid back a million fold everytime it catches a mistake you'd have missed or your IDE out you used the wrong type. It's probably not listed in the article because it's a nonsensical argument.

>catches a mistake you'd have missed or your IDE out you used the wrong type. Do people really have this issue? My errors are never type related and when they are the console tells me immediately and the exactly line to fix. What I need is a StupidScript to save me from the stupidity of my logic errors… Like for example I’m working on a custom game engine for a web game I’m making, I’m having issues with the rewards…

> the console tells me immediately and the exactly line to fix.

Uh, yeah, that's a runtime error. Type safety tells you the error before you even hit save, let alone run and test. It's a wildly faster loop.

Re: Just Say No to JavaScript

#22

Post by jasode »

glutamate wrote: post #6

The author never actually says what is so wrong with JavaScript. I think it is quite a good dynamically typed language, and it certainly has some very high-performance implementations. If you don't like it, just use something else? > Ultimately, JavaScript was the right thing at the right time. It ended up being folded, spindled, and mutilated to serve purposes that it isn’t well suited for Counterpoint: many quirks…

>The author never actually says what is so wrong with JavaScript.

The author does but you have to extract it yourself by using some mental subtraction from the sentences he did write:

>[...], TypeScript has all of the benefits of JavaScript (such as they are) while _adding_ a type system that is expressive and powerful. [...] TypeScript leverages the ubiquity of JavaScript while _adding_ all the power of a modern typing system. And that is why you should be using TypeScript instead.

Translation... subtract out the "added modern type system" from Typescript... to reveal his Javascript criticism: "Javascript does not have a modern type system to help catch errors."

Re: Just Say No to JavaScript

#23

Post by DecoySalamander »

This kind of rant, culminating in a hackneyed "created in a week" insult, usually comes from backend developers who jumped into frontend work thinking it was a silly little thing that could be mastered in under an hour, discovered that it was a whole separate field, and still failed to adjust their priors.

This time it comes from a "former Delphi product manager" turned clickbait writer. I just hope that my visit with adblock enabled didn't generate any form of income for him or his website.

Re: Just Say No to JavaScript

#24

Post by akira2501 »

jraph wrote: post #16
glutamate wrote: post #6

The author never actually says what is so wrong with JavaScript. I think it is quite a good dynamically typed language, and it certainly has some very high-performance implementations. If you don't like it, just use something else? > Ultimately, JavaScript was the right thing at the right time. It ended up being folded, spindled, and mutilated to serve purposes that it isn’t well suited for Counterpoint: many quirks…

> The author never actually says what is so wrong with JavaScript The lack of explicit typing. The author argues against untyped code, and for using typescript instead of javascript to get types.

> The lack of explicit typing.

The JIT seems to figure it out just fine. Otherwise typeless programming is just a particular style and it's not particularly complicated just different. I've never understood this rationale in a language that does not have pointers.

Re: Just Say No to JavaScript

#25

Post by sureIy »

tobyhinloopen wrote: post #20

I was disappointed to read this is just a "Use TypeScript" instead. Look, you can hot glue and tape all the types you want, but it is still JavaScript. No amount of compiler-enforced comments is changing that.

> it is still JavaScript

Yes, it's still one of the most performant languages around, so that's a good thing right?

Re: Just Say No to JavaScript

#26

Post by akira2501 »

medo-bear wrote: post #13
archerx wrote: post #11

Earlier quoted context omitted.

>catches a mistake you'd have missed or your IDE out you used the wrong type. Do people really have this issue? My errors are never type related and when they are the console tells me immediately and the exactly line to fix. What I need is a StupidScript to save me from the stupidity of my logic errors… Like for example I’m working on a custom game engine for a web game I’m making, I’m having issues with the rewards…

At that point sir you would have no job. Your job is logic safety

My job is to produce more value than I cost. Otherwise you're going to get laid off anyways.

Re: Just Say No to JavaScript

#27

Post by akira2501 »

nottorp wrote: post #18

Translation: type less languages get messy when the project size grows. This is not only about javascript, it's also about python and whatever else is in fashion. Still, the title is disappointing because switching to a type checked dialect of JS won't fix the bloat issues that are fundamental to the browser as a platform.

Any system can get messy when the project size grows. Defect rates seem to be correlated with the addition of new features. Stable projects only including bug fixes with good test coverage become more stable over time. This is all regardless of language.

There may be a case that typed languages ship with fewer initial defects in new features but I'm not entirely convinced it's always competitive with the return in development speed and simplified testing you can get staying untyped. Particularly when your underlying problem is not CPU bound.

Re: Just Say No to JavaScript

#28

Post by jeroenhd »

glutamate wrote: post #7
qayxc wrote: post #4

The author seems to ignore the fact that type hints are a thing even with plain JS. Serious question: does the author "just say no to Python" as well? If lack of explicit typing is the issue, then his rant would apply to most scripting languages and to single out JS seems odd to me...

> type hints are a thing even with plain JS Can you clarify how you do this? the type annotation TC39 is not approved; but I'm interested in hearing if you have a "userland" approach that works for you?

I've seen several ways of annotating Javascript that IDEs seem to understand. They usually involve using comments before fields, classes, or functions.

The most compliant one seems to be using [JSDoc](https://jsdoc.app/). JSDoc is mostly intended for generating documentation. However, the Typescript compiler can validate types (and can even interoperate with Typescript definitions), if you configure it as such.

In scenarios where you HAVE to write raw Javascript but still would like to do some type validation, this is probably the best solution.

It looks a bit like this:

    /**
     * Fiddle the widget
     * @param {WidgetThing} The widget to fiddle
     */
    function fiddleWidget(widget) {
This is a type hint that asserts that `widget` is of type `WidgetThing`.

JSDoc also works in the middle of a method:

    /** @type {Foo} */
    const foo = widget.fetchFoo();
This asserts that `foo` is of type `Foo`. This could in theory also be derived from the return value of `widget.fetchFoo()` of course.

JSDoc also has arbitrary type definitions:

    /**
     * @typedef Foo
     * @type {object}
     * @property {WidgetThing} parent - the parent that created this Foo.
     * @property {string} name - the name of this Foo.
     */
I would stick to transpiling Typescript myself, but I've also seen use cases where that's simply not an option.

Re: Just Say No to JavaScript

#29

Post by hmmokidk »

DecoySalamander wrote: post #23

This kind of rant, culminating in a hackneyed "created in a week" insult, usually comes from backend developers who jumped into frontend work thinking it was a silly little thing that could be mastered in under an hour, discovered that it was a whole separate field, and still failed to adjust their priors. This time it comes from a "former Delphi product manager" turned clickbait writer. I just hope that my visit wit…

I love JS. Well, that's not true. I love it, and then I hate it, and then I love it again. And I am not sure how to respond.

It has warts. I have seen a staggering amount of flavors / styles of JS.

It is a really expressive language. But that is kind of a cope. You will figure out how to express your wildest ideas. But you will struggle to read others code.

Multithreading is...weird to say the least. Are people spinning up a server per core? Using PM2? Have they discovered the world of testing...without mocks.

If we don't criticize JS it will never get better. So writing off the criticism of the especially hateful BE dev stereotype isn't doing anyone any good. Take it in stride. Nobodies feelings need to be hurt.

Many languages evolve into other languages. JS does not really have that luxury, and I don't know of any langs that preceded it that were similar (my own ignorance).

It is amazing for what it is.

But...if we could start over with what we have learned over the years many things would certainly be very different.

Re: Just Say No to JavaScript

#30

Post by iLoveOncall »

archerx wrote: post #11
iLoveOncall wrote: post #5

Earlier quoted context omitted.

> it's because it needs a compilation step, and I don't want that Why? The seconds it takes to compile even a large project are paid back a million fold everytime it catches a mistake you'd have missed or your IDE out you used the wrong type. It's probably not listed in the article because it's a nonsensical argument.

>catches a mistake you'd have missed or your IDE out you used the wrong type. Do people really have this issue? My errors are never type related and when they are the console tells me immediately and the exactly line to fix. What I need is a StupidScript to save me from the stupidity of my logic errors… Like for example I’m working on a custom game engine for a web game I’m making, I’m having issues with the rewards…

> Do people really have this issue?

Yes. The point is that without type-safety and a compile-time type check, you have absolutely no way of knowing if you have an error like this until you hit that piece of code.

The very fact that you think you don't have those kinds of issues just exemplifies how you actually are just ignorant to all the type errors you have in your code because you haven't tested enough, hit the right edge case, etc.

Post reply on HN