The incumbent is not C, it is JavaScript. Initially JavaScript was also simply run on an interpreter. And it wasn't particularly fast until it got considerable attention by Google & Co, and browsers competing for "who can run this silly JavaScript benchmark the fastest".
Then complaining about how more abstract languages like Python are inefficient compared to C is not fair. These calls to range and Exception handlers are there on purpose, to help the developer avoid writing boilerplate code for the millionth time, and focusing on the problem itself, writing cool things.
C would be a terrible language for the Web I would argue. Web "development" was never a thing for the greybeards and "I dream in assembler"-types (not that I want to exclude anyone, I mean it didn't attract that crowd and another instead). Any challenger for JavaScript must be approachable, easy to understand, easy to write and read. Easy to fix and modify (most "Web Apps" are already obsolete the moment they hit deployment).
Heck, why not go full x86 instructions? Hm, then there are millions of iPhones and Androids on the Web that are not x86... Write our own Assembler?! Let's call it WebAssembly!
Oh, wait.
For example, JS has no classes and uses prototype inheritance, and you can even change prototype at runtime. This is absolutely useless, inconvenient feature and it makes optimization (like JIT compilation) much more difficult (for example, before calling a method you must ensure that the prototype didn't change, the method was not replaced and so on).
In 95% (arbitrary number) of cases you just need classes with a fixed set of fields and methods known at compile time, which is very optimizer-friendly.
On the opposite: not only it isn't unfair, it's absolutely necessary. Over the years we witnessed the birth of so many languages, and each of them promised to be more safe than C while keeping performance "close to C". Now we have a cornucopia of programming languages, many of them are definitely "safer" than C (in the sense that it is more difficult or impossible to create some types of errors like buffer overflows), but in terms of performance there still seems to be a considerable gap. Having bad performance is bad for the users, bad for the environment (in terms of direct energy consumption and more power-hungry hardware needed), and bad for software companies (who are limited in what they can do).
Hacker News is written in some Lisp, and I spend more time here than on any bloated SPA.
Reddit with the old UI is a close second.
Also, C and Lisp are different breeds. It’s wrong to put them in one bucket of “greybeard” languages. Some Lisps gained traction in the front end space (see ClojureScript).
JS got fast because Google and friends started an arms race on it, since the adoption scale justified pouring resources into optimizing efforts.
Python has a large amount of developers' mindshare, which makes its use in the browser potentially worthwhile for large interests invested in the ecosystem (e.g. Anaconda). However, the problem is so big that the cost/benefit ratio for any given group that would want to tackle it, is still fundamentally unattractive. Python developers are legion, but still not a patch on JS users.
This is where WASM is a potential game-changer: by effectively dividing the problem in two and sharing the load for the first half with a lot of other ecosystems, the cost/benefit calculation improves significantly enough that commercial interests seem more willing to invest. CPython speeds, after the temporary v3 setback, get better and better every year; likewise WASM speeds. If their coupling becomes normal, enough effort will go into it that this consideration will just go away.
Also, it is unlikely that compiling to WASM will be more effective than to native code because browser cannot afford spending as much time on optimization as a native compiler. Therefore WASM will always be slower than a native code.
If you want to benefit from amazing optimizations that were done for JS, then it is better to transpile your Python code directly into JS.
No, but the bytecode gets better and more efficient with new releases. The point at which it becomes acceptable depends on the use case, of course.
> it is unlikely that compiling to WASM will be more effective than to native code
It doesn't have to be more effective, it only has to reach a point where the penalty is worth paying. After all, JS is slower than C, but you accept that as a part of larger trade-offs on manpower, ease of deployment, etc. Once the trade-off becomes acceptable for the use case, absolute benchmarks stop being relevant.
> If you want to benefit from amazing optimizations that were done for JS, then it is better to transpile your Python code directly into JS.
Why stop there? At that point you might as well use JS, since you get the best speeds and chances are you'll have to deal with it anyway at some point. There are already solutions like that out there, and they are not popular precisely for that reason. The beauty of using WASM is that you'll probably never have to touch JS.
No reason whatever compiles the code to wasm can’t perform all the expensive optimizations and the wasm execution environment just runs it.
In fact, I would be very disappointed in a tool that didn’t run optimization passes over the code while it still had the language specific information to inform the optimizer.
Then you just pass the multi-megabyte wasm payload over to the browser to render your static content — all’s still good in the webdev world.
[1] https://en.wikipedia.org/wiki/Dart_(programming_language)#Hi...
At this point the main issue I've seen is the slow load time (not a problem for jupyterlite but is for pyscript). Hopefully this can improve with time and regardless I think there are a lot of cases for pyscript to remove the need for server-side code and the associated maintaince.
We added support for PyScript using Collagraph, which allows you to define single file components with a Vue-like syntax.
Excerpt from the project README:
Write your Python interfaces in a declarative manner with plain render functions, component classes or even single-file components using Vue-like syntax, but with Python!
- Reactivity (made possible by leveraging observ)
- Function components
- Class components with local state and life-cycle methods/hooks
-Single-file components with Vue-like syntax (.cgx files)
- Custom renderers (PySide, pygfx and now PyScript)
Talking about optimizing a range(10) loop was valid in the 90's, not today
Yes, CPython could be better, but there's Pypy. And still, CPython runs circles around the optimized Dart example you gave.
"pay a little attention to performance" cool, are we going to take all the crap out of JS that makes it inefficient?
"pay a little attention to performance" sounds to me like you're a fan of those C compilers that break code on purpose because the developer forgot some arcane detail. To what I call BS
Of course if you are writing an internal app and can provide M2 MacBook to every employee, then it is totally fine. But if you are writing applications for wide audience, it is a different thing.
I remember that one of early users of Vkontakte (a Russian clone of Facebook) was impressed that the site was loading fast on his old computer. As I remember, its JS code was written in vanilla JS without libraries like jQuery. Today the hardware is better, but if you will run SQLAlchemy in a browser to save development cost, your site's loading time won't impress users.
> your site's loading time won't impress users.
Anybody who used client-server apps in the 80s and 90s is not impressed by browser-based apps either. Those expectations can be managed in so many ways.
Yes that will be a complete non starter!
I'm all for fighting inefficiencies and slow code, but fixing things like this, or Redux etc go much further than a simple for i in range() loop in Python
Anything written to be performant is immediately noticeable - things just happen when you click a button. Dev time > runtime, but I’d argue some runtimes are so slow they begin to eat into user time too.
I can only imagine how many people will just close the tab and move to next search result.
Python is not a fast language. For example, consider a simple loop:
In Python, this will be compiled into: a call to range(), heap allocation of an Iterable, calling getIterator() on an Iterable (which might also do allocation), calling next() on an Iterator while catching for StopIteration exception (and calls are often slow in interpreted languages). While in C we could just have a loop without any calls.I remember how I had to use a Dart-based web application (compiled to JS) in one of Google's advertising products. The script weighed around several megabytes and everything was so slow. Furthermore, there also was a small and useless "what's new" applet, and it probably was shipped with a separate copy of Dart runtime because it weighed several megabytes too. Obviously this was a product intended to be used only on latest MacBooks, not on a Windows XP laptop.
It is totally fine to write such application for youself, or maybe for internal use, but if you are a corporation with millions of users, I think you should pay a little attention to performance and choose a better technology. Or, if you are of a Google scale, find a way to optimize the code.