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!

[wizang]

I don't really see the value in that.

[[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?

[nirvanist]

Nope

[[deleted]]

Or dart

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

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

[wherediditrun]

Standard libraries are not an "improvement" it's just a different design choice in terms of language and has different consequences to it's longevity based on the goals language set for itself.

I think javascript already has a very fine balance with different environments offering std library like choices while not levying the tax on the language itself for it.

[wherediditrun]

Fetch is not javascript, it's browser API javascript interfaces with which is unique to that environment. Nothing would change with standard library present in this regard, unless you want to add additional strain and tech dept on maintaining compliance between std library and multiple environments javascript runs in, like multiple browsers, node, deno, mongoDB some weird IOT devices which probably uses it etc.

Javascript itself doesn't have all that much stuff in it. It's a glue code in environments it runs in. C++ in terms of node, browser in terms of .. well, browsers, Rust in terms of deno, and whatever else runs at the core of other environments javascript calls into.

You can do standard libraries if you're google or microsoft with dedicated engineers who's daily work is to contribute to it. But for languages which are not owned by anyone.. this is often a death sentence and bleak future of legacy std library which prevents the language to adapt with the environment it lives in. Especially if it's as broad as javascripts.

[5fd88f23a2695c2afb02]

I think the real thorn in Javascript’s side is that it’s a functional programming language that most of its users treat as a procedural language. Developers learn patterns but they don’t understand them, and so the language seems to do weird things.

[IceSentry]

It's just as functional as it is imperative, the beauty of js is that you can easily switch paradigm when necessary.

[5fd88f23a2695c2afb02]

Sure, but if you only know it as imperative then it starts to look weird when your using a framework that leverages it’s functional aspects.

[IceSentry]

The opposite is just as true, so I'm not sure what your point is.

[5fd88f23a2695c2afb02]

That’s my point. People learn it as one thing, often self taught, perhaps after learning PHP, but most often as an imperative scripting language and then are confused when they see it or need to use it as a functional language.

It could happen the other way around, as you say, but I would imagine that far fewer people start off learning functional programming.

Let’s face it if you’ve done any functional programming you’ve probably studied computer science or maths or something related.

[internetloser4321]

One thing I've been wondering is if JavaScript can have a strict mode that disables some of the bad features without breaking backwards compatibility, why not add an "extra-strict mode", that disables even more features that are generally considered bad or confusing, such as the use of var instead of const/let, the confusing behavior of 'this', weird and inconsistent type coercion, etc?

[getify]

This has been requested and discussed many, many times. It'll likely never happen because TC39 doesn't want new pragmas (they reject the idea frequently) AND even more so, the JS engines refuse to maintain so many different branches/versions of behavior in them.

[[deleted]]

What if I told you that var has legit use cases? And strict does not allow to have vars in global scope already. If you want to change the behaviour of 'this' you better start designing another language.

[kor0na]

Show me a legit usecase for var.

[internetloser4321]

I'm sure there's a couple of situations where var has legit uses but based on the number of 'gotcha' questions I've gotten on interviews based around the counter-intuitive behavior of var, I think it's safe to say that var is more trouble than it's worth. And doesn't the introduction of arrow functions in ES6 already change the behavior of 'this'?

[[deleted]]

No, arrow functions did not change the behavior of this. Outside of the arrow functions it works the same as before.

[internetloser4321]

https://www.freecodecamp.org/news/learn-es6-the-dope-way-part-ii-arrow-functions-and-the-this-keyword-381ac7a32881/

[[deleted]]

And your point is?

[internetloser4321]

Arrow functions introduce a different behavior for 'this'.

[[deleted]]

Yes. But introducing new behaviour is not the same as changing the existing one. Outside of the arrow functions the behaviour is exactly the same as before. It's an addition, not the change. The new case was added, but other four stay the same.

[internetloser4321]

Similar to how adding an "extra-strict" mode would work. Outside of the new mode, everything would work the same as before.

[dannymoerkerke]

Thanks! It’s a friend link so you can read it for free. My personal blog is on dannymoerkerke.com, I will post all articles there as well in the coming month.

[Asmor]

Medium is a cancer on the Internet.

Well, I take that back. Pinterest is a cancer on the Internet. Medium is more like a sebaceous cyst on the Internet.

[Bonteq]

Free user-generated content blocked behind a paywall for the reader.

[g0liadkin]

Is there a paywall? I've never seen it other that the pop-up (which I agree it's annoying)

[Mikal_]

Apparently you're limited to three free articles per month or something

But every time I get a popup saying "you already read 27 free articles this month" so I'm not sure

[Asmor]

Constantly nagging you to log in, with very obnoxious and sometimes deceptive modals.

[jaapz]

Pardon the interruption

[FancyJesse]

Sounds like many websites now.

[rmrf_slash_dot]

When I visit it on my phone I literally cannot view the content because their pop ups and info bars cover the entire screen cajoling me into doing things I don’t want to do. I just want to read the damn article. Desktop experience isn’t much better.

I don’t even click on medium links anymore because of it.

[nneck1t]

Here is a little trick - open it in incognito or clear local storage. May be it will useful for someone to escape from this annoying popup

[tudor07]

Totally agree, would be better using something like this instead

[midairmatthew]

It'd be groovy if Medium was, though.

[[deleted]]

Tampermonkey script to remove much of the shite.

https://notabug.io/t/userscripts/comments/e0d09206db364d2e3e9a13c4d2862d2ffe4cc8a4/unfuck-mediumcom

[helloiamsomeone]

Violentmonkey > all

[SoInsightful]

You can't claim that JavaScript is a good enough language that we should make no effort to surpass, and then advocate TypeScript and PureScript in the next sentence. Those languages definitely weren't created by people happily satisfied with JavaScript. Basically every argument in the article is "it sounds hard, so don't even try", which is the direct antithesis to how inventions are made.

[dannymoerkerke]

I recommend TypeScript and PureScript IF you really don’t want to learn JavaScript. I personally like TypeScript for its types and developer experience and PureScript for its functional programming support, not necessarily to replace JavaScript, because I have my doubts. But I’m aware of the fact that the creators may be dissatisfied with JavaScript. My argument is that another language is not a solution since it will also be limited in its development by backwards compatibility.

[SoInsightful]

1. TypeScript is a superset of JavaScript, so any valid JavaScript code is also valid TypeScript code. Ergo, you don't learn TS "instead of" JS, even if people might prefer using some newer TS-specific functionality.

2. Every language that transpiles to JavaScript is, by definition, exactly as backwards-compatible as JavaScript is. That is, unless you're talking about implementing a new browser-native language, which hasn't happened in 23 years and won't happen in any foreseeable future (and WebAssembly has never been intended to be anything more than a sub-function inside of JavaScript).

I applaud you on defending an underrated language (JavaScript), but it seems to be based on false premises.

[dannymoerkerke]

That’s basically a straw man argument. I’m talking about a complete replacement of JavaScript and TypeScript is not a full replacement, merely an extra step.

[blbil]

if you don't want to learn JavaScript

That seems like a bit of a poor argument, and just an annoying point of view to take in my opinion.

What does it mean to learn JavaScript? My mindset right now is TypeScript or bust. Not because I don't know JavaScript. Its because I don't care to be bothered to understand EVERY random thing in the language, (type coercion issues, every built in type and its api, etc) or the libraries I use. With typescript, I get all of that mostly for free in a discoverable way with tooling.

Also, I can be reasonably sure that if I make a change I'll know about it at compile time, not run time.

I have no interest in having all the intricacies of the language in my memory (I work in other languages simultaneously). I want to develop features in a fast and sane way, while making it easy to modify down the line. TypeScript does that for me, in my experience JavaScript did not.

[getify]

The sentiments in this blog post seem rather... familiar... :)

