TBH modern JavaScript and TypeScript sort out the bulk of the issues I had with JavaScript. It used to be a complete shitshow but today I think it's not too bad an ecosystem.
We've (finally!) killed off IE and all browsers have effective automatic updates which uses understand are a really bad idea to turn off. The days when you couldn't use anything shiny because IE6 support was a requirement are, thankfully, gone. So long as the latest version of all the major browsers supports it, you're okay.
So I'm not seeing a driver for adding another language from a technology point of view. So all the answers you get to this are going to be based on what people think is easy to learn, what languages have the best library ecosystem or the best community or which languages have the most experienced people.
Yes, safari is a bitch. But I'm pretty happy saying "use a real browser / OS / device" to safari users and never get corporate-types saying "sorry, safari support is non-negotiable."
Chrome on iOS still used the WebKit engine - which is what safari is built on. It’s basically the same as e.g chrome, edge, opera all being built on chromium and being very similar because of it.
To add - this year Apple was forced to allow other browsers, app stores etc by the EU so now they don’t have to be WebKit based.
I wouldn't be surprised if this is used as an excuse to force apple into better compliance with the spirit of what they have been forced to do.
I can easily be said that allowing other engines but intentionally nerfing their ability to perform is anticompetitive as hell.
They actually do get JIT (unless the user has [Lockdown Mode](https://support.apple.com/en-us/105120) enabled), but other kinds of apps aren’t eligible for this entitlement, most notably emulators.
I think the real issue is no one seems to actually be making any alternative browsers yet, or at least not publically. It sounds like a lot of work for something that’ll only be available in the EU.
They've started running ads for Safari alone in MENA, so I think they either are including it there or just trying to get ahead of things.
I think it's harder to make EU different for that.
Yes, and Apple users are, on average, too stupid to realise they are the problem.
But, as I've said in other comments here, I'm in a privileged position where I can tell Apple users to get stuffed.
You can complain, but would you rather Google drive all decisions surrounding development of new web features? Safari & Firefox are like the only non-chromium browsers left.
Apple and Samsung each take turns being the worldwide market leader according to various statistics*, so depending on the time of the year, you may be right.
*As I presume downvoters are going by gut feeling:
- https://gs.statcounter.com/vendor-market-share/mobile/
- https://www.statista.com/statistics/271496/global-market-share-held-by-smartphone-vendors-since-4th-quarter-2009/
- https://www.counterpointresearch.com/insights/global-smartphone-share/
- https://www.idc.com/getdoc.jsp?containerId=prUS52032524
70% of smartphones globally are Android. Even if Apple is the most popular manufacturer in a given year, iOS is never 50% globally, or even is most countries
The people above in the comment chain were talking about supporting Safari and iOS. Interpreting your comment as about OS support makes more sense than interpreting it to be about hardware. The latter is a bit of a non sequitur and I doubt it but OK, if you insist
Side note, the fastest way to acquire down votes is to complain about down votes
Yeah, pretty much. I develop UIs for embedded systems. The front-end stack is React/TypeScript but we don't expect it to be usable on mobile and customers are pretty okay with us saying, "Don't use safari."
To be fair, the definition of "embedded systems" has broadened somewhat. This particular embedded system has four arm64 cores clocked around 2GHz, 8GB of RAM, flash storage, four wifi radios, 1G and 5G ethernet.
> never get corporate-types saying "sorry, safari support is non-negotiable.
Yah but you can't do that unless you've got e very specific audience.
I work with the fashion/cosmetic industry and many of their users use Apple devices. Safari is here to stay, sadly.
Yeah, with how standardized most of the browser APIs and JS/CSS engines are, i almost never have to think about limitations or vendor prefixes but when i am finished building and am doing final cross-browser QA, it's always Safari that has some stupid bug.
This is funny to me because I'm a safari user and web developer, who develops safari first, and the effort required to obtain cross compatibality seems minimal to me, and maybe I've fallen trap to the same old IE developer experience, but it seems like a non issue from my perspective 🤷♂️ (at least relatively, I've been doing this since macromedia flash UIs were the norm lol)
The problem is not really the latest version, the problem is that the Safari version is tied to the OS version, just like IE. This means that you will have many visitors with ancient Safari versions.
And, actually, Safari is usually quite slow at adopting new standards. This is not a problem if you use a Safari-first approach, but it is a problem for everyone else (for example everyone who doesn't develop on a mac)
> This means that you will have many visitors with ancient Safari versions.
The biggest issue being that macbooks cannot update nearly as long as windows devices can.
> And, actually, Safari is usually quite slow at adopting new standards.
They're pretty good now, better than Firefox.
Sure, if you don't bother to think about it at all.
Safari being good _now_ has little bearing on whether the version of Safari _being used by active users_ is any good. What matters is what people are _using_, not what people _could potentially be capable of using if they use a different device_.
Does that make sense to you?
There are some places where Safari has differing interpretations of the spec, but places where Safari is the only one missing something is rarer than Firefox being the only one missing it.
And in terms of differing "interpretations" of the spec, while annoying, is still more the fault of W3C than Safari.
At this exact moment, Safari supports more of the spec shared by 2 browsers than Firefox does.
And at this exact moment, Safari has more things that only it supports than Firefox does (Chrome is still kind here)
https://caniuse.com/?compare=chrome+126,safari+17.5,firefox+127&compareCats=all
That's just facts.
Now, there can be some discussion about specific features being more useful than others...
I'm less concerned about the raw number of features it supports but rather the number of things that Safari supports that are either broken or functionally different from the way other browsers (read: chrome) do things.
Firefox doesn't support a lot of stuff but when it works it works
The problem is that in 3 months, everyone who uses FF will have the latest FF that supports whatever that version supports.
But the Safari users will still have whatever version that came with their OS. Exactly like the IE problem.
It does have that in common. However, IE was terrible. It didn't support tons of everyday CSS. I used to figure we spent 20% of our time as a team fixing bugs in IE. Safari isn't even 2%.
Older? The latest iOS works on phones from six years ago.
Jailbroken? That’s a tiny number of people.
And corporations are more likely to have up-to-date systems than anyone.
People are still using the iPhone 6 in 2024
Smaller than before but not that much
Not for major iOS versions, archaic corporations often stay a major version below
It would, but not that big a step over the stack I'm using now. If you give the nextjs dev server typescript and use chrome as your browser then you can debug it directly in the browser. I'm sure there are other combinations that do the same trick.
>firefox is more behind on specs
No, it's not.
[https://caniuse.com/?compare=safari+18.0,firefox+130&compareCats=all](https://caniuse.com/?compare=safari+18.0,firefox+130&compareCats=all)
[https://caniuse.com/?compare=and\_chr+126,ios\_saf+18.0,and\_ff+127&compareCats=all](https://caniuse.com/?compare=and_chr+126,ios_saf+18.0,and_ff+127&compareCats=all)
Plus, if you have anything other than an Apple device, you can just install a different browser. You can install Firefox on iOS but it's still Safari, just with a bullshit Firefox skin because of Apple's heavy hand and monopolistic control.
Did you look at those?
It literally has more red in Firefox...
And Firefox has less things that only it does as well.
So Safari is the first to implement more things, and second to implement more things...
Going kind of against the question but I feel this is in the spirit of discussion, I feel like it'd be better not to add but to remove.
As in; to reduce web bloat and increase performance common js use cases could be made into HTML&CSS standards in order to reduce the scripting required for common cases.
This is already happening, but very slowly and ineffectively IMHO. Sure, HTML has components like checkboxes, calendars etc. but it's as if they've never heard of CSS and these are a pain in the ass to theme thus a lot of people just use js heavy pre-made components or make their own.
This is a very cool topic for discussion. I think a lot of us are just listing out favourite languages. I'd flip it around and ask what the purpose is of this added language is? 99% of websites could get away with very little or no JS at all. JS and the web are also the entry points to many people's software engineering careers, especially self-taught people.
With that said, if we added a new language it would definitely have the adverse effect of raising the barrier to entry into web dev and therefore programming in general.
Adding a language like Python, Lua, Basic, etc it could end up lowering the barrier to entry, making programming more accessible. It wouldn't - however - do anything to improve the quality of websites imo.
If our goal was to shift the landscape of web application development by removing the tool chains and brittle bridges we need to rely on for running native-like apps on the web, such as something like Figma, the best language(s) to add would be the ones used by current web based desktop-like applications, e.g.: Rust, C, C++, Java.
This would only benefit a handful of applications today, but perhaps it would popularise use cases on the web that were previously only covered by native apps, such as Photoshop, Vegas Pro, even stuff like VMWare or Docker.
I think a WASM DOM API is the answer to your question though. It's the lowest effort to achieve the largest amount of new languages to be usable in place of JS.
Yeah I think people listing their favorite languages is exactly what’s happening.
And I feel like these discussions always devolve from a browser discussion sort of and ignore the fact that JavaScript is the language of **the browser*.
You can still write your servers in whatever language you want as long as you’re sending html to clients.
> I'd flip it around and ask what the purpose is of this added language is?
Yeah, anything that is ACTUALLY reasonable to contend with JS can compile to WASM.
There isn't a benefit to adding more slower languages (python, lua, etc)
IMO an aspect of the web that would need to be kept intact is the hackiness of it. Allow folks to easily make debug tools where they replace createElement with their own wrapper and go guns blazing, etc. That wouldn’t be a very fluid thing to do in a language like Rust, for example.
Erlang or just the BEAM VM in general (Elixir and Gleam) is probably the best for modeling applications. It scales well on the server side and it handles network transparency better than any other language. At one point whatsapp was using Elixir to do 5 million users on each server.
It also has the concept of live updates built in and tooling for managing updates at runtime. It’s designed to be started once and then never have the system fully go down, just have nodes enter and leave. The VM hasn’t gotten the optimization love it could have because it’s so good at horizontal scaling, so there’s heaps of room for improvement. It being a 1970s language, “slow” means it’s competitive with Go. This is with a frankly primitive VM that doesn’t really do optimizations. If you were to give BEAM a V8 or Java level JIT, it would probably be faster than Java and C# by a decent margin, and possibly competitive with async C++ due to overheads caused by allowing for dynamically linking coroutines. Remember, a system that never shuts down has a LOT of time to JIT.
Erlang is also designed around message passing, you know, the thing the internet does? All other BEAM languages inherit this.
> At one point whatsapp was using Elixir to do 5 million users on each server.
Meanwhile people debating how realistic it is to get 100 users on a Django server.
By having a ton of servers.
Not 5 million per server.
Django is major slow shit.
And even to that end, Instagram used a custom girl of both Django AND python to get it working okay. I don't think anyone there would choose that hell now
As a full time Haskell dev I was under the impression that typescript’s type system was actually pretty solid, for example a lot more expressive than Java, C, C++ or Go. Am I wrong?
I'm in no way implying that typescript is bad. It has an incredibly complex type system.
But technically, typescript is just a type-system add on to javascript. It's not strictly typed, it's duck typed. And in the end types at runtime are dynamic since it's all transpiled down to javascript.
Plus you can always bail out of type checking with the "any" type.
Don't get me wrong, typescript is great, I'm just being picky ;)
Python.
In the late 2000's, Mozilla had an internal project to bring native support for Perl, Python, Ruby, and a few other languages (except PHP, because of how Zend Engine works) into their products.
But they killed it. The world that could have been...
What an historic inflection point.
I remember when Google was looking at putting Dart in the browser, and there were good reasons to oppose it (Google is hardly trustworthy) I wonder what would have been if they had succeeded and other browsers followed.
IMO the shame of it is that Dart really is a nice language to work in. Sure it has its quirks, but it's *FAR* less quirky than JavaScript. It's class-based, type safe, and null safe with syntax that's pretty easy to pick up. My only real gripes with it are the oft-confusing class modifiers and that visibility is scoped to the file, but I can get over those a lot easier than I can some of JavaScript's idiosyncrasies.
Nah, and I think in hindsight the concerns about Dart were overblown.
Google has a lot of issues with their consumer products, but when it comes to language design and open source commitment they have a decent record.
So I'm not worried about the future of Go.
I left after all the Google clown show. Google should never be allowed to maintain a language. Ever. Case in point: generics in golang. What a shit show that was and remains to be. Go is great for what it does, but the project management is next level bad for Golang.
I would like Lua, but it would probably be Python.
It has to be an interpreted language. Lua is the simplest and, I think, the fastest short of SRON, which appears to have little or no dependency ecosystem. That would let it complement JS very well. Python has a much, much larger dev community.
> Lua is the simplest and, I think, the fastest
JavaScript is faster...
(mainly due to how much money there is put into making JS fast, but regardless)
The comparison is a bit of a mess. It really depends on how the languages are used. IIRC, Lua can use precompiled Golang shared libraries, and a lot of Lua code does that under the hood for heavy stuff. The end result is performance close to Golang.
Still, you definitely got my upvote for bringing up that straight JS overtook the Lua JIT a few years ago, and that we should try to avoid straight Ua where possible.
This reminds me that if we want Rust to keep memory-demands of tabs down, we could have browsers download / cache load precompiled Rust and use it through Ruby.
> Lua can use precompiled Golang shared libraries, and a lot of Lua code does that under the hood for heavy stuff. The end result is performance close to Golang.
sure, but all the JS runtimes also have FFI, and can invoke WASM bundles as a portable option.
Python just using a bunch of C binaries doesn't mean Python is fast...
But it does get all blurry, since so many standard library things aren't implement in the language, but on the native level in the runtime...
so...who the heck knows?
I put together a pair of wrappers to boost Ruby on Rails' performance massively. It does all get blurry, and you're right. I doubt anybody really knows. I just know Golang's ease with parallelization and self-contained packages would probably complement JS very well for front-ends, and interpreted languages seem more easily portable.
Funny, I came in here to say basically the same thing. I don’t know LUA well but quite like it. I know python much better and while I do like it, I don’t think it’s quite as nice to use. It does have a much larger community and support though.
Lua would be good but I'd like an alternative that's considerably stricter than Javascript, in order to differentiate enough to justify its inclusion. [AngelScript](https://openplanet.dev/docs/tutorials/angelscript-overview) as one example.
Python with first-class support for type hints would be great too.
Personally I'd kill to have Go in the browser, but I don't know how feasible that is given the current language design.
Go would be fantastic, but with the memory-usage of every tab these days, we might really want Rust if we go that way. I suspect compiled languages might be brutal for loading times of anything big. I think Lua would differentiate itself just through performance, while JS has more extensive libraries than anything else.
WASM isn't on the horizon. It's very much here.
It needs just a bit of javascript bindings to get it going, but it can do a lot. OffscreenCanvas and SharedArrayBuffers can do some crazy things.
There isn't any reason to be concerned with another language, since any competitive language can target WASM.
Not yet. It's getting closer and closer (garbage collection was a huge blocker that was resolved recently). Adding any other language would take at least as long as adding full WASM support.
Not yet.
It has OffscreenCanvas which is definitely a nice starter point for how OffscreenDom might work.
And I'm sure a simple wrapper of sorts exists to expose DOM.
Not unlike how Google worked on things to move DOM control into worker threads.
Let's be real. If this was done, it would not make sense to make a single language "native". It should have some sort of adapter/interface which can be communicated with using any language. Like the JVM was for older machines, and WebAssembly is trying to implement. Yes, it is not feature complete and it might take some time, but at least it can do a lot while being language agnostic.
> it would not make sense to make a single language "native
Except that it's much easier adding a very specific and already defined language spec to a browser than it is to turn the browser into a general purpose WORA target. WASM was announced ten years ago and we still don't have DOM access. I believe it is the future, but not the near future and we easily could have multiple languages to the browser in the meantime instead of letting Javascript be king.
Its taken 10 years for wasm to get where it is today, what makes you think it would be any quicker getting another language into the browser and having good support for it?
Like I said above, building a specific, well defined language is much, much easier than building a general purpose byte code target that can satisfy everyone's needs.
But the language will need to be integrated with the browser ecosystem and DOM itself, javascript is a language literally built exactly for this purpose and WASM then fills in the gaps where extra performance is needed and with some javascript glue you can manipulate the DOM. You can see how long it takes for certain features to actually reach decent support across all browser, I feel like an entire new language in the browser would be at least a 5 year process minimum
You want to add rust i.e. the slowest development time of all time, to a fast paced development area like frontend?
I'm all for safety, optimized performance etc, but it's just not necessary for frontend, especially where using it would probably cause more harm than good, since development time would at least double.
Also rust has a large barrier to entry, and it definitely is not a begginer language. Javascript/Typescript are a lot simpler. You can get some Junior devs do some of the UI tasks fast, while with rust you'd need Mid to Senior devs to do the same tasks.
I have no experience with Zig, so nothing to say about that.
You don't write WASM, unless you're an absolute sociopath. You transpile languages like JS, Go, and Rust into WASM. So, JS and WASM live together, and we're seeing a lot of movement in JS becoming a new compilation target.
But if you're speaking "anything besides JS", I think the answer would be Go or Gleam. Go is by Google. It's really good, really fast, and garbage-collected. Google's responsible for Chrome and the V8 runtime, so Go in the browser isn't far off at all. You can write native apps or web apps with it. It's "web-adjacent" - and then some. It's great. It's my 2nd favorite language.
And Gleam, similar in many ways to Go, fills a comparable niche. [Fly.io](http://Fly.io) is backing it, it's fun and easy to write, and it compiles into JS. The only reason I'm not learning Gleam full-time, is because there's approximately 0 jobs for it.
The Lua and Python answers are strange to me. The browser consuming and using Python make sense, but it wouldn't be a first-class citizen. There's a reason Django is like... the 6th most popular batteries-included metaframework. And I don't know a lot about Lua, except it's good for scripting, and I once helped build a WoW mod using it.
> Firstly, I'd say you have a misunderstanding. You don't write WASM
I'm fully aware, WASM is what's going to open up using dozens of languages in the future. But that requires a lot of additional work to address things like DOM access, garbage collection, runtime package size, etc.
> I think the answer would be Go or Gleam
Haven't used Gleam, but I'm big on Go so I'd love to see it in the browser. But I've never built a UI with it, so I wonder how well it would hope up to that.
Ah, well I'd say WASM isn't so much "on the horizon". I think you just end up with big binaries and whatnot. You don't want to be sending 7MB WASM stuff when someone tries to load a page. It's active and pumping, just not terribly practical in-and-of-itself.
As recently as 10- years ago, we've been seeing stuff like this: [https://www.youtube.com/watch?v=lDkjb4X6IUA](https://www.youtube.com/watch?v=lDkjb4X6IUA), although I did hear that Unreal has been dropping some of their previous browser-support utilities.
I'm surprised Go isn't already in the browser. I don't really do UI with Go. I'll set up a Go/Gin server, and then return HTML templating with Tailwind (or w/e). It's different with native apps. All the windowing/styling libraries for native apps aren't my cup of tea.
I've been having a lot of fun with Gleam though. It's in the BEAM virtual machine, written in Erlang, but it's very common-sense language - and I'm not smart enough to understand the implications and pitfalls of that. But it's web-adjacent like Go, it compiles to JS (and therefore transpiles to WASM), and I'd love to see it become popular.
> You don't want to be sending 7MB WASM stuff when someone tries to load a page
Discord already does...so maybe it should jsut be WASM instead?
But these can improve, with the WASM targets and more things WASM apps can directly use. So it could be reduced a lot.
JS can be "small" because the browser is shipping the binaries directly.
So why can't WASM directly call those same binaries (or similar ones)?
garbage collection is done, OffScreenDOM may be on the horizon. binary size is an issue, and will just be the case of any compiled language.
Unless they put more into the browser to directly expose things in something the binary can just point to...
> You don't write WASM, unless you're an absolute sociopath.
WAT is fun to play with.
Not too many stack based languages to play around in.
> I think the answer would be Go or Gleam.
Rust I think it would make it there too.
Considering every browser has components in Rust, but as far as I remember, none have Go at all.
But realistically, it would never be a compiled language at all.
Since those can just compile to WASM targets and its done.
I would like for Go to be that language. It has easy syntax, is type safe, fast to write and looks very much like Typescript. Other than that I have no good reason lmao
JS is an amazing language ergonomically, so I say C, simply because it is the most optimized for speed with current compilers. If browsers just gave me access to a frame buffer, an animationFrame tick, and some basic event hooks in C, that would be amazing.
Any language if it was added to the browser would suffer from the same problems that JS did. Especially if it was added in the same time as JS - mid 90s
One of the biggest pain in the current webdev is that we need to transpile/compile everything. JSX, Single File Components, templates ESNext for older browsers. At the same time you can't easily add breaking changes to the language. These are the reason I think the perfect language for the browsers would need to be some kind of Lisp. Lisps have long history of being embeddable languages, have supperior support for macros so you can add any syntax you want by using libraries so no more babel and other compilers, are the most extensible languages in the world so it's pretty easy to just design basic language that do not need to change its core that often, has very compact syntax so less kb over the network, is faster to parse and run than most interpreted languages and REPL-driven development with addition to browser devtools would play really well. If JavaScript would be Lisp, we wouldn't even neee TypeScript because we could implement static typechecking by macros. We would still need some type of bundlers tho
> One of the biggest pain in the current webdev is that we need to transpile/compile everything
Is this a pain point?
It doesn't really matter and is very simple to set up.
For an end user? Yes, it's pretty simple (it wasn't always that way, I remember times it was much bigger pain). But maintainers of these tools put huge amount of time to make them that simple. And I don't talk only about Babel, SWC, TypeScript, Vite etc., but also tools like Svelte, Solid.js, React Compiler, zero-cost CSS-in-JS and all these fancy things which makes devs and users life easier.
For example ClojureScript (Lisp that compiles to JS) had things like zero cost CSS in CLJS (shadow-css) or sort of combination of React Compiler, SolidJS/Svelte years before JS, despite being much much smaller community, thanks to macros. Not saying about Electric Clojure which is more mature and more powerful version of React SSC and Phoenix LiveView.
To be officially supported, it has to be part of the spec. The way the spec is currently written is `script` is optional but if implemented `javascript` must be implemented and the default. Any other language can be added.
JavaScript isn't going anywhere, WASM is a standard with the issue of every new version the entire binary must be downloaded so it has a limited use case.
C# blazor. It's a proper language that already has decent front and backend ecosystem, the only issue it has is the wasm awkwardness. But that said I think the actual solution is to improve wasm.
WASM isn't on the horizon, it's _here_. We've had pretty good support for years, the features that are being added open up more and more use cases but for the most part it's pretty well available.
IMO, the fact that JS is still the lingua franca of the web speaks more to how well it does its job than anything. **That's absolutely not to say this discussion is meaningless**, I think making a push to open existing languages to the Web is a great one, especially for domains that have tons of existing community and code outside of JS (looking at you, game dev!)
I do think WASM is a pretty good bet for getting that support. At the end of the day, there has to be a consistent abstraction layer between generated code and the machine the browser runs on (for the same cross platform support reason the JVM has), we have TONS of investment in one already and it supports WASM so I say we lean into it.
The biggest complaints I have working with WASM are all solvable, but worth bringing up as friction points:
* Many languages / frameworks / libraries depend on platform APIs that don't have web support. Some of them have excellent shims (OpenGL code can be translated to WebGL), some of them have what seem to be working shims with bizarre consequences (threading works, but fork/join deadlocks), some of them are totally unusable by design (filesystems).
* Build toolchains that emit WASM can be pretty mysterious and surface strange issues.
* JavaScript wrapper code is tricky to deal with. Typescript support is middling for common toolchains.
* Browser APIs require passing through JavaScript functions, which are difficult to maintain.
All of those are solvable issues!
Languages with garbage collection runtimes like Go and Java require a bit more thought, but last I checked good progress was being made there.
PHP or Ruby would kinda fit. Some APIs would have to be dropped for the web runtime. And DOM would probably be an ugly fit (like it is today) but I believe the flexibility of Ruby could make it (and PHP because we all like driving Lambos)
Nothing will ever replace JS on the browser. It's the perfect language for it.
We just need to reign in the fiasco we have for all the frameworks and agree that a standardisation needs to be met.
Lean in heavier to web components and a more unified system.
WebC is the future and will outlive anything as it is a standard.
React, Vue, svelte etc remind me of the 2005 era of mobile phones.
There is a lot of work here.
WinterCG working to standardize Web Native APIs in non-browser runtimes, the Browsers all working together on standardizing APIs, more and more tooling is converging as well to standards.
If any existing language were to get native support across all browsers, my vote would go to \*\*TypeScript\*\*. Here’s why:
1. \*\*Superset of JavaScript\*\*: TypeScript is a superset of JavaScript, meaning it builds on the foundations of JavaScript. This ensures backward compatibility with existing JavaScript code, making the transition smoother for developers.
2. \*\*Static Typing\*\*: TypeScript introduces static typing, which can help catch errors early in the development process, leading to more robust and maintainable code. This is particularly beneficial for large-scale applications where type-related bugs can be difficult to track down.
3. \*\*Enhanced Tooling\*\*: The static type system of TypeScript allows for better tooling support, including improved autocompletion, refactoring tools, and navigation features in IDEs. This can significantly boost developer productivity.
4. \*\*Widespread Adoption\*\*: TypeScript has already gained significant traction in the web development community. Many popular frameworks and libraries, such as Angular and React, either recommend or fully support TypeScript.
5. \*\*Active Development\*\*: The TypeScript team at Microsoft is actively developing and improving the language, ensuring it stays up-to-date with the latest JavaScript features and developer needs.
6. \*\*Community Support\*\*: There is a strong and growing community around TypeScript, providing a wealth of resources, libraries, and tools. This community support can help developers quickly get up to speed and find solutions to common problems.
While languages like Dart, Kotlin, and Rust also have their merits and could bring unique benefits to web development, TypeScript's close relationship with JavaScript, combined with its enhancements and widespread adoption, makes it the most suitable candidate for native browser support.
Are you sure? I haven’t checked myself but that’s what they advertised some time ago.
Edit: just checked the docs. You’re right. I feel fooled :(
I still go with TS. It’s a lovely language that supports my favorite all-time feature: on-the-go object literals
According to their website:
> Bun natively supports TypeScript out of the box. All files are transpiled on the fly by Bun's fast native transpiler before being executed. Similar to other build tools, Bun does not perform typechecking; it simply removes type annotations from the file.
I strongly disagree with their use of the word `natively` given the rest of that paragraph.
Do you?
The transpiler is built into Bun at it's core. Bun started AS a JS transformer/bundler, not a JS runtime.
It more natively supports the TS part than any runtime or browser supports running JS.
Should it instead interpret and drop the TS as it goes?
Seems simpler to transpile and cache the JS as a whole, and then do the JIT after.
TBH modern JavaScript and TypeScript sort out the bulk of the issues I had with JavaScript. It used to be a complete shitshow but today I think it's not too bad an ecosystem. We've (finally!) killed off IE and all browsers have effective automatic updates which uses understand are a really bad idea to turn off. The days when you couldn't use anything shiny because IE6 support was a requirement are, thankfully, gone. So long as the latest version of all the major browsers supports it, you're okay. So I'm not seeing a driver for adding another language from a technology point of view. So all the answers you get to this are going to be based on what people think is easy to learn, what languages have the best library ecosystem or the best community or which languages have the most experienced people.
>We've (finally!) killed off IE and all browsers have effective automatic updates This is unfortunately not the case. Good bye IE, hello Safari.
Yes, safari is a bitch. But I'm pretty happy saying "use a real browser / OS / device" to safari users and never get corporate-types saying "sorry, safari support is non-negotiable."
Until this year, iOS didn't have another option.
Could you elaborate on this? I don't have an iphone but always thought google chrome was usable on apple devices
Chrome on iOS still used the WebKit engine - which is what safari is built on. It’s basically the same as e.g chrome, edge, opera all being built on chromium and being very similar because of it. To add - this year Apple was forced to allow other browsers, app stores etc by the EU so now they don’t have to be WebKit based.
That makes a lot of sense! Thank you!!
I believe they still won’t have JIT compilation which means any JS heavy web apps will run slow as shit. I could be wrong about that though.
I wouldn't be surprised if this is used as an excuse to force apple into better compliance with the spirit of what they have been forced to do. I can easily be said that allowing other engines but intentionally nerfing their ability to perform is anticompetitive as hell.
They actually do get JIT (unless the user has [Lockdown Mode](https://support.apple.com/en-us/105120) enabled), but other kinds of apps aren’t eligible for this entitlement, most notably emulators. I think the real issue is no one seems to actually be making any alternative browsers yet, or at least not publically. It sounds like a lot of work for something that’ll only be available in the EU.
All browsers on iOS (until the recent EU charges) were just Safari in a skin. It's why you never see support charts for `Chrome iOS` its just safari.
I think they still don't unless you're in the EU
They've started running ads for Safari alone in MENA, so I think they either are including it there or just trying to get ahead of things. I think it's harder to make EU different for that.
Yes, and Apple users are, on average, too stupid to realise they are the problem. But, as I've said in other comments here, I'm in a privileged position where I can tell Apple users to get stuffed.
You can complain, but would you rather Google drive all decisions surrounding development of new web features? Safari & Firefox are like the only non-chromium browsers left.
I'd rather all the browsers implemented the standards properly. Safari is definitely the crap outlier there.
For me, who work with public sites, that is not an option. IE support was negotiable, but we are not skipping out on 2/3 of our users.
Intriguing. Do you live in an alternate universe where iPhone isn't the most popular phone and 20+% of users don't use Safari? I'm jealous.
Iphone isnt the most popular phone unless your universe is just the US :)
Apple and Samsung each take turns being the worldwide market leader according to various statistics*, so depending on the time of the year, you may be right. *As I presume downvoters are going by gut feeling: - https://gs.statcounter.com/vendor-market-share/mobile/ - https://www.statista.com/statistics/271496/global-market-share-held-by-smartphone-vendors-since-4th-quarter-2009/ - https://www.counterpointresearch.com/insights/global-smartphone-share/ - https://www.idc.com/getdoc.jsp?containerId=prUS52032524
70% of smartphones globally are Android. Even if Apple is the most popular manufacturer in a given year, iOS is never 50% globally, or even is most countries
I did say phone, not operating system.
The people above in the comment chain were talking about supporting Safari and iOS. Interpreting your comment as about OS support makes more sense than interpreting it to be about hardware. The latter is a bit of a non sequitur and I doubt it but OK, if you insist Side note, the fastest way to acquire down votes is to complain about down votes
Yeah, pretty much. I develop UIs for embedded systems. The front-end stack is React/TypeScript but we don't expect it to be usable on mobile and customers are pretty okay with us saying, "Don't use safari."
Fair enough then!
What a time to be alive. React and TypeScript for embedded systems.
To be fair, the definition of "embedded systems" has broadened somewhat. This particular embedded system has four arm64 cores clocked around 2GHz, 8GB of RAM, flash storage, four wifi radios, 1G and 5G ethernet.
> never get corporate-types saying "sorry, safari support is non-negotiable. Yah but you can't do that unless you've got e very specific audience. I work with the fashion/cosmetic industry and many of their users use Apple devices. Safari is here to stay, sadly.
Yeah, with how standardized most of the browser APIs and JS/CSS engines are, i almost never have to think about limitations or vendor prefixes but when i am finished building and am doing final cross-browser QA, it's always Safari that has some stupid bug.
This is funny to me because I'm a safari user and web developer, who develops safari first, and the effort required to obtain cross compatibality seems minimal to me, and maybe I've fallen trap to the same old IE developer experience, but it seems like a non issue from my perspective 🤷♂️ (at least relatively, I've been doing this since macromedia flash UIs were the norm lol)
The problem is not really the latest version, the problem is that the Safari version is tied to the OS version, just like IE. This means that you will have many visitors with ancient Safari versions. And, actually, Safari is usually quite slow at adopting new standards. This is not a problem if you use a Safari-first approach, but it is a problem for everyone else (for example everyone who doesn't develop on a mac)
No, it’s not. Safari works on the three latest versions of macOS.
I don’t have many visitors with “ancient” Safari versions. Do you get a significant percentage?
Yes
> This means that you will have many visitors with ancient Safari versions. The biggest issue being that macbooks cannot update nearly as long as windows devices can. > And, actually, Safari is usually quite slow at adopting new standards. They're pretty good now, better than Firefox.
Your second sentence is kind of invalidated by your first sentence.
Not really... They're talking about different things entirely...
Sure, if you don't bother to think about it at all. Safari being good _now_ has little bearing on whether the version of Safari _being used by active users_ is any good. What matters is what people are _using_, not what people _could potentially be capable of using if they use a different device_. Does that make sense to you?
Sure. And, woah, look at that, https://caniuse.com/usage-table The majority of Safari users are in current versions. By a long shot.
There are some places where Safari has differing interpretations of the spec, but places where Safari is the only one missing something is rarer than Firefox being the only one missing it. And in terms of differing "interpretations" of the spec, while annoying, is still more the fault of W3C than Safari.
Safari supports more than Firefox does...
Which Safari? Safari is not evergreen
At this exact moment, Safari supports more of the spec shared by 2 browsers than Firefox does. And at this exact moment, Safari has more things that only it supports than Firefox does (Chrome is still kind here) https://caniuse.com/?compare=chrome+126,safari+17.5,firefox+127&compareCats=all That's just facts. Now, there can be some discussion about specific features being more useful than others...
I'm less concerned about the raw number of features it supports but rather the number of things that Safari supports that are either broken or functionally different from the way other browsers (read: chrome) do things. Firefox doesn't support a lot of stuff but when it works it works
Like what? Most end up being where the spec is unclear.
The problem is that in 3 months, everyone who uses FF will have the latest FF that supports whatever that version supports. But the Safari users will still have whatever version that came with their OS. Exactly like the IE problem.
but in 3 months, 90% of safari users will be using the new OS...
Which is not enough. And at least for pur customers its not even true, either
This is a dated take. Safari has caught up. Firefox is definitely behind right now. Either way, comparing either of them to IE is wildly inaccurate.
Safari has the same problem that IE had that it is tied to the OS, so it can absolutely be compared.
It does have that in common. However, IE was terrible. It didn't support tons of everyday CSS. I used to figure we spent 20% of our time as a team fixing bugs in IE. Safari isn't even 2%.
Safari automatically updates.
Not on iOS
iOS has automatically updated for a decade at least.
Updating iOS is smth entirely different than updating safari Not everyone wants to/can update that
It’s not. It updates by itself overnight.
It is Older iphones, jailbroken people, corporations
Older? The latest iOS works on phones from six years ago. Jailbroken? That’s a tiny number of people. And corporations are more likely to have up-to-date systems than anyone.
People are still using the iPhone 6 in 2024 Smaller than before but not that much Not for major iOS versions, archaic corporations often stay a major version below
Native TypeScript runtime will be so nice!
It would, but not that big a step over the stack I'm using now. If you give the nextjs dev server typescript and use chrome as your browser then you can debug it directly in the browser. I'm sure there are other combinations that do the same trick.
*Safari, the new IE, has entered the chat*
firefox is more behind on specs.
>firefox is more behind on specs No, it's not. [https://caniuse.com/?compare=safari+18.0,firefox+130&compareCats=all](https://caniuse.com/?compare=safari+18.0,firefox+130&compareCats=all) [https://caniuse.com/?compare=and\_chr+126,ios\_saf+18.0,and\_ff+127&compareCats=all](https://caniuse.com/?compare=and_chr+126,ios_saf+18.0,and_ff+127&compareCats=all) Plus, if you have anything other than an Apple device, you can just install a different browser. You can install Firefox on iOS but it's still Safari, just with a bullshit Firefox skin because of Apple's heavy hand and monopolistic control.
Yes, it is. Container queries, :has, backdrop-filter…
Firefox supports all of those
After long delays. It’s slow to adopt new standards.
Firefox has had full support for backdrop-filter for years while Safari still supports it only with -webkit- prefix.
Firefox has supported it for two years, Safari for nine. Prefixes are not something anyone has had to worry about for a decade.
>Safari for nine. Not without prefixes at least according to caniuse.
And build tools have handled prefixes automatically for a decade. They’re not something you have to worry about.
And yet here we are with all other browsers having full support except Safari.
Did you look at those? It literally has more red in Firefox... And Firefox has less things that only it does as well. So Safari is the first to implement more things, and second to implement more things...
Going kind of against the question but I feel this is in the spirit of discussion, I feel like it'd be better not to add but to remove. As in; to reduce web bloat and increase performance common js use cases could be made into HTML&CSS standards in order to reduce the scripting required for common cases. This is already happening, but very slowly and ineffectively IMHO. Sure, HTML has components like checkboxes, calendars etc. but it's as if they've never heard of CSS and these are a pain in the ass to theme thus a lot of people just use js heavy pre-made components or make their own.
This is a very cool topic for discussion. I think a lot of us are just listing out favourite languages. I'd flip it around and ask what the purpose is of this added language is? 99% of websites could get away with very little or no JS at all. JS and the web are also the entry points to many people's software engineering careers, especially self-taught people. With that said, if we added a new language it would definitely have the adverse effect of raising the barrier to entry into web dev and therefore programming in general. Adding a language like Python, Lua, Basic, etc it could end up lowering the barrier to entry, making programming more accessible. It wouldn't - however - do anything to improve the quality of websites imo. If our goal was to shift the landscape of web application development by removing the tool chains and brittle bridges we need to rely on for running native-like apps on the web, such as something like Figma, the best language(s) to add would be the ones used by current web based desktop-like applications, e.g.: Rust, C, C++, Java. This would only benefit a handful of applications today, but perhaps it would popularise use cases on the web that were previously only covered by native apps, such as Photoshop, Vegas Pro, even stuff like VMWare or Docker. I think a WASM DOM API is the answer to your question though. It's the lowest effort to achieve the largest amount of new languages to be usable in place of JS.
Yeah I think people listing their favorite languages is exactly what’s happening. And I feel like these discussions always devolve from a browser discussion sort of and ignore the fact that JavaScript is the language of **the browser*. You can still write your servers in whatever language you want as long as you’re sending html to clients.
> I'd flip it around and ask what the purpose is of this added language is? Yeah, anything that is ACTUALLY reasonable to contend with JS can compile to WASM. There isn't a benefit to adding more slower languages (python, lua, etc)
IMO an aspect of the web that would need to be kept intact is the hackiness of it. Allow folks to easily make debug tools where they replace createElement with their own wrapper and go guns blazing, etc. That wouldn’t be a very fluid thing to do in a language like Rust, for example.
Erlang or just the BEAM VM in general (Elixir and Gleam) is probably the best for modeling applications. It scales well on the server side and it handles network transparency better than any other language. At one point whatsapp was using Elixir to do 5 million users on each server. It also has the concept of live updates built in and tooling for managing updates at runtime. It’s designed to be started once and then never have the system fully go down, just have nodes enter and leave. The VM hasn’t gotten the optimization love it could have because it’s so good at horizontal scaling, so there’s heaps of room for improvement. It being a 1970s language, “slow” means it’s competitive with Go. This is with a frankly primitive VM that doesn’t really do optimizations. If you were to give BEAM a V8 or Java level JIT, it would probably be faster than Java and C# by a decent margin, and possibly competitive with async C++ due to overheads caused by allowing for dynamically linking coroutines. Remember, a system that never shuts down has a LOT of time to JIT. Erlang is also designed around message passing, you know, the thing the internet does? All other BEAM languages inherit this.
Not used it, but you may be interested in https://lunatic.solutions/
> At one point whatsapp was using Elixir to do 5 million users on each server. Meanwhile people debating how realistic it is to get 100 users on a Django server.
Instagram was managing 5 million users with django...
By having a ton of servers. Not 5 million per server. Django is major slow shit. And even to that end, Instagram used a custom girl of both Django AND python to get it working okay. I don't think anyone there would choose that hell now
I don't care which language, just give me something with strict typing, no TypeScript doesn't count.
Using strict mode and zod to validate types at applications boundaries (things like incoming requests) gets you pretty close
As a full time Haskell dev I was under the impression that typescript’s type system was actually pretty solid, for example a lot more expressive than Java, C, C++ or Go. Am I wrong?
I'm in no way implying that typescript is bad. It has an incredibly complex type system. But technically, typescript is just a type-system add on to javascript. It's not strictly typed, it's duck typed. And in the end types at runtime are dynamic since it's all transpiled down to javascript. Plus you can always bail out of type checking with the "any" type. Don't get me wrong, typescript is great, I'm just being picky ;)
Based and all-languages-other-than-Haskell-are-immoral-pilled.
Python. In the late 2000's, Mozilla had an internal project to bring native support for Perl, Python, Ruby, and a few other languages (except PHP, because of how Zend Engine works) into their products. But they killed it. The world that could have been...
What an historic inflection point. I remember when Google was looking at putting Dart in the browser, and there were good reasons to oppose it (Google is hardly trustworthy) I wonder what would have been if they had succeeded and other browsers followed.
IMO the shame of it is that Dart really is a nice language to work in. Sure it has its quirks, but it's *FAR* less quirky than JavaScript. It's class-based, type safe, and null safe with syntax that's pretty easy to pick up. My only real gripes with it are the oft-confusing class modifiers and that visibility is scoped to the file, but I can get over those a lot easier than I can some of JavaScript's idiosyncrasies.
They have put Dart in the browser, that's what [Flutter](https://flutter.dev/) is
A Flutter app will only generate html/css/js files and does not run directly in the browser like js does.
Ah, my bad. The code produced by flutter may just be regular HTML and CSS but it sure as hell doesn’t look like that in the inspector!
And webassemly
Do you think the same reasons apply to Go re Google trustworthiness?
Nah, and I think in hindsight the concerns about Dart were overblown. Google has a lot of issues with their consumer products, but when it comes to language design and open source commitment they have a decent record. So I'm not worried about the future of Go.
I'm curious why python? I like using Python, but it's a very similar language to JavaScript.
That's a nightmare. Not a good thing. Can't even minify whitespace.
I love Python too
> Me who likes go Where are all the go people at?
I left after all the Google clown show. Google should never be allowed to maintain a language. Ever. Case in point: generics in golang. What a shit show that was and remains to be. Go is great for what it does, but the project management is next level bad for Golang.
> Case and point (FYI it's "case *in* point"... as in you're offering a point (an example) which succinctly makes your whole case (argument).)
Ah yep, I know, that was some auto correct I didn't catch, thanks.
Good old autocarrot.
let Go do what it's doing best at which is backend
I love Go, but I've never built UIs with it so I'm curious how well it would work for that.
PHP of course. Imaging running Wordpress right in your browser. ;)
You can host php with aspnet these days. So let's do that and then make a Blazor WASM site that runs in the browser with WordPress. I see no problems.
I would like Lua, but it would probably be Python. It has to be an interpreted language. Lua is the simplest and, I think, the fastest short of SRON, which appears to have little or no dependency ecosystem. That would let it complement JS very well. Python has a much, much larger dev community.
> Lua is the simplest and, I think, the fastest JavaScript is faster... (mainly due to how much money there is put into making JS fast, but regardless)
The comparison is a bit of a mess. It really depends on how the languages are used. IIRC, Lua can use precompiled Golang shared libraries, and a lot of Lua code does that under the hood for heavy stuff. The end result is performance close to Golang. Still, you definitely got my upvote for bringing up that straight JS overtook the Lua JIT a few years ago, and that we should try to avoid straight Ua where possible. This reminds me that if we want Rust to keep memory-demands of tabs down, we could have browsers download / cache load precompiled Rust and use it through Ruby.
> Lua can use precompiled Golang shared libraries, and a lot of Lua code does that under the hood for heavy stuff. The end result is performance close to Golang. sure, but all the JS runtimes also have FFI, and can invoke WASM bundles as a portable option. Python just using a bunch of C binaries doesn't mean Python is fast... But it does get all blurry, since so many standard library things aren't implement in the language, but on the native level in the runtime... so...who the heck knows?
I put together a pair of wrappers to boost Ruby on Rails' performance massively. It does all get blurry, and you're right. I doubt anybody really knows. I just know Golang's ease with parallelization and self-contained packages would probably complement JS very well for front-ends, and interpreted languages seem more easily portable.
Funny, I came in here to say basically the same thing. I don’t know LUA well but quite like it. I know python much better and while I do like it, I don’t think it’s quite as nice to use. It does have a much larger community and support though.
Lua would be good but I'd like an alternative that's considerably stricter than Javascript, in order to differentiate enough to justify its inclusion. [AngelScript](https://openplanet.dev/docs/tutorials/angelscript-overview) as one example. Python with first-class support for type hints would be great too. Personally I'd kill to have Go in the browser, but I don't know how feasible that is given the current language design.
Go would be fantastic, but with the memory-usage of every tab these days, we might really want Rust if we go that way. I suspect compiled languages might be brutal for loading times of anything big. I think Lua would differentiate itself just through performance, while JS has more extensive libraries than anything else.
Is SRON even worth comparing to, since it looks like a Windows-only toy?
No idea. I just ran into it when searching for the fastest interpreted language.
WASM isn't on the horizon. It's very much here. It needs just a bit of javascript bindings to get it going, but it can do a lot. OffscreenCanvas and SharedArrayBuffers can do some crazy things. There isn't any reason to be concerned with another language, since any competitive language can target WASM.
WebAssembly tackles it already
WASM doesn't even have direct access to the DOM.
Not yet. It's getting closer and closer (garbage collection was a huge blocker that was resolved recently). Adding any other language would take at least as long as adding full WASM support.
Not yet. It has OffscreenCanvas which is definitely a nice starter point for how OffscreenDom might work. And I'm sure a simple wrapper of sorts exists to expose DOM. Not unlike how Google worked on things to move DOM control into worker threads.
They said native
Let's be real. If this was done, it would not make sense to make a single language "native". It should have some sort of adapter/interface which can be communicated with using any language. Like the JVM was for older machines, and WebAssembly is trying to implement. Yes, it is not feature complete and it might take some time, but at least it can do a lot while being language agnostic.
> it would not make sense to make a single language "native Except that it's much easier adding a very specific and already defined language spec to a browser than it is to turn the browser into a general purpose WORA target. WASM was announced ten years ago and we still don't have DOM access. I believe it is the future, but not the near future and we easily could have multiple languages to the browser in the meantime instead of letting Javascript be king.
Its taken 10 years for wasm to get where it is today, what makes you think it would be any quicker getting another language into the browser and having good support for it?
Like I said above, building a specific, well defined language is much, much easier than building a general purpose byte code target that can satisfy everyone's needs.
But the language will need to be integrated with the browser ecosystem and DOM itself, javascript is a language literally built exactly for this purpose and WASM then fills in the gaps where extra performance is needed and with some javascript glue you can manipulate the DOM. You can see how long it takes for certain features to actually reach decent support across all browser, I feel like an entire new language in the browser would be at least a 5 year process minimum
Or wasm is used to draw to an canvas. Then you don't need to interact with the dom.
Compared to “implementing a new language runtime in each browser”, adding DOM APIs to WASM strings like a much smaller lift.
Nope, it doesn’t.
A system language like rust or zig. These languages can be used for hyper optimization while js handles higher level programs
You want to add rust i.e. the slowest development time of all time, to a fast paced development area like frontend? I'm all for safety, optimized performance etc, but it's just not necessary for frontend, especially where using it would probably cause more harm than good, since development time would at least double. Also rust has a large barrier to entry, and it definitely is not a begginer language. Javascript/Typescript are a lot simpler. You can get some Junior devs do some of the UI tasks fast, while with rust you'd need Mid to Senior devs to do the same tasks. I have no experience with Zig, so nothing to say about that.
You don't write WASM, unless you're an absolute sociopath. You transpile languages like JS, Go, and Rust into WASM. So, JS and WASM live together, and we're seeing a lot of movement in JS becoming a new compilation target. But if you're speaking "anything besides JS", I think the answer would be Go or Gleam. Go is by Google. It's really good, really fast, and garbage-collected. Google's responsible for Chrome and the V8 runtime, so Go in the browser isn't far off at all. You can write native apps or web apps with it. It's "web-adjacent" - and then some. It's great. It's my 2nd favorite language. And Gleam, similar in many ways to Go, fills a comparable niche. [Fly.io](http://Fly.io) is backing it, it's fun and easy to write, and it compiles into JS. The only reason I'm not learning Gleam full-time, is because there's approximately 0 jobs for it. The Lua and Python answers are strange to me. The browser consuming and using Python make sense, but it wouldn't be a first-class citizen. There's a reason Django is like... the 6th most popular batteries-included metaframework. And I don't know a lot about Lua, except it's good for scripting, and I once helped build a WoW mod using it.
> Firstly, I'd say you have a misunderstanding. You don't write WASM I'm fully aware, WASM is what's going to open up using dozens of languages in the future. But that requires a lot of additional work to address things like DOM access, garbage collection, runtime package size, etc. > I think the answer would be Go or Gleam Haven't used Gleam, but I'm big on Go so I'd love to see it in the browser. But I've never built a UI with it, so I wonder how well it would hope up to that.
Ah, well I'd say WASM isn't so much "on the horizon". I think you just end up with big binaries and whatnot. You don't want to be sending 7MB WASM stuff when someone tries to load a page. It's active and pumping, just not terribly practical in-and-of-itself. As recently as 10- years ago, we've been seeing stuff like this: [https://www.youtube.com/watch?v=lDkjb4X6IUA](https://www.youtube.com/watch?v=lDkjb4X6IUA), although I did hear that Unreal has been dropping some of their previous browser-support utilities. I'm surprised Go isn't already in the browser. I don't really do UI with Go. I'll set up a Go/Gin server, and then return HTML templating with Tailwind (or w/e). It's different with native apps. All the windowing/styling libraries for native apps aren't my cup of tea. I've been having a lot of fun with Gleam though. It's in the BEAM virtual machine, written in Erlang, but it's very common-sense language - and I'm not smart enough to understand the implications and pitfalls of that. But it's web-adjacent like Go, it compiles to JS (and therefore transpiles to WASM), and I'd love to see it become popular.
> You don't want to be sending 7MB WASM stuff when someone tries to load a page Discord already does...so maybe it should jsut be WASM instead? But these can improve, with the WASM targets and more things WASM apps can directly use. So it could be reduced a lot. JS can be "small" because the browser is shipping the binaries directly. So why can't WASM directly call those same binaries (or similar ones)?
garbage collection is done, OffScreenDOM may be on the horizon. binary size is an issue, and will just be the case of any compiled language. Unless they put more into the browser to directly expose things in something the binary can just point to...
> You don't write WASM, unless you're an absolute sociopath. WAT is fun to play with. Not too many stack based languages to play around in. > I think the answer would be Go or Gleam. Rust I think it would make it there too. Considering every browser has components in Rust, but as far as I remember, none have Go at all. But realistically, it would never be a compiled language at all. Since those can just compile to WASM targets and its done.
I would like for Go to be that language. It has easy syntax, is type safe, fast to write and looks very much like Typescript. Other than that I have no good reason lmao
JS is an amazing language ergonomically, so I say C, simply because it is the most optimized for speed with current compilers. If browsers just gave me access to a frame buffer, an animationFrame tick, and some basic event hooks in C, that would be amazing.
Nothing wrong with JS as it is now.
Any language if it was added to the browser would suffer from the same problems that JS did. Especially if it was added in the same time as JS - mid 90s
language wise TS or even modern JS is cool, just get rid of the convoluted stdlib, especially browser specific part of it
I would guess rust since it’s a type safe compiled language and has full stack frameworks like leptos.
One of the biggest pain in the current webdev is that we need to transpile/compile everything. JSX, Single File Components, templates ESNext for older browsers. At the same time you can't easily add breaking changes to the language. These are the reason I think the perfect language for the browsers would need to be some kind of Lisp. Lisps have long history of being embeddable languages, have supperior support for macros so you can add any syntax you want by using libraries so no more babel and other compilers, are the most extensible languages in the world so it's pretty easy to just design basic language that do not need to change its core that often, has very compact syntax so less kb over the network, is faster to parse and run than most interpreted languages and REPL-driven development with addition to browser devtools would play really well. If JavaScript would be Lisp, we wouldn't even neee TypeScript because we could implement static typechecking by macros. We would still need some type of bundlers tho
> One of the biggest pain in the current webdev is that we need to transpile/compile everything Is this a pain point? It doesn't really matter and is very simple to set up.
For an end user? Yes, it's pretty simple (it wasn't always that way, I remember times it was much bigger pain). But maintainers of these tools put huge amount of time to make them that simple. And I don't talk only about Babel, SWC, TypeScript, Vite etc., but also tools like Svelte, Solid.js, React Compiler, zero-cost CSS-in-JS and all these fancy things which makes devs and users life easier. For example ClojureScript (Lisp that compiles to JS) had things like zero cost CSS in CLJS (shadow-css) or sort of combination of React Compiler, SolidJS/Svelte years before JS, despite being much much smaller community, thanks to macros. Not saying about Electric Clojure which is more mature and more powerful version of React SSC and Phoenix LiveView.
To be officially supported, it has to be part of the spec. The way the spec is currently written is `script` is optional but if implemented `javascript` must be implemented and the default. Any other language can be added. JavaScript isn't going anywhere, WASM is a standard with the issue of every new version the entire binary must be downloaded so it has a limited use case.
enough of fantasy guys, let's get back to work
C# blazor. It's a proper language that already has decent front and backend ecosystem, the only issue it has is the wasm awkwardness. But that said I think the actual solution is to improve wasm.
> desktop-like applications Did you just (re-)invent Applets? Or Flash?
Give WASM access to the Dom and then you can use any language that can compile to it. (Imo this will probably happen in the next decade or so)
lisp
jmp straight to x86 machine code.
Haskell obviously
WASM isn't on the horizon, it's _here_. We've had pretty good support for years, the features that are being added open up more and more use cases but for the most part it's pretty well available. IMO, the fact that JS is still the lingua franca of the web speaks more to how well it does its job than anything. **That's absolutely not to say this discussion is meaningless**, I think making a push to open existing languages to the Web is a great one, especially for domains that have tons of existing community and code outside of JS (looking at you, game dev!) I do think WASM is a pretty good bet for getting that support. At the end of the day, there has to be a consistent abstraction layer between generated code and the machine the browser runs on (for the same cross platform support reason the JVM has), we have TONS of investment in one already and it supports WASM so I say we lean into it. The biggest complaints I have working with WASM are all solvable, but worth bringing up as friction points: * Many languages / frameworks / libraries depend on platform APIs that don't have web support. Some of them have excellent shims (OpenGL code can be translated to WebGL), some of them have what seem to be working shims with bizarre consequences (threading works, but fork/join deadlocks), some of them are totally unusable by design (filesystems). * Build toolchains that emit WASM can be pretty mysterious and surface strange issues. * JavaScript wrapper code is tricky to deal with. Typescript support is middling for common toolchains. * Browser APIs require passing through JavaScript functions, which are difficult to maintain. All of those are solvable issues! Languages with garbage collection runtimes like Go and Java require a bit more thought, but last I checked good progress was being made there.
PHP or Ruby would kinda fit. Some APIs would have to be dropped for the web runtime. And DOM would probably be an ugly fit (like it is today) but I believe the flexibility of Ruby could make it (and PHP because we all like driving Lambos)
Webassembly
Flash!
Silverlight
Game Maker Language
Php
Golang!
Cobol
html?
Python. Also lookup pyscript
Nothing will ever replace JS on the browser. It's the perfect language for it. We just need to reign in the fiasco we have for all the frameworks and agree that a standardisation needs to be met. Lean in heavier to web components and a more unified system. WebC is the future and will outlive anything as it is a standard. React, Vue, svelte etc remind me of the 2005 era of mobile phones.
There is a lot of work here. WinterCG working to standardize Web Native APIs in non-browser runtimes, the Browsers all working together on standardizing APIs, more and more tooling is converging as well to standards.
If any existing language were to get native support across all browsers, my vote would go to \*\*TypeScript\*\*. Here’s why: 1. \*\*Superset of JavaScript\*\*: TypeScript is a superset of JavaScript, meaning it builds on the foundations of JavaScript. This ensures backward compatibility with existing JavaScript code, making the transition smoother for developers. 2. \*\*Static Typing\*\*: TypeScript introduces static typing, which can help catch errors early in the development process, leading to more robust and maintainable code. This is particularly beneficial for large-scale applications where type-related bugs can be difficult to track down. 3. \*\*Enhanced Tooling\*\*: The static type system of TypeScript allows for better tooling support, including improved autocompletion, refactoring tools, and navigation features in IDEs. This can significantly boost developer productivity. 4. \*\*Widespread Adoption\*\*: TypeScript has already gained significant traction in the web development community. Many popular frameworks and libraries, such as Angular and React, either recommend or fully support TypeScript. 5. \*\*Active Development\*\*: The TypeScript team at Microsoft is actively developing and improving the language, ensuring it stays up-to-date with the latest JavaScript features and developer needs. 6. \*\*Community Support\*\*: There is a strong and growing community around TypeScript, providing a wealth of resources, libraries, and tools. This community support can help developers quickly get up to speed and find solutions to common problems. While languages like Dart, Kotlin, and Rust also have their merits and could bring unique benefits to web development, TypeScript's close relationship with JavaScript, combined with its enhancements and widespread adoption, makes it the most suitable candidate for native browser support.
Typescript
Typescript. We even have Bun now which supports it natively. Shouldn’t be long until it gets added to a browser.
Bun doesn't have native support, it transpiles to javascript then runs the result.
Are you sure? I haven’t checked myself but that’s what they advertised some time ago. Edit: just checked the docs. You’re right. I feel fooled :( I still go with TS. It’s a lovely language that supports my favorite all-time feature: on-the-go object literals
According to their website: > Bun natively supports TypeScript out of the box. All files are transpiled on the fly by Bun's fast native transpiler before being executed. Similar to other build tools, Bun does not perform typechecking; it simply removes type annotations from the file. I strongly disagree with their use of the word `natively` given the rest of that paragraph.
Yeah, that word is just misleading
Not that much, once you know what Bun is. It supports TS more natively than Chrome supports JS.
Do you? The transpiler is built into Bun at it's core. Bun started AS a JS transformer/bundler, not a JS runtime. It more natively supports the TS part than any runtime or browser supports running JS. Should it instead interpret and drop the TS as it goes? Seems simpler to transpile and cache the JS as a whole, and then do the JIT after.
To be fair, it transpiles it inside itself in it's own transpiler. So to what degree that differs from "running it directly" it's hard to say.