Hacker News Reader

Comment by dkarapetyan | Hacker News Reader

Ladies and gentlemen we already have TypeScript, Dart, clojurescript, scalajs, coffeescript, PureScript, elm, etc. More innovation in the web language ecosystem is not what is lacking. What is lacking is all the boring stuff like a sensible package management system, deployment mechanism, framework interoperability, etc. You know, all the un-sexy stuff that actual engineering requires.

View on HN

What we really need is a replacement for Javascript as the 'bytecode of the internet'. It's clear now that people want to have the freedom to write client web code in whatever language they prefer. A web browser is just a VM for running the output of a [dart, coffeescript, scala...] compiler, and we should recognise that, and replace javascript (a language designed for humans to write) with a new bytecode (a language designed for computers to run), and then people can use whatever compilers they want to translate from the code they write to the code the user runs.

People can still write javascript with a JS->Bytecode compiler; people who want to write TypeScript or Dart can get better compilation or performance, and people can easily write a whole load of new languages and new compilers without being constrained by the intricacies and design decisions of Javascript.

I'll take "Subsets of Javascript by Mozilla" for $200, Alex

I think asm.js has proven itself to be a "good enough" solution if we start writing some serious compiler tech

I didn't mention asm.js but it was on my mind when I wrote the parent; it's possible that it is 'good enough' and eventually becomes widely adopted enough, but I wonder if we might do better by eschewing the need for compatibility with Javascript.

We might but first someone has to first design and specify the new Intermediate Language. Then submit it to ECMA. Then implement it in a browser.

This new IR better be so much better than JavaScript and asm.js at being a compile target for languages, that it takes no time for web application developers and compiler developers support it with enough tools and applications to dwarf their JavaScript counterparts. Good luck with that.

Yes, and please let this 'bytecode' actually be that used in CLI assemblies. In other words, can we have a .NET runtime in the browser please?

All that Javascript will continue to run beautifully, but I'll be able to write C# or Ruby, and those who favour other languages will likely be able to write them too, as there are so many supported.

I think in most cases, a bytecode solution would just be inserting another runtime layer between JS and hardware. It'd be a rough couple years of transition to get speed back, and not to mention the years spent trying to get everyone to agree to a standard.

Sadly, JavaScript may very well be our bytecode. Unless by some miracle one of the intended JS replacements actually takes off.

Currently each browser implements JS compilation different. Some compile to a bytecode, and others do not. Getting them to agree on a single bytecode format is very unlikely.

I can't help but be confused by the point of your comment (not trying to sound mean).

Are you saying that he (we?) shouldn't be developing new languages, and instead focus on "things that matter"? Ie, don't work on what you want to work on, work on what is useful to others / "solves real problems"?

I mean, that statement, while very useful at heart, seems ultimately close minded to me. It chips away at the soul of trying something new, or doing something fun.

I mean, i don't think anyone would argue that we need more languages, but i would (and am, apparently) argue against the idea that we shouldn't be creating new languages because we don't "need" them. Not everything should be industry scale and immediately applicable to professional needs.

New for the sake of being new is not engineering, it's fashion. Programming fundamentally is a problem solving discipline which means the tools I adopt and use at the end of the day are about augmenting my ability to solve new and novel problems instead of spinning my wheels in place and re-writing yet another old library in the new language du jour. The JavaScript framework/application ecosystem could use less fashion and more engineering.

That doesn't mean I don't think that spider is cool. In fact the list of language features is really well thought out.

> Ladies and gentlemen we already have NPM, Bower, Component, Duo, Jam, etc. More package management systems are not what is lacking. What is lacking ...

I find your comment to be snide, ungrateful and most of all uninformed. Personally I think new programming languages are interesting, despite how widely they might or might not end up being used, if they present new ideas, or solve difficult problems. Spider seems to solve a few Javascript problems and does so with a different approach to the other languages you listed.

You forgot jspm.io. So are you enjoying having all those choices and each one being subtly incompatible with all the others? Let me know how your next spider project turns out and how it interoperates with all the existing code written in coffeescript, typescript, dart, vanilla js, etc.

Well you may want to read this link which may address your first complaint existing languages.

  http://spiderlang.org/#why-spider

I think package management is well handled by npm on node and browserify on the browser.

projects like grunt make deployment a piece of cake.

framework interoperability is just like in any other language, it's up to individual library maintainers. Personally I've rarely had issues with interoperability. On the plus side I think on that same link you'll find that Spider works happily interops with vanilla js.

One way we could look at it is this; all these languages mean there is an option for everyone. I think if you look at the list of langs you mentioned (throw in vanilla js as well) you will find one that really speaks to you.

I have to disagree on principle and yet agree. This looks a lot better than the other options and I really hope it catches on. However, I can't really use it until it catches on, because I need all this "other" stuff to be done before I can use it in my projects.

Actually, this looks like it hits a sweet spot (for my taste at least) that none of the others really quite do.

Ironically, I've now filed this in my head as something to look at when adding a web UI to some package management and deployment code I'm working on :)

I disagree. There's still lacking a good compile-to-JS language that works well in the current library ecosystem (ruling out scalajs and fay) and has ADTs and good static typing.

LOL. So basically "I want X, but languages which give me X are excluded, because that would hurt my claim"?

Especially compared to Scala.js and Fay, I don't see the point of going backward to a slightly improved JavaScript again.

You mean PureScript?

Note that Spider comes _from_ an actual engineering requirement. http://spiderlang.org/#why-spider

Please don't take my comment as dismissive of your work. I think it's really cool and the list of language features is quite impressive. I only disagree with the dynamic typing statement. Both TypeScript and AtScript are optionally/gradually typed which means your code can be as dynamically typed as you want it to be so you still retain the benefits of dynamic types. For some the backwards compatibility might be an issue but I personally like the fact that any JavaScript code is automatically valid TypeScript code that I can easily migrate to use more and more TypeScript features.

Reply on news.ycombinator.com