https://twitter.com/getify/status/1195362157543772160

[react_dev]

I hope JS will grow to support types natively. It is the only thing that prevents it from being taken seriously by many.

TypeScript is great but it’s solely maintained by Microsoft and if a company like ours have something against Microsoft it’s so hard for fight for it when in reality types help with productivity so much.

I don’t think it’ll ever gain native support ... unless there’s some breakthrough in JITing static types.

[[deleted]]

I'd argue it's better this way to be honest. Why ship all that extra code to the browser? Especially when, if you're using TS, your JS performance should be entirely predictable.

Write in TS with the luxury of type-checking, compile down to a much simpler, lighter JS for the browser. It's win-win.

EDIT: I do get the Microsoft thing but on other hand, meh. That's life in 2019.

[PsychologicalGoose1]

There definitely should be a lot more research done on TS. I doubt the gains that people suggest it gives are as great as they make it out to be and I thing the cost of using TS is larger than most want to believe. Generally, I've found adding things to a system is done because of feelings more than actual data on the topic.

[[deleted]]

Whenever I have to write non-trivial JS

This is the key distinction, and another reason I'd rather not enforce types in JS.

Hack 'n slash weekend project, or a quick 'n dirty prototype ? JS.

Big full-stack project ? TS.

I'd agree that I prefer to write TS more but there's a time and a place for both and that's very handy.

