
ThinScript, an experimental programming language that can compile to WebAssembly - pjmlp
https://github.com/evanw/thinscript
======
oblio
I'm partially worried about WebAssembly. On one hand it opens up new
possibilities... on the other hand, due to backwards compatibility I think
that the future will look like this:

\- 1 browser tab: Java runtime environment compiled to WebAssembly, loaded by
some sort of enterprise app I'll have to use at work

\- another browser tab: .NET BCL compiled to WebAssembly, loaded by another
sort of enterprise app I'll have to use at work

\- yet another browser tab: some sort of other C/C++ runtime compiled to
WebAssembly, loaded by fancy site, let's call it XMail

\- and yet another browser tab: another C/C++ runtime loaded by another fancy
site, let's call it Ywitch

\- a million other tabs with Javascript frameworks

From a certain point of view diversity is good, on the other hand there's so
much fragmentation. One of the dreams when computers appeared was that
programmers will build libraries that everyone will use and people would just
build on top of these libraries, reaching ever higher.

Instead, we have I don't know how many re-implementations of things in various
incompatible/slightly incompatible languages. And that's just for OSS,
nevermind the billion proprietary re-implementations.

Truly the Tower of Babel.

As bad as Javascript is generally considered, from this philosophical point of
view at least we seemed to be on the right track...

~~~
ryanbrunner
The thing is, at the end of the day, the language used to develop the site
should be completely irrelevant for the user. You're not using Java or .NET to
run your site, you're running WebAssembly. The tools used to generate that
should be as irrelevant as whether someone used Gimp or Photoshop to create
the images on the site that you're using.

Bloat is always a concern, but I don't see how WebAssembly materially changes
things - as it stands right now, you're downloading the "runtime" for
virtually every site you use in the form of a javascript bundle packaging up
every library used to make a site function.

~~~
oblio
I think it will be much worse. Want to bet that there will be checklists and
sales pitches on development tools websites where the likes of Microsoft,
Oracle, Borland (Embarcadero?) will sell developers the possibility to build
apps for the web using their runtimes, which will be 100% forklifted to the
Web?

As-in, share-nothing, just their existing libraries cross compiled to
WebAssembly.

And we will have to use those apps because we will need them for specific
purposes (the typical example is enterprise apps, but also government sites,
educational sites, etc.)

~~~
ryanbrunner
I'm sure that there's going to be inefficient, bloated libraries out there.
That's really no different than the Javascript world today. But as time goes
on, I believe the more efficient libraries, frameworks and tools will win out.
No one uses jQuery UI or Sproutcore these days. The same will be true of any
bloated monstrosity that is compiled to WebAssembly.

~~~
shakna
> But as time goes on, I believe the more efficient libraries, frameworks and
> tools will win out.

The average webpage today weighs in at 2.5mb. I don't think that demonstrates
an efficiency win over time.

~~~
mikewhy
Curious as to if that includes images, or if it's just JS/CSS.

~~~
ry_ry
Probably includes images, although Universal apps tend to end up with a bunch
of JSON embedded in the page, quasi-unique BEM style classes on everything you
might conceivably want to style will bulk out the html more than strictly
necessary too, Babel makes some pretty damn ugly ES5 in certain circumstances,
and poorly nested SASS produces some travesties, so it might just be a
cumulative effect.

In truth, I'm not really sure what constitutes an average webpage, or even if
the quoted number is after gzipped assets are unpacked by the client.

Would be interested to see where that number comes from though.

~~~
shakna
Ronan Cronin is the original source [0]. Lots of news outlets picked up the
story at the time. The data comes from httparchive, you can grab a breakdown
here. [1]

Videos and JPGs are the worst offenders, but PNG and JS nearly tie for third
in page weight. Though I _think_ it isn't measuring gzip, but raw bytes, which
changes it up a little.

[0] [https://mobiforge.com/research-analysis/the-web-is-
doom](https://mobiforge.com/research-analysis/the-web-is-doom)

[1]
[http://www.httparchive.org/interesting.php?a=All&l=Apr%201%2...](http://www.httparchive.org/interesting.php?a=All&l=Apr%201%202016)

------
pselbert
The most recent open issue is from 6 months ago and posits whether the project
is still active. It definitely feels "experimental", but a bit outdated
already.

~~~
xigency
I've been following this project from the beginning and it is not active but
there is an active fork being developed called TurboScript:

[https://github.com/01alchemist/turboscript](https://github.com/01alchemist/turboscript)

ThinScript was very impressive because it was put together in a short amount
of time to show a language that could compile to either JavaScript or web
assembly.

------
mvindahl
The question is if WASM is really meant to be a compile target for anything
resembling Javascript, or indeed of any language implementing garbage
collection. And yeah, I know that there are proposals to include GC in WASM.
And yeah, I know that a lot of people would love to program at the high
abstraction level of JavaScript, only faster. Thing is, Javascript runtimes
are already highly optimized at running Javascript type code. I think to
really get faster, we'd have to face the tradeoffs.

The main tradeoff, IMHO, is memory management. If you go full OO with a lot of
object allocations, and with a garbage collector picking up the litter in the
background, then you will be freed to focus upon business logic and your
development will move faster. If you manage memory yourself, C style, then you
are in for a world of pitfalls and potential pain, but you can make your
algorithms tighter and faster. What to pick depends upon your priorites.
Postgres is written in C, for speed. A lot of modern web apps are written in
full stack Javascript, for agility.

I envision the future of web assembly not as a compile target for your entire
codebase, but as a way to optimize the tight loops and algorithms that do the
heavy lifting, but leave the rest of the web application as Javascript. Also I
think that once you go down that road, you have deliberately picked speed over
convenience with respect to the methods in question.

The way that it's going to work, I think, is not by having a Javascript-type
language compile into WASM, but by having a more low level language which
easily compiles to WASM, but which also compiles to (slower) Javascript to
support older browsers.

But what do I know ..

------
amelius
Nice, but I'd rather see existing languages compiled to WASM. Such as C++,
OCaml, Haskell, CPython, Rust, ...

~~~
tom_mellior
Did you try looking? LLVM has a WebAssembly backend, so things that can be
compiled with LLVM (from your list, at least C++ and Rust) can be compiled to
WebAssembly as well. See a guide here:
[https://gist.github.com/yurydelendik/4eeff8248aeb14ce763e](https://gist.github.com/yurydelendik/4eeff8248aeb14ce763e)

I haven't tried it; let us know how it went! Not sure how many hoops you have
to jump through to compile the languages' standard libraries.

~~~
pjmlp
Haskell has a LLVM backend as well.

------
noway421
Half of the c output seems to be unicode boilerplate. Should there have been
unicode to begin with? I guess they are going the way of go, but wonder
whether they would take other useful "high level" features like concurrency
handling and gc, if they started looking that way.

