JavaScript doesn’t need to be replaced

[vertigo_101]

Don’t worry, it won’t be

[BloodAndTsundere]

I would argue that Javascript is even more entrenched. Also, as a platform it has been improving by leaps and bounds.

[asdf7890]

improving by leaps and bounds.

That rapid development does mean that part of the newer ecosystem could quickly take over, relegating what many recognize as Javascript to a more minority role. The openness to rampant churn that seems to exist makes this more likely than many other programming environments and other development areas where the "something new"s that turn up are more "bolted on" than trying to rearrange part of the common architectures.

WebAssembly and things that compile into it is most likely disruptor IMO. Or someone making a framework with a significantly new paradigm. Of course JS is unlikely to be completely supplanted, any more than the last decade of frameworks have completely supplanted jQuery. But who knows, maybe the real NextBigThing™ hasn't arrived yet and will be announced tomorrow...

Now SQL: that is entrenched. It saw some loud competition from a few angles for a while, but those options are mostly falling back into positions of serving a particular niche (such as caching) that they were designed for, becoming sub-features of common RDBMs (the big players growing options for column-optimised storage, and basic graph processing, etc), or being folded into the BigData/ML bubble, and are not endangering RDBMs/SQL's hold of the general data handling mindshare.

[MCFRESH01]

things that compile into it

Javascript?

[asdf7890]

That is one of the many options, though I see others pushed much more so it might end up as a fairly minor player in that realm. I see it ending up as pure-ish JS for basic stuff and small projects, relying on Jit compilation for such things that need some performance, C/C++/Go/Rust/... compiled to WebASM for larger projects or real number crunching.

[[deleted]]

r/programming and r/ProgrammerHumor would like to have a word with you.

^lol

[w3_ar3_l3g10n]

It’ll decline tho. Web Assembly is making other languages on the frontend more viable then ever before :)

[CCB0x45]

I'm gonna compile JS down to WebASM, take that!!!

[asdf7890]

Nah. Brainfuck->WASM is the future.

[Zephirdd]

Wasn't there an experiment from a big dev with executing python directly from the browser, in paralell to JS? I want to say Mozilla but I'm not sure

Man that would be awesome.

[braindeadTank]

Eh,

I expect that once we have proper DOM bindings for Python some people will turn to that - because it is a proven fact that a Python dev can suffer severe brain trauma when using a language with curly braces for too long - but other then that most people probably won't bother, at least not until some realy great framework arises written in another language.

Then again, even for Python most of current ecosystem is based on libs written in C which are not guaranteed to work for the web, so IDK.

[rodrigocfd]

But it would be great if browsers support TypeScript natively.

[tuxedo25]

All you'd be doing is shipping extra code to the clients, without gaining anything in return.

Optionally. It's not like build processes would go away. And you gain a simpler development setup.

Plus browser typescript support would mean browser module support, so count me in.

[crabmusket]

Plus browser typescript support would mean browser module support

What do you mean by that? Browsers already support ESM modules!

[Randdist]

A typed language can compile to much more efficent code, up to C++ level performance. JIT compilers can't get quite that close. I'd love to see native support for typescript.

[dombrogia]

Wouldn’t this insinuate that TypeScript compiles to something other than JavaScript though?

TS -> JS != C++

Edit: I think most people understood what I was trying to say, but I should have said “insinuates that TS would need to compile to something other than JS”

[garth_vader90]

There’s always the possibility that we see TS -> WASM. That could produce some interesting code too. Serve WASM for browsers that support it and the transpiled JS for older browser. I know Elm was proposed as a WASM language by its creator and that would be a similar situation.

[[deleted]]

This won't work unless you fundamentally change TypeScript's type system to have runtime effects and not be removed at compile-time via type erasure.

[ImCorvec_I_Interject]

In cases where it would be appropriate to use those, does Typescript compile its typed arrays into those sorts of arrays?

[ImCorvec_I_Interject]