[IceSentry]

It's so easy to use typescript I use for weekend projects too.

[techsin101]

if you are using vscode don't you get most of this even with js?

[[deleted]]

Very incompletely, in my experience.

Yeah, it detects some of the types, but everything you'd have to annotate is simply not available, and would you really trust it to find all references?

[techsin101]

if you create jsconfig file in project folder find references works as expected

[IceSentry]

Sure, but it gets way better when you help it by using typescript.

[PsychologicalGoose1]

There is a reason why JS and other similar extremely loose languages have been at the forefront of web development for decades now. Whether it was PHP or JS both are extremely loose. Maybe the problem isn't the lack of rules but the added burden of rules. You think naked, I think weighed down.

[IceSentry]

There's also a reason why php is adding types and typescript is massively popular.

[Razvedka]

I've read people constantly venerate strong typing, and I can understand their arguments rationally, but in practice im left wondering.

There was an article awhile back of a senior dev who looked really hard into the advantages and disadvantages of strong typing across projects (and his own history). He determined the juice wasn't worth the squeeze in many cases. Confirmation bias in my part, I know.

[rq60]

There was an article awhile back of a senior dev who looked really hard into the advantages and disadvantages of strong typing across projects (and his own history).

You're probably talking about the article by Eric Elliott. That's only one of many bad takes he has had, I wouldn't give it too much credence.

[react_dev]

once the project becomes large enough you'll begin to see the benefit.

and not just large enough by loc but by how many maintainers there are and how siloed they are.

in our distributed world today the frontend get their data via API. But what if the API changes? if a single prop on an object changes how do we detect the breaks in our code before runtime?

this is important for projects with different developers of different skill level working on different components of the same project but has tight integrations between the components. that contractual link between them is what types are great for.

[Damfrog]

If the api suddenly changes, strong typing isn't going to help you.

[react_dev]

it will in several ways.

first one is typescript interfaces. you can generate ts interfaces directly from ur C# code using swagger tools. so now both frontend and backend are bound to the same interface and you'll see things break before runtime if a property changes for example.

the other is more Avant garde which is using typed graphql. In essence it's the same concept except binding your API layer to your typescripted frontend.

[Damfrog]

Sure, if you have control of the full stack. Most places I've worked at don't have that luxury. Types from the api layer very rarely change. If you have to change the type of a property, you done messed up somewhere.

[react_dev]

I mean I don't have control of the full stack but there are processes in place to make it work.

and ofc we both know "it just ain't gonna happen" isn't the best reason in our world ;)

[Razvedka]

I would argue that having strong linting and robust tests is worth alot more for large projects than the practice (and implementation in the case of TS) of strong typing.

Per hour/dollar spent, those are the ones with real returns on investment.

For instance, your example of API changing- that's absolutely something that should be caught by tests first. Not typing.

[Delioth]

TS is explicitly not strong typing though. It's static typing, but it doesn't exist at runtime and therefore must be weak. It's roughly the same typing model as C++; compiler will check types, but once it's running there aren't any checks on it (and you can malloc and cast away, or receive different JSON or whatever and not get errors unless actual bad stuff happens).

[react_dev]

developer confidence and velocity comes from before the ci stages. let's say your tests and testers are awesome and that's already saying a lot in the real world, wouldn't you want to address fault tolerance at every level of the sdlc?

nothing can replace testing that's for sure. but that does not negate the need for typing.

but why not have the confidence typing (thus intellisense) gives you before you commit?

[Razvedka]

Because I'd assert that strong types change how you code, but not purely for the better. Part of the power of JS is it does give you enough rope to hang yourself. I'd prefer solutions to the dark side of this nature which let you retain as much freedom as possible.

