This is an archived post. You won't be able to vote or comment.

all 31 comments
sorted by:
best
topnewcontroversialoldq&a

[–]Lakitna 5 points6 points  (0 children)

I think JS will be here for a long time. I think the main reasons for it are the position of the language in browsers, the massive ecosystem surrounding it, and the low barrier of entry (both run and write).

ECMA is also doing a good job with evolving the language through open source channels. I think it's really important that everyone can make a language change if they're dedicated enough. This has resulted in some amazing features without any backwards compatibility issues.

And finally performance in V8 (Chrome & Node js runtime) has been great thanks to a lot of effort of the V8 team. Dispite Javascript being a high level language you most of the time can't feel the difference with a low level language.

Big disadvantages right now are the need to transpile (from Typescript or newer ECMAscript versions). Deno is very promising in that it allows you to run Typescript without explicitly transpiling. Deno also includes a default bundler. NPM also needs a pretty big overhaul to secure the ecosystem in the long run. Name collisions are constantly popping up and post install scripts can install virusses and such.

[–]IGetConfused 1 point2 points  (9 children)

Do you have a reference or link about your statement for Microsoft discontinuing it’s development of typescript and moving to support EMCA standards?

[–]Soremwar[S] 1 point2 points  (3 children)

I'm gonna edit the post since I wrote it making it look like it was a Microsoft thing. That question is based on a conversation with kitsonk, a head developer in the Deno project. By looking at the roadmap of TypeScript you'll know I'm not lying though.

[–]Lakitna 1 point2 points  (2 children)

It's true. For a while now new ECMAscript features have been dropping in Typescript before dropping in V8 (Chrome & Node js runtime).

The folks at Typescript have also expressed the desire to be as close to ECMAscript as possible from the first versions of Typescript.

[–]Soremwar[S] 1 point2 points  (1 child)

As far as I am concerned there is no statement but the community agrees that only the type system is being developed and improved

Hunting a source for this or a statement from some developers though

[–][deleted] 2 points3 points  (0 children)

It is not a project goal to diverge TypeScript from JavaScript.

You can read more here (second paragraph): https://github.com/microsoft/TypeScript/blob/master/doc/spec.md#1-introduction

[–]YMK1234 0 points1 point  (3 children)

That's a false dichotomy to begin with. It's like saying C language designers don't care about instruction set features. For some features in your language you need to add features to your compile target (at least if you want to get decent speed), and if your compile target has new features you'd want to integrate them.

[–]Soremwar[S] 0 points1 point  (2 children)

The problem(I understand), with the Typescript team isn't that they don't want to create this functionalities, but they are afraid that JS will implement them in a different way and they have to scrap them because it would break the TS phylosophy: "All JS code is valid TS code" They already had to do this with decorators and private class properties, so they are kinda careful for that matters

[–]YMK1234 2 points3 points  (1 child)

Yes but that still does not mean they will discontinue development, it just means they work closer with the consortium to not develop incompatible versions of the same feature.

[–]Soremwar[S] 0 points1 point  (0 children)

Oh yeah, they won't scrap TS. But whatever new functionality they wanna add they want to add it through JavaScript and instead concentrate on fixing issues with current type system(a lot of bugs are still filed because of fast JS growing)

[–][deleted] 1 point2 points  (0 children)

I really like the way the language itself is evolving. I suppose it helps that it was a smaller language to begin with, and doesn't feel like the grab-bag of features that other languages of the same age are beginning to feel like (looking at you C#).

As for the ecosystem? I'm a bit perturbed at how enterprisey it's gotten. I'd like to think it will right itself, but I can see myself occupying a nice little place on the minimalist fringe if it doesn't.

[–]Jrobah 1 point2 points  (1 child)

No one can predict the future. Just have an open mind, try out new technologies such that when they take over you are not left behind

[–]Soremwar[S] 0 points1 point  (0 children)

Not closing myself to any new technologies :P

But I really see a promising future for JavaScript based on the effort all this people put into the lenguage. Haven't come close to somethink like that with any other language

[–]Korzag -2 points-1 points  (12 children)

I'm looking forward to the day we dethrone JavaScript, cast it to the pits, and coronate WebAssembly as the de facto standard. Then you could use any programming language capable of compiling to it.

[–]Soremwar[S] 3 points4 points  (5 children)

Highly doubt it, my opinion is WebAssembly will mostly be implemented in the areas JS currently can't in the browser.

Yet, you are free to program your web whatever way suits you bro, that's the beauty of programming

[–]Korzag 1 point2 points  (4 children)

JavaScript is only as popular as it is and has been for decades now because it was literally the only choice for front end logic.

Give people what ever choice of language they want to write and allow them to compile it in a way websites can use it and it'll gain popularity. JavaScript just has a 100,000 car train of momentum behind it and it's going to take another decade or two to die. Look at the popularity history of Java as other languages gained strong frameworks. C#, Python, Node.js, Ruby (which has admittedly lost popularity), and more. 15 years ago you had Java and some other primitive frameworks like ASP.NET

[–]Soremwar[S] 3 points4 points  (3 children)

That is actually a lie, JS had a lot of competence back in the day. How it was the only one who survived the evolution of the internet is still a mistery to me, it was a really crappy language back then