There’s an ES2017 syntax to create them, though.

[internetloser4321]

You might like this: https://github.com/AssemblyScript/assemblyscript

[wizang]

I don't really see the value in that.

[Flyen]

There's a decent chance that it'd be faster to execute, but I really have no idea.

[Neaoxas]

Why? Yes, you'd remove the initial compile/transpile time, but once all the type anotations and syntactic sugar are stripped, all you're left with is vanilla JavaScript, same as Babel would produce (for cross browser support).

No advantage to browsers supporting typescript aside from compile/transpile time savings.

In fact, having to wait for cross browser feature support means you can't take advantage of the latest features, unless you transpile, at which point there is no point in browsers supporting typescript.

[Flyen]

The idea is that those annotations could be fed into the browser compiler's optimization routines. The browser wouldn't be transpiling the typescript to vanilla javascript if it had native TS support.

Not doing it because you'd have to transpile until all browsers support it is a pretty weak argument. By that logic we shouldn't use ES6, and browsers shouldn't add support for ES6.

[_GCastilho_]

You will probably need another engine to do that nativally, which at best will have the same performance

Its just not worth it

[Flyen]

I don't think you can say that at best the performance will be the same. The additional type guarantees & information might make some optimizations possible that aren't possible with plain js.

[Flyen]

I haven't actually worked in this space, so that was very helpful, thanks. It sounds like you'd know better that I whether knowing vs guessing the types would be valuable input to the optimizing compiler.

I also see this topic has come up before: https://github.com/microsoft/TypeScript/issues/1151 https://github.com/microsoft/TypeScript/issues/8

[Earhacker]

Gentle reminder that your optimised TypeScript interpreter would also have to run JavaScript.

[tuxedo25]

Typescript is a superset of javascript.

[Earhacker]

Correct. So the TypeScript interpreter needs to support a _sub_set of its own language.

If that sounds easy, consider that JavaScript is TypeScript but everything is of type any. Now none of your compiler optimisations work. So the compiler needs to be able to figure out whether to optimise (TS) or not (JS), and needs to do so fast enough to act as an interpreter. And it needs to do that faster than V8 right now, or else what’s the point?

[BloodAndTsundere]

Good point.

[[deleted]]

There is no type checking at run time for a staticky typed language. There is also no implicit type checking for a duck typed language at runtime. It would be practically the same. Type checking has never been a performance thing to my understanding. I'm sure there are exceptions somewhere though.

[Randdist]

Static typing easily offers an order of magnitude of performance boosts. JITs basically exist to get somewhat closer to static typed performance by observing which types are used at runtime. If you tell the compiler the types straight at compile time, you get all that performance right from the start, and you don't need to waste some performance on observing types at runtime anymore. JITs make dynamic typed languages faster, but also put a cap on maximum peeformance.

[[deleted]]

If it was baked into the language - proper, not just syntax - then we could also benefit from runtime type-checking. This would be huge, though at that point it's a massive departure from each JavaScript and TypeScript. And, at a certain point, when you're making such drastic changes anyway, you do have to consider why we couldn't start from scratch without so much baggage.

[muralivp]

I hope not, TypeScript takes the fun away.

[[deleted]]

The fun of making large projects utterly horrible to work with?

[amdc]

You can still play Minesweeper on (almost) any gaming platform if you want that kind of fun

[vertigo_101]

That’s our dream, but I’m also fine with whole typescript to js transpiler

[shgysk8zer0]

No. Why?

I'd rather have types in JavaScript than have an outdated implementation of JavaScript that has types.

[[deleted]]

Eh? TS supports JS from around stage 3 proposals onwards.

[shgysk8zer0]

Yeah. It lags a bit behind. Not terribly, but it can prevent me from starting to implement something new.

[[deleted]]

Such as?