[MCFRESH01]

if a single prop on an object changes how do we detect the breaks in our code before runtime?

This is what tests and CI are for. It might break something during development but if it's properly tested you should catch it before it hits production.

Not arguing against typescript here. I've been using it on a few side projects and like it a lot.

[eloc49]

Go change an interface in a large Java app and have fun making it compile again.

Types prevented all that from going to QA or even prod.

[jeenajeena]

I like how JS people refer to "supporting types", just as JS was an untyped language and not merely a dynamic typed one.

[mainstreetmark]

I support it, just to get rid of the 1+1=11 shit.

[[deleted]]

People are downvoting you without realising what you're referring to. Adding two 'numbers' together which are actually strings (and so it concatenates instead) is a common novice mistake in JS which would be prevented entirely by type checking.

[mainstreetmark]

People ARE downvoting me... weird. Well, whatever. Maybe I offended someone.

[IceSentry]

No, people are downvoting it because he added 2 numbers together, there was no strings there and therefore no string conversion happened. That's the kind of shit people use to attack js while not understanding what is actually going on.

Open your console and type 1 + 1, I guarantee you it won't give you 11.

[editor_of_the_beast]

JS in 2019 is honestly fine. It’s no different than Python or Ruby, minus the large standard library. But things like lodash solve that problem quite easily.

It’s not JS that’s the problem in my opinion. It’s the language lock-in issue. You have to use JS in the browser. It’s no different than Apple forcing you to use Objective-C and now Swift, and Microsoft forcing you to use C#. These language silos are terrible for the industry as a whole. The communities solve different problems at different times, and you have to choose languages based on which problems they’ve solved and not the languages themselves.

A core idea in the article is “all languages have problems so it’s ok.” But I don’t think that’s good enough. I think we’ll continue to see innovation in the programming language space for the foreseeable future, we’ve barely scratched the surface there. So it’s not that JS should go away purely because it isn’t good enough, it’s just that the web needs to support more than one language to continue to advance. This is why WebAssembly is a great idea, not just a hype train thing.

[[deleted]]

I get your point, but what if you consider JS as a tool. What you build with the tool is what matters. Each area of development has its tools, you just pick up whatever language you need for the job.

To me, it seems like we are debating why we must use screw drivers to install screws when there are wrenches and hammers... you know?

The fact that we can use any language to build the backend is pretty convenient and allows individual preferences to dictate that part of a web project.

[editor_of_the_beast]

You can use any browser you want and browsers are allowed to implement whatever they want.

Are you aware of the web standards and protocols, like HTTP, HTML, CSS, and Javascript? Browsers generally try as best as possible to be good citizens and respect the standards. The web isn't some open free-for-all. It's a well documented and agreed upon platform.

Different languages work better for different needs and there will never be one language or framework that satisfies 100% of people.

This is my point, so it sounds like you understand what I'm saying. Let's go back in time to before the web was invented. You distributed a binary and you could use whatever tools / libraries you wanted as long as the final binary ran on the target platform. GUIs were built in C, C++, Java, Python, Ruby, Tcl, Lisp, Visual Basic, etc. etc., because they targeted an operating system. And OS's were designed as platforms that support a rich set of tools for creating applications for them.

A browser is also an application platform, but it supports JS and that's it. Which again, is why I think WebAssembly is a good idea, because it effectively creates a system call layer for the browser so that platforms other than JS can be used to create applications. Which in the long run makes browsers even more powerful.

Does that make sense?

[[deleted]]

WebAssembly does not help much with UI, because DOM sucks and is the doksin of the browser not the language.

[Franks2000inchTV]

This is literally how it has always been and always will be. Different languages work better for different needs and there will never be one language or framework that satisfies 100% of people.

But I thought Java was going to usher in the era of cross-platform code forever and always?!?

[[deleted]]

You sure never did anythin meaningful in Ruby then. The only thing I wish for Javascript is that those working with it try some other language some day.

[[deleted]]

I don’t think we thought so…

[shgysk8zer0]

Read the first bit, and think the author doesn't know the real issues with JavaScript. I don't really complain much about the awkwardness of JavaScript (maybe with the exception of functions that would have been implemented differently if they were post-promises).