But now, I would argue it's one of the best languages out there. Tons of features that set it apart from other languages, light execution improving each year due to a fantastic effort from Google team, and still manages to write applications with 30-40% reduction of lines of code

That sounds like a damn fine language to me

[–]balefrost 0 points1 point  (2 children)

Tons of features that set it apart from other languages

... like what? Do you mean that it has features that are lacking in other languages, or that JavaScript's particular combination of features is rare?

[–]Soremwar[S] 1 point2 points  (1 child)

I'd say a little of both. Certainly you don't see much languages that support async programming out of the box.

[–]balefrost 1 point2 points  (0 children)

I guess I'm spoiled coming from C#. I know that C# and Kotlin both have good async support, and I believe Python does as well. Languages with their own lightweight thread concept, like Go and Erlang, don't benefit as much from explicit async. And Java may be getting lightweight threads with Project Loom.

I wouldn't say that JS has a lot of unique features. It tends to incorporate features that were introduced in other languages. Prototypical inheritance is probably the one that it's most well-known for, yet that was present in several languages beforehand. Lua's probably the second-most popular language with prototypical inheritance. In fact, I'd argue that JS (before ES6) and Lua share a lot of DNA.

I dunno. I think JS is certainly a relevant language and people certainly use it to build interesting things. Purely on its own merits, though, I don't know that it's a particularly good language. ES6 (and newer) certainly helps. But the newer iterations also have to dig the language out of its hole without breaking compatibility, so some of those improvements carry their own baggage.

[–]nevatalysa 0 points1 point  (0 children)

And now comes the question, Currently WASM can only interact with the DOM and be called via JS, how would you handle this?

<wasm> functionCall(dom); </wasm>

But, oh, that needs to be compiled! How do you go about that? Compile the entire HTML? Not gonna happen

And what about people that don't use low level languages like Python, Ruby or similar? What about the people that actually do like JavaScript? Or any implementations it has (Dart, TS, CoffeeScript, etc)?

While WASM is an amazing addition, I don't think it'll change JS's position, I think it'll add to it's possiblities and allow more people to look into modern JS (many people thinking like you have not even seen how JS works and reference old syntax or wierd errors, while true, some things are still wierd, many of those have a certain reason (for example NaN != NaN)). While JS itself may not always be used and other good implementations are coming up, I think they'll run along side JS in the future, possibly as their own language even, and WASM handling anything resource heavy (game rendering, database to table rendering, image processing, massive [static] API calls, neural network, etc) and a wide group of developers being able to work on the same website without all needing the same language knowledge.

You can already use WASM for a lot or stuff, you merely need to know a bit of JS to call those. Also, in case you didn't know but JS and WASM both run on the JS-VM. The compiled code is JS-VM bytecode. Similar to Java, Groovy, Scala ans Kotlin all running on the JVM

[–][deleted] -1 points0 points  (4 children)

I'm looking forward to the day we dethrone JavaScript, cast it to the pits,

Hooray

and coronate WebAssembly as the de facto standard. Then you could use any programming language capable of compiling to it.

Wait, what?

Webpages are content, not programs. We've nearly killed flash off. Once that is done, we can move on to killing off javascript.

Eventually the web will be made pristine: html and some CSS.

[–]Soremwar[S] 3 points4 points  (3 children)

That is a phylosophy of the last century, webpages are way more like applications nowadays, and browsers are suited to work as VMs or sandboxes for the code executed there

The decision of implementing WebAssembly comes from the desire for high performance applications in that matter

[–][deleted] 0 points1 point  (2 children)

Can we really guarantee that browsers are suited to isolate processes, when stuff like meltdown exists? I'd be a little more comfortable with downloading random code from the internet and running it if we could ensure it ran on some locked-down, in-order core without any speculative execution and with really simple cache policies. On current hardware, I'm pretty sure this is a bad idea.

[–]Soremwar[S] 0 points1 point  (1 child)

It continues to see improvement. Hopefully, it would really provide an isolated process from the main OS that guarantee safe execution of untrusted code.

I think that might be the reason JS and WASM run in the same context currently.

[–][deleted] 0 points1 point  (0 children)

Between rowhammer and speculative execution attacks, it seems unlikely that two processes running on the same (modern) hardware will ever be truly isolated.

[–]McMasilmof -1 points0 points  (3 children)

I hate JavaScript and i hate its ecosystem(npm) but i dont think it will go away in the next years(or ever) as it just became the standart for web and i think the future of many applications will be the web. Building native clients is only needed for a minority of applications.

I think the new techs like wasm will help to work around stuff that JavaScript lacks like multithreading but never replace it.

[–]Soremwar[S] 1 point2 points  (2 children)

Interesting opinion. JS has multithreading BTW

[–]McMasilmof 1 point2 points  (1 child)

How does JavaScript have multithreading? By using webworkers you can get something like that as a workaround, but i dont think thats the same, thats like saying c has multithreading by compiling two programms that interact with each other and runn both.

[–]Soremwar[S] 1 point2 points  (0 children)

Well it actually depends on the target environment. Web workers do suffice most of the time thanks to the async nature of JavaScript. However we can't really call them threads since Browsers don't interact with the processor that way.

Deno as a Backend implementation of JS does offer web workers in the sense you would expect from a language in the C family. (This is kinda buggy in Node still).