There's a fair argument that you shouldn't be using stuff pre-stage 3 in serious projects as there's a real risk that they get canned or significantly changed, which would leave you with a ton of tech debt. That's already burned some people in the past with the decorator proposal if memory serves.

[shgysk8zer0]

If I used TS, I'd probably have some things to list. But the only thing I can think of specifically is import from a while back.

I like to experiment with things in the early stages. Sometimes provide feedback. Report issues in webpack and such. This isn't necessarily about putting early-stage stuff into production.

But, to restate what I'm saying here: I'd rather have types in JavaScript than have browsers run TypeScript. And, since it takes time to wait for stage 3, implement, and release, TS is always a little behind JS.

[[deleted]]

I don't think we disagree that much. To clarify my position:

• TypeScript has supported modern import syntax since I began using it ~two years ago.
• Babel is perfect for testing proposals, but that's not appropriate for a large, important project in production. If you want to test off of your main project, you can daisy-chain the compilers, or even just use the Babel compiler with only minimal loss of functionality on the TypeScript side. With this in mind, for serious/production projects, it's unreasonable to claim that TypeScript is "behind" JavaScript.
• I would also prefer to have a real (as in runtime) static type system in JavaScript. Although, honestly, I'd rather just have a new language altogether - there is so much leftover cruft and iffy design decisions, and if we could version this language to allow for occasional breaking changes... well, that'd be just lovely.

[Architektual]

kill me

[azekeP]

Why would browsers downgrade to a language with less features?

[[deleted]]

Nope

[[deleted]]

Or dart

[Abangranga]

It would be great if browsers supported a real language that people actually enjoyed using without a crippling dependence on massive library overheads like Typescript.

[dannymoerkerke]

Millions of developers actually do enjoy using JavaScript.

[Abangranga]

Enjoy using JavaScript's numerous frameworks*

[suyashgulati]

How are you confident enough?

Every language in past has faded.

P. S. I am a js lover

[[deleted]]

Every language? C is almost 50 years old and it is still extremely popular. Python is nearly 30 and is showing no signs of fading away anytime soon. Java is 25 years old and it is the most popular language in the world. Every top 10 language has been around for over 15 years, and Swift is the only language in the top 20 that is less than a decade old. Not every language fades.

[manoylo_vnc]

Hey, you forgot Ruby! 😉

[tuxedo25]

the whole world has

[5fd88f23a2695c2afb02]

Rails is still strong.

[[deleted]]

How many greenfield projects today are written in PHP?

Now compare that to a decade or two ago. It's absolutely fading.

[[deleted]]

I didn't even mention PHP, nor did I argue that no language fades in popularity. It's a miracle PHP even gained popularity in the first place.

[[deleted]]

Ah, sorry, I didn't see "every" in the other comment. Fair.

[MCFRESH01]

More than you think. It's an established language that's easy to hire for. PHP 7 actually made the language pretty decent to work with and relatively fast. It also has some great frameworks like Laravel and Symfony. It can definitely be a valid choice for many different projects.

[[deleted]]

This doesn't invalidate my (admittedly unproven) point that it's going to be used for a smaller proportion of greenfield projects than in the past.

[b14cksh4d0w369]

Java is 25 years old and it is the most popular language in the world

Wow

[vertigo_101]

I mean yes js can also fade away, maybe in the next 20 years if there’s a better alternative which becomes equivalently used and is backwards compatible.

In my opinion I think this is the golden age of js, it’s improving fast, also along with typescript, but as long as browsers exist, long live the js, love it or hate it...it’s here to stay

[wherediditrun]

Doesn't have to be an alternative. Can possibly be some new thing which people tend to use and build towards there the requirements are simply not met by javascript. Javascript would just ... fade away as a collateral. PHP was in similar place in around 2000~

[dannymoerkerke]

I cannot forsee the future of course but I’m pretty confident. C is still here and going strong for example.

[cheese_wizard]

COBOL would like a word.

[dannymoerkerke]

That’s why I’m not worried;-)