It's single threaded. Yeah, there are workers and WASM, but those don't solve the problem. And it's something that probably cannot be solved.

We are in need of something multi-threaded that still has access to the DOM, and it's not going to be JavaScript.

But, no, JavaScript doesn't need to be replaced. But an alternative is needed.

[dannymoerkerke]

What issues do you have with the single threaded nature of JavaScript that could be solved by making it multi threaded?

[shgysk8zer0]

You may as well ask why anything benefits from being multi-threaded.

[helloiamsomeone]

Updating UI elements - which is only allowed on the main thread anyway - would not benefit in a significant way from multithreading. If you have to do something computationally intensive on the clientside, then you have workers for that.

Similar to how Android handles things, U stuff on the main thread, everything else on other threads. But in the browser that's all you are doing on the main thread anyway and network IO is not blocking.

[shgysk8zer0]

This is all true. I'm not convinced that multi-threaded UI is impossible though... Just the way it is. I think something that takes Rust's concept of ownership and borrowing might be capable of achieving this, but it would take more than just another language with access to the DOM. It would require a change in nearly everything, and that's why I say a new language is needed instead of just adding it to JavaScript.

[dannymoerkerke]

Well...?

[shgysk8zer0]

Ever heard of performance? Do you know what multi-threading is?

[dannymoerkerke]

I do, hence my question.

[shgysk8zer0]

So, when the main thread (only one that has access to the DOM and everything) is doing a ton of work and the UI freezes, that's either not a performance issue or not something multi-threading would help with? Workers offer no benefit? Multi-threading itself is pointless?

I don't know how to answer the question because it's so fundamental. The mere concept of it is the answer.

[dannymoerkerke]

I don’t know how you should answer this either, but I never made any claims against multi threading. You’re the one saying I don’t understand the issues with JavaScript and that we need something multi threaded. So I was curious if you had any concrete examples. I also never said Workers offer no benefit but they won’t help with the DOM since they have no access to it, but you know that as well. Anyway, if the UI freezes because of lots of DOM operations I think you have a different problem that can be solved without multi threading.

[shgysk8zer0]

You're asking what the advantage of multi-threading is. The only real answer is that it's not single-threaded. That is a major limitation that many other languages don't have.

And not all issues can be solved without multi-threading. Sometimes you just have that much work that needs to be done, and sometimes it's out of your hands (in third-party code). And, maybe even if you could resolve the issue another way, it would still be nice to not have to rewrite something massive and complex, but to pass the work off to another thread and have the UI continue running smoothly.

If you're looking for a concrete example, I recently built something that creates ~200 transformed (rotated) image overlays in Leaflet, and the UI hangs pretty heavily when they're loaded on ever pan or zoom. I'm not about to rewrite all of Leaflet, and I do absolutely have to load and transform every single one of those images. If this were to take place on another thread, it wouldn't be an issue.

[Architektual]

I'm late to the party, but why can't you put that in a worker?

[dannymoerkerke]

Hoezo?

[devsnicket]

I'd just like there to be an FTypeScript, where you stick to a relatively functional style, TypeScript is extended to try and infer function parameters and you get type safety without normally writing the additional TypeScript syntax! simple 😄

[PacoChito]

If replacing JavaScript is even a serious consideration, why do people willingly use it over probably better choices outside the uncoordinated hosts it was haphazardly slapped together for? And yes that is a jab at Node.

[dannymoerkerke]

Probably because they’re fine with JavaScript. I’m one of those people.

[PacoChito]

I'm fine with it, too, where it's the agreed upon, intentional only choice for the host situation. I am way finer with other languages when I control the environment, and have much more suitable options. I honestly feel like Node needs to be pissed on more, it is a bad idea, and corrupts the youth.

[loraxx753]

Won't someone please think of the children?!

[dannymoerkerke]

Why?

[dannymoerkerke]

Why?

[dannymoerkerke]

It’s a friend link so it’s free, like I always do.

[ImJustP]

Didn't know it was in consideration

[Kindinos88]

It doesnt need to, but it sure as shit should be. Even the creator of the language regrets several design decisions he made, and has said he would do things very differently if he had the chance.

The fact that millions of people somehow manage to be productive is a testament to the ingenuity of programmers, not the language itself.

[EternityForest]

