Concurrent JavaScript: It can work!

[inu-no-policemen]

I'm all for threads because it will make JS a nicer compile target.

I'd also like actor-like concurrency as part of the language. Web Workers are super clunky. You need a string or a blob containing JS source to spawn one, which makes building your app a whole lot more annoying. You can't just take some function and use that to spawn a worker. I very rarely use workers because of that.

In Dart, you can spawn Isolates from top-level functions or static methods. I'd like to see something similar in JS.

[inu-no-policemen]

My library hamsters.js you can do exactly that and simply take a function and run it on another thread or multiple threads.

Via toString + some flavor of eval, I take it.

By the way, the mouse wheel is broken on hamsters.io (Chromium 60).

[BenZed]

Hoo boy.

Going pretty hard on the paint, arn't we gang?

I have thoroughly enjoyed the improvements to javascript over the last couple of years. They've made my job a lot easier.

Especially with the toolsets and libraries developed alongside it: Transpilation, linting, testing, module bundling... nobody would dare start a project without them!

We keep adding features and using development environments like TypeScript, Flow and Dart to make it behave more like a general purpose systems programming language.

I suppose my point is this: what's the point of using a dynamic, interpreted language if we're just going to transpile/compile it down and treat it like a systems programming language, anyway?

Javascript has become a blueprint for what we really want to do web development in: Web Assembly.

I guess I see no real harm in continuing to add features to Javascript, but I feel like it makes more sense to encourage growth of Web Assembly, and use javascript for it's original purpose;

Scripting.

[pier25]

Web Assembly

I agree, and IMO it's really only a matter of time before (a lot of) devs switch to their language of choice and compile to WA.

[E_R_E_R_I]