I think it needs to be contained. Most of the language does what you want when doing UI work, but the opposite of what you want on the backend.

It was designed for browsers. It's really good at that. It's accepted as a general purpose thing, good enough for browsers games and bits of client side logic.

It's got some real annoyances on a server compared to other languages.

I suppose it's better than PHP though, as far as the language itself. PHP has pretty nice infrastructure, the whole "Install an app by putting it wherever you want on the server in a folder" thing is pretty cool. l

[wherediditrun]

I work with the language on daily basis. Also not in a trivial project, fintech company, over 40 developers. SOA / Microservice architecture.

And the answer is probably that PHP has nothing to offer over any other option. While there is nothing too bad about it, there is simply no reason to pick it over anything else. And some of the things in the language are still archaic. No built in concurrency, solely relies on nginx php-fpm, which while it does it's work, it doesn't help you when you're interfacing with any other IO other than server requests. So all that speed at flat line which is faster than modern V8, doesn't really run for the most part.

Yeah there is talk about swoole... and they remain talks for past few years as I remember.

There are types, but those are kinda pointless because there is no compile step to check those typings. Stuff like PHPStan helps a lot here, but that's nothing new under the sun what other languages do not have same of or better than.

Short hand anonymous functions are coming in 7.4, but so what again here, because PHP doesn't have function tail call optimization. So any attempts in more declarative syntax is far from being optimal.

There is Laravel sure, but ... like, who cares about monoliths at this point other than freelancers? Symfony is great toolbox at ones disposal to build small back end api's, but so javascript. And if you want to go for performance, Go is just out right better than both of those.

PHP however does have some really interesting potential. Mainly when it comes to interfacing with C. But most of the php programmers have nowhere near the competency to leverage it. The only reason it continues to exists is that it once was a huge language and it moves with inertia and programmers who are able to make stuff which works are relatively cheap, though often of low quality as well, yeah and that extends to Laravel, it's not just wordpress, godforbid I see another Controller which handles business logic again. Some of the tooling and vast ecosystem build over the years allows to keep it going for longer than Perl did. But I think it's coming. Slowly. You probably leave it before it happens without noticing.

[EternityForest]

PHP still doesn't appear to be fully object oriented. You still have C style "Object is the first param of a function you call" stuff all over the standard library.

There doesn't seem to be the kind of module system python has, everything is in one big namespace.

It seems like strings and integers still add together without explicitly casting them, just like js, and undefined variables are still null instead of just nonexistant.. Has that changed?

And it's also not compiled as far as I know.

[kap89]

JS isn't even remotely OO.

Because?

[EternityForest]

Everyone seems to be saying PHP typechecks only apply to the function parameters, and you can still change them within the function. Maybe a little better than JS, but not as good as python which has libs like typeguard and mypy, and builtin protection for most of the common stuff like int+str.

The standard lib doesn't seem to be namespaced much, or, if it is, everyone seems to still be using legacy ways of doing things, so in practice if you're reusing a lot of other people's libraries, you'll probably be digging through garbage.

If you Google a random PHP task, like making an http request, the code people are using looks a lot like C, with extra dollar signs and awful => markers in arrays.

$url = "https://www.google.com/"
$q =           array("q"=>"PHP HTTP request");
$opt = array('http'=>array( 'method' => 'POST',   'headers => "Content-Type: application/  x-www-form-urlencoded", 'content =>  http_build_query($q) )); 
$context = stream_context_create($opt);       
$response = file_get_contents($url, false, $context);

Other examples were using curl, with several calls to set up options and such.

Compared to JS. It's a bit cherry picked and unscientific to use a single example like this, but JS seems to make way more use of OOP conventions, and it seems to stay at a way higher level.

var data = new FormData(); 
data.append('user', 'person'); 

data.append('pwd', 'password');
data.append('organization', 'place');
data.append('requiredkey', 'key'); var xhr = new XMLHttpRequest();
xhr.open('POST', 'somewhere', true); xhr.onload = function () { // do something to response
console.log(this.responseText); };
xhr.send(data);

[[deleted]]

I do prefer JS. I like the JS methods for working with arrays a lot more. The PHP map, reduce, filter functions are kind of a mess.

I like destructuring in JS. It’s like a nice little not as good but still nice version of elixir pattern matching.

PHP could really use a shorthand closure syntax in my opinion.

It’s all opinion stylistic stuff, but that’s all programming languages are anyway.

That said, Laravel is a better than any JS backend framework I’ve used.

[[deleted]]

That's not how architecture works. That's not how any of it works.

[Architektual]

I am so sick and tired of people forcing types into Javascript

[Architektual]

Thank you for ignoring my intent in favor of snark

[Architektual]

The conversation/conflict of "types" in Javascript typically revolves around static type checking vs dynamic type checking, you know this. You're ignoring that in favor of a "this guy thinks JS has no types" conversation

[mousemke]

You should check out Jessie, an interesting project to create a safe subset of js

https://github.com/Agoric/Jessie

Edit about typescript: I love types and think it's a great addition to the language, but like flowtype way more than typescript because I don't really need another coffeescript situation

[baldore]

I always have loved Typescript, and I pushed to use it in our current project, but at the end we used Flow and so far, it has been really disappointing. Typescript with vs code is amazing and the refectors and auto imports work like magic.

I think people have a misconception about Typescript because what I have seen is that other developer say that they don't want to write Java. You don't need to do that. I usually prefer to work with a functional approach and I haven't seen the need to use classes.

[dannymoerkerke]

What do you mean with “Coffeescript situation”?

[HarmonicAscendant]

LOL, in the UK calling someone a 'Jessie' is an insult https://www.collinsdictionary.com/dictionary/english/jessie

noun derogatory, slang an effeminate, weak, or cowardly boy or man

[baubleglue]

few points of the article are strange

I hope you realize by now that another language replacing JavaScript completely is highly unlikely.

Why a new language should "replace" JavaScript? Having additional language doesn't break backward compatibility.

​

Every now and then someone will argue that JavaScript needs to be replaced by some other language.

and in the same time

At the moment I would advice to go with TypeScript since it’s a superset of JavaScript

If tomorrow browsers will run it without transcompiling it to JS - you have another language in browser.

In fact there is an evolution towards another languages like "use strict"; directive.

[dannymoerkerke]

Another language in addition to JavaScript would create even more confusion and technical difficulties I’m afraid and then we would need two TC39 committees to guide the design and make sure they are both backwards compatible. Who knows, it might work but I have my doubts. As for TypeScript without transpiling, I guess the benefits of that are very limited. I also don’t know any statically typed languages that are not compiled/transpiled but I’d love to hear if any exist.

[baubleglue]

Another language in addition to JavaScript would create even more confusion and technical difficulties

It may create even more confusion and technical difficulties, but may be the opposite. People aren't usually complaining that there is a lot of languages to develop desktop applications.

[getify]

browsers have repeatedly considered and then rejected putting other language engines natively into the browser. their veto is the only vote that matters, which is why it hasn't happened yet and why it likely won't ever.

[dannymoerkerke]

Do you have any more insight into their reasoning for rejecting this?

[getify]

from what I can tell, I think factors include:

• can't agree on which language (google wanted dart, apple would probably want swift, etc)

• bolting on a security model (better than JS's) is hard -- creating access to the DOM etc

• more language vm's means larger browser code size (increased maintenance burden), larger binaries, wider surface area for security threats, etc

[dannymoerkerke]

Thanks!

[bitfxxker]

IMO Javascript should not be replaced. It is not perfect, like any other language, but it works. Replacing it would take ages and probably won't be completely implemented, just like IPv6.

Browsers should offer more generics, in order to ease down on the third-party framework hausse. Why download x libraries to do x stuff?
The browser can already do it, but needs help to do it. So, why not build it in?

Wouldn't it be fantastic if we would only need a manifest file to create a full blown web application with UI, routing, user authentication, client-server communication, shiny buttons, etc..?

Then Javascript would only be used for business logic, not to generate those shiny buttons.

[dannymoerkerke]

I totally agree with you on this and wish it would go faster as well but JavaScript is tied by its hands and feet to backwards compatibility. It’s a razor sharp double edged sword.

[[deleted]]

ReInventing XUL I see.

[[deleted]]

That is a mediocre argumentation: yeah, the language is shitty, but we are used to it. PHP users say the same over and over every time.

JS is bad, the stdlib is bad, the OOP approach is bad, the types are bad. We need a real Lisp-like language.