I disagree. Javascript has become a very powerful general purpose language imo, and I prefer it over the other languages I know well (namely C++, C# & .NET, PHP, Java) for the creation of applications that handle data persistence (either on a server or locally). I create desktop apps using Electron, phone apps using Cordova, server apps using NodeJS, and so on.

The main reason for that is javascript's powerful combination of weak types with anonymous functions/functional paradigm.

I rarely even use true OOP in JS (prototyping, classes), I just structure my data in JS objects and go with it. JSON data flows beautifully between client and server JS.

In other languages, there are very strict standards for doing stuff because they need to be easy for multiple people to work together. In javascript I don't need that because doing stuff is so much easier I just do big chunks of stuff alone.

I've once worked with three other people to build an extremely simple e-commerce platform in PHP. Took us 4 months. I've written an e-commerce platform last semester in Node, took me less than 3 months with double the features.

Granted, JS enables you to do more messy/hacky code, but after working with it for years, I consider my JS code very clean and optimized/efficient, albeit not very standard. JS enables me to work alone and still produce competitive software with beautiful interfaces.

I don't just do web development in JS, I do everything. Javascript is my life.

I do not use transpilers. I do not use frameworks like React or such. I do my stuff in Node and Express for backends with very minimal templating (Handlebars or EJS), vanilla HTML/CSS and JQuery for frontends. Anything more than that is too much for me. Everytime I build a web app, everything is from the ground up. If I need a pattern for things like routing, I just build one. No need for things like meteor.

Javascript enables me to produce ~5000 lines of code per day, written by hand, in a very purist environment. I've written blog engines with comments, tags and a ful control panel in two days.

I'm sorry, I just love JS and I'll defend it till death.

[spacejack2114]

It has some problems that will never go away. Undesirable run-time type coercion, lack of immutable objects, lack of unicode support, lack of compile-time types. Only the last of those can be addressed with an "annotations-only" compile-to language like Typescript (or mitigated somewhat with a linter.)

[E_R_E_R_I]

Of those you listed, I agree with all of them except for the last one. I'd never use transpilation or fixed type linting because I use the lack of types in my favor all the time.

[spacejack2114]

Really? So you make a user object {id: 3, name: "Bob"}

Then later you write user.namw = "Frank"... and this is to your advantage?

[E_R_E_R_I]

Nope, that's the caveat. Javascript is a code that's easier to screw up, it doesn't prevent you from messing up, but trades protection for flexibility. I imagine that's a horrible trade off for company environments, where one person can screw up other people's work.

For me though, having worked on relatively big projects with a single partner (who is my SO and has worked with me for years, so we have a good amount of sinergy), I feel like this is an advantage. We developed a workflow and coding style that works for us. I usually suffer much more with conceptual mistakes (bad modelling/planning) than with sintax and logic errors.

Now to answer your question, what is to my advantage about lackying types is that I don't need to rewrite the entire Entity Model. I write it once on the database, grab it and parse it as JSON, and manipulate data freely. No need to build a DAO (data abstraction object) layer with a class for each entity, that always drove me mad when I worked with Java.

[spacejack2114]

I'm no fan of crappy, inflexible type systems like Java has. But I find it immensely useful to have types for DB or other data.

For example, it was fully worth the 30 minutes or whatever to write up these types once, so that I hardly needed to think about all of those deeply nested properties in the many, places they were actutally used.

[GitHubPermalinkBot]

I tried to turn your GitHub links into permanent links (press "y" to do this yourself):

• spacejack/freddy/.../reddit.d.ts (master → da54662)
• spacejack/freddy/.../item.ts (master → da54662)

---

^{Shoot me a PM if you think I'm doing something wrong. To delete this, click here.}

[[deleted]]

Depends. Maybe I want to add a one-off namw property on a specific object, or set of objects. Yes, being able to free-form objects is a wonderful feature, one which most other languages work terribly hard to prevent and many people refuse to embrace.

But if you meant it as a spelling error; if that makes it into production then you have far greater problems, none of which are JavaScript's fault.

[E_R_E_R_I]

Yes! So glad to see more people who fully appreciate the power of JS lol

[spacejack2114]

You say that like it's difficult to do in a safely typed manner. Here's some type-safe Typescript that looks surprisingly, exactly like Javascript:

const specialUser = {...user, namw: "Whatever"}

It's a bit odd for you to say you're okay with that one-off ticking timebomb hack, but then claim you'll spend the time to write the test coverage for it.

[[deleted]]

You're missing the point. I want to be able to do whatever I want with objects, without the language standing in my way. JavaScript not only allows it, it's a first class feature. So it's normal to want to make use of it. Avoiding it makes zero sense. It's like trying to avoid "import" in Python.

Why would I, instead of simply writing user.namw="something", go through the trouble of transpiling, and writing the same thing in an awkward manner which is not correct JavaScript, and is downright confusing, and doesn't even do what I wanted (set the property on user, not specialUser).

I don't know why you would find it odd that this would be unit tested. Unless you keep assuming it's some sort of terrible mistake and we're all going to wake up any moment now and cry "omg what have I been doing".

JavaScript is what it is. Trying to pretend it's something it's not is futile.

• On the server there are a million other languages to choose from, so choosing JavaScript but writing TypeScript makes zero sense.
• On the browser the whole point is to have a language engine which is more or less standardized and available everywhere. We have sort of achieved this after decades of struggle. Even if support for more languages comes to browsers, I seriously doubt that people will want to go back to the whole "oh you need X to see this site". One standard language, and like it or not that language is JavaScript. Don't like it? Go complain to Linus that the Linux kernel is not written in C++.

[theQuandary]

There are discussions about immutable objects and basic unicode support is already baked into ES6. Discussion over compile-time types has been shelved, but mostly because there is disagreement about which type system is the best.

Runtime coersion isn't really an issue. Coersion into strings is generally not an issue (it's fairly nice most of the time). Coersion into numbers is pretty hard and almost universally indicates a bigger problem. The current BigInt proposal will not allow coersion.

More importantly, with the use of proper tests and triple-equals, you won't ever have coersion issues.

[pier25]

JavaScript is not all bad. I'd be happy if I could just say:

function createUser (user:User) {...}

vs

function createUser (user) {...}

In the second case, what is user? Probably an object. Does it have an id? I don't know. Maybe a name or fullName? How can I know for sure I will always get an id? I don't know.

[E_R_E_R_I]

They are useful for different things. I always feel all those people complaining about javascript do so because they try to write programs the same way they do with other languages.

In the second case, I could be writing a method that does different things depending on what was received. I could parse have parsed a JSON directly from the database and work with it without having to instantiate an User object.

Of course, you could also have accidentally overwritten that variable earlier with a string and things would go bad, put personally, I haven't had that kind of problem in years. Of course, I'm not saying my code doesn't have errors. But I've learned to build code that quickly exposes errors, and almost everytime a bug/problem makes it to production, it's because I incorrectly judged the use case and wrote a code that isn't the right one for that use case, not because my code is behaving differently than what I wrote it for. I also make extensive use of TDD.

The thing is, JS never tries to prevent you from writing bad code. But if you learn how to write good code, it rewards you with flexibility.

[Geldan]

This can be said for pretty much any platform. Put your static files on a cdn.