Hacker News Reader

Comment by Herald_MJ | Hacker News Reader

No, it's not, and it's certainly not OK. Javascript is a quirky interpreted scripting language created for scripting minor workflow events. It's an afterthought by Netscape, duct-taped to a bundle of silly hacks, wrapped up in some interesting attempts to standardise, with a few more vendor-specific hacks crowbarred in there for good measure. asm.js is one more hack on top of the mess, and while it's technically interesting, and probably very useful (much like the rest of javascript), we shouldn't be building these monstrous feats of engineering on top of such shaky foundations.

> there's only one language that works everywhere without installation or trouble and that's JavaScript.

This is true. But we've arrived at this situation virtually by chance, and it's a huge mess and we shouldn't be readily accepting it. We need a real bytecode for the web, we need it to be standardised and we need to push for browsers to support it. NaCl seems to be the furthest down the road to this objective so far.

View on HN

> duct-taped to a bundle of silly hacks, wrapped up in some interesting attempts to standardise, with a few more vendor-specific hacks crowbarred in there for good measure

By this point you could easily have been confused for someone describing amd64 (nee ia32, nee Pentium, i486, i386, 80286, 8088, 8080, 4004.. circa 1971).

Just as we still have a perplexing set of registers and operations that happen to encode efficiently on this ubiquitous architecture due to their suitability to application in our distant ancestors' desktop calculators (binary-coded decimal, anyone?), no matter what kind of cleanliness you're alluding to existing in proposed alternatives that you might hope supplant Javascript.. in 40 years it'll look just as stale and nasty as x86 and Javascript do today.

Not least PNaCl, where last I checked they were busy trying to shoehorn an architecture-specific binary format (bitcode) into something that might run on multiple machines. If that's not enough for you, the original NaCl relied on a vestigial 80286-specific hack (segmentation) that was finally removed in amd64. It's turtles all the way down.

> By this point you could easily have been confused for someone describing amd64 (nee ia32, nee Pentium, i486, i386, 80286, 8088, 8080, 4004.. circa 1971).

He said "We need a real bytecode for the web" not some architecture-specific machine language like x86 et al.

LLVM or JVM are examples of bytecode. They're highly portable (at least the JVM is), and they're not the mess that practically any real hardware instruction set is.

> last I checked they were busy trying to shoehorn an architecture-specific binary format (bitcode) into something that might run on multiple machines

The bitcode you're referring to is LLVM. It's an architecture-independent assembly that can be used to target most major real ISAs. For instance, the Clang compilers use LLVM as their backend. Any programming language designer could use LLVM and instantly (and easily) be able to generate native code for who knows how many different architectures.

So I think the parent poster was right in what he/she said.

> He said "We need a real bytecode for the web

That's what I was talking about, too. Since processors have essentially plateaued in performance improvements by increasing raw clock speed, the only growth options going forward are wider designs – increasingly unorthodox features (e.g. hardware-assisted TM) for which there is no historical precedent.

I'm further hinting that no matter what utterly ideal format we pick, not 40 years from now.. perhaps not 10, perhaps not even 36 months time, some market participant will drop an architectural feature that completely obliterates contemporary thinking about what such an ideal format should look like. And once again we're back to x86-level cleanliness.

So why take the penalty of a brand new mostly incompatible design when non-delusional incremental improvements would have got us there anyway..

> The bitcode you're referring to is LLVM. It's an architecture-independent assembly that can be used to target most major real ISAs

http://thread.gmane.org/gmane.comp.compilers.llvm.devel/4376...

Lars Bak and Kasper Lund (Hotspot, V8, Dart VM) discus the problems with a bytecode VM here starting at about 30:45

http://javascriptjabber.com/008-jsj-v8-and-dart-with-lars-ba...

> The bitcode you're referring to is LLVM. It's an architecture-independent assembly

It is abstracted over specific CPU instructions, but is not portable and not intended to be. It can contain CPU and OS-specific patterns.

It is possible to convert LLVM bytecode into something portable though, or at least a subset of it. That is sort of what Emscripten and PNaCl do.

Javascript is not just a "quirky scripting language for minor workflow events." It is a powerful, expressive language, that has many benefits over contemporary languages, regardless of setting. Yes, it has quirks, and yes, there are some things that coming from another language are difficult to grasp, but it is not a Bad Language.

The fact that Node.js, Javascript on the server, is gaining so much popularity in the developer community means that it has benefits beyond its universality in the browser.

Asm.js is not a "hack on the top of the mess", it's a simplification of "the mess" down to it's simplest, most bytecode-esque parts. And it's performance is shockingly close to Native.

Javascript is not the perfect bytecode for the web. But it does work as a bytecode for the web, and with asm.js, it seems that it works decently well. I think efforts are better spent improving Javascript, asm.js, and languages that can target it rather than swimming upstream.

> Javascript is not just a "quirky scripting language for minor workflow events." It is a powerful, expressive language

I didn't say it was just for minor workflow events, I said it was created for minor workflow events - it's just good fortune that Brendan Eich was an experienced language designer and created something that was powerful and extendable enough to bring us to the situation Javascript is in today.

It's certainly powerful (particularly considering it's original intentions), I disagree that it's expressive in comparison to other modern languages.

Why anyone thinks server-side javascript is a good idea is beyond me.

> Why anyone thinks server-side javascript is a good idea is beyond me.

That someone would want to use the same language to write both their client and server side code is beyond you?

When that language is javascript, yes.

Have you ever worked on a non-trivial JavaScript application? I'll define that as 10,000 lines or more. I ask because I suspect that this comment is simply a visceral reaction to some flaw in JS, and I want to know if that reaction is based on experience.

I have worked on what I would call non-trivial Javascript applications, but only front-end javascript (no server-side js, apart from a few MongoDB map-reduce queries).

My feelings towards js are are informed by that experience, and my (happier) experiences with other languages - which are primarily Python, Java and Objective-C, if you're interested.

Largely, yes. The problem domains are different. The usage patterns are different. The constraints are different. Why not be pragmatic and pick an appropriate technology for each use case?

> Why not be pragmatic and pick an appropriate technology for each use case

I suppose you know what's appropriate.

Defensive much? All I was saying is that I don't find the "uses the same language" argument dispositive.

I don't mean to be defensive, I personally don't use JS on the server side, but I don't see any problems with other people doing it. No more than I would have problems with people using, say, Ruby.

You responded to someone who said "I disagree that it's expressive in comparison to other modern languages."

Why would a person of that opinion value a small amount of code sharing over language expressiveness? So, there's your answer as to what they're imagining.

Regarding code sharing - maybe you can answer another post in this thread which I ask, "Where are these mythical Node.js applications that share so much code with the client...?"

I'd argue that many applications have plenty of concerns for which sharing code between the server and client is clearly pragmatic: http://nerds.airbnb.com/wp-content/uploads/2012/10/shared-js...

I can think of two ways to interpret this.

Perhaps you believe that in web applications, all of the real computation happens on the server, and JavaScript is just for providing a nice UI. Some people probably want it to be this way, so they can do most of the work in their preferred language and runtime environment, and only deal with JS for the minimum of client-side work. But to take this approach is to leave unused the embarrassment of riches that we have in computing power on the client side, even in smartphones. If we make full use of that client-side computing power, we can reduce server resource consumption and, more important from a user's perspective, the need to incur the cost of network round trips.

Or maybe you think that in modern web applications, most of the complex logic belongs on the client side, and the server is mainly for receiving, storing, and sending data. In that case, perhaps you think the most important attribute of a server-side language is performance. But it's probably quite rare for the server side of a real web application to be a dumb data store. So what happens if you wrote some non-trivial logic in JS, then discover that it needs to run server-side?

I think we're still figuring out what belongs on the client and what belongs on the server. Therefore, I think using the same language on both sides might have some benefit. Admittedly, I've never written a real application with Node.js, and the thought of callback spaghetti everywhere doesn't exactly appeal to me. But I might accept that in return for maximal code re-use.

I don't think callback spaghetti is an absolute requirement of programming in Node.

I think this article says it quite well: Callback Hell is a Design Choice : http://blog.caplin.com/2013/03/13/callback-hell-is-a-design-...

One does not have to believe that "all of the real computation happens on the server" to not want to use Javascript if one doesn't have to.

Where are these mythical Node.js applications that share so much code with the client though? What functionality is shared and how much time did it save anyone?

Personally, I wouldn't trust one browser-land function or library in my server application without digging through every line of code to make sure it's not going to do some browser-specific hackery. Then what have I saved? I'd rather go get a separate module that was built specifically for Node.js.

Then there's the time I'd save sharing my own code between Node.js and browser - which would be next to nothing because any time I save would be spent having to think about platform differences anyway.

Code reuse is an advantage I guess. For example you want fast responsive validations as the user enters data, but for security reasons you need to do final validations on the server.

You have objects on the client that you want to persist to the server but you don't want to have to write two models.

Server-side Javascript, in particular Node, is much better suited to event-driven applications (e.g. web servers) than a lot of other languages out there, including Ruby (and dare I say Python?).

This time I'll argue the other side.

A lot of web applications routinely do many I/O operations per request handler. For example, do a DB query, then do something with that data, then conditionally do another DB query based on the results of the first, then do something with that data, then query a REST Web service, and so on. Blocking APIs make this very natural; add high-level abstractions such as an ORM, and you don't even think about the fact that you're doing I/O. With something like Node, application code of this sort degenerates into callback spaghetti, unless you use something like the fiber module, or a compiler that transforms the natural, straight-line code into continuation passing style. Though I've previously argued for the potential advantages of using the same language for both the client and the server, I fail to understand why something like the fiber module isn't standard in Node, or why the kind of compiler I described isn't more popular. Perhaps that's just dogmatism or a cargo-cult mentality.

An event-driven system might be good for "real-time" applications where many clients connect and wait to have things pushed to them. Even then, I think coroutines or lightweight threads would be fine, as long as they're the norm for a runtime environment and its standard library (e.g. Go, and Haskell IIUC) and not bolted on (e.g. Python's eventlet and gevent).

The fact that most web applications do many I/O operations per request handler and the Blocking API's make it very natural so that "you don't even think about the fact that you're doing I/O" is precisely the problem. I/O is an eternity compared to computing cycles, and to have the entire thread blocked while waiting for I/O to complete means that you can have exactly one concurrent client.

Node can easily degenerate into callback spaghetti, that's true. But I think that has more to do with the paradigm being new to a lot of developers. Using promises and similar constructs are a very natural way to deal with callbacks, and reduce the spaghetti significantly. Unfortunately, they won't be baked into Node's core.

Even for a standard CRUD app, you can get way more performance out of Node than you can out of, say, Rails, precisely because it is highly concurrent.

> I said it was created for minor workflow events

I remember those times when Javascript was only used for changing button images in the mouse over event! It was a powerful extra to designers to have this knowledge.

I agree, its a mess with regard to expression - isn't that why this thread exists? The language is fun to write but eye-gouging to maintain. Of course you could apply strict conventions to make it maintainable, but at that point you might as well be in a statically typed language working at full speed in an ide.

After coding JS by hand for years (while doing other languages) I'm done with it. I'm ready to go preprocessor full time, either static language based but also interested in lisp variants, because if I have to go typeless, might as well do it in style.

I tried CoffeeScript for a while, but the philosophy is too similar to JS to keep my interest. It did reduce the code dramatically though, on avg about 70%.

I see your point, but JavaScript is much more popular than any of the other languages designed to compile to it. Thus, even if one works in a restricted and somewhat tedious subset of JS (such as the one encouraged by the Google Closure Compiler and used by the Closure Library), wouldn't it still be easier to find already-qualified developers than if one uses Haxe or ClojureScript or Dart?

> Of course you could apply strict conventions to make it maintainable, but at that point you might as well be in a statically typed language working at full speed in an ide.

Not really. We do the strict conventions thing and have had a lot of success with it. Being able to run in a browser is a huge, huge advantage. If I had a nice statically typed language that gave me that advantage as well as javascript does, I'd probably switch to it, because by inclination I prefer the compiler to do more work for me, but there's no way I want to leave behind having my code work for anything with a browser and f5 to see my code in action.

The fact that Node.js, Javascript on the server, is gaining so much popularity in the developer community means that it has benefits beyond its universality in the browser.

The fact that Node.js is becoming popular is simply a symptom of having a ridiculously large ecosystem of developers, and not much else.

A ridiculously large ecosystem of developers is a huge feature that we ignore at our peril. I think a mature developer should overlook aesthetic quibbles with a language, framework, or any other tool, and make decisions based solely on what's most practical.

we ignore at our peril.

Yup, developers do. But clients and users don't. Just make it work!

Who just so happen to be creating a lot of great libraries in a popular domain.

tg3 circa 2002:

The fact that PHP is gaining so much popularity in the developer community means that it has benefits beyond its universality in shared hosting environments.

> We need a real bytecode for the web, we need it to be standardised and we need to push for browsers to support it.

We had one. It was called Java. Actually, we still have it, but it just has such a bad reputation now; users don't trust it because of "security" and developers don't trust it because of "public static cruft()" and "Oracle".

But it is still quite capable. Did anyone else first play minecraft in a web applet? It worked incredibly well for me. So I argue that we do have a viable bytecode, we're just ignoring it.

Java is not vendor-neutral as JS is. That makes JS better.

Not necessarily. Not having a single (hopefully benevolent) entity control a platform means poor standardization -- which leads --> to vendor-specific variants - and voila, you get to the HTML/JS mess that we have today.

The experience sucks beyond compare, always has, and blaming the user isn't going to solve that.

You have to download a separate plugin with stupid ads in it. If your version is wrong, it won't work or it won't work right. A number of things won't work unless you use the one from Oracle. If you are lucky, a little tray reminder obtrusively harasses you every few weeks to update to a new version. If you don't, you have to worry about unpatched vulnerabilities. Now you come across a page with an applet in it. This applet stuck inside a little rectangle on the page takes a few seconds to kick off at all. Most of the time it looks terrible once it's up. It isn't at all uncommon that it crashes. Many people have experienced this bringing down the browser or even hanging the computer, which is especially awesome when you didn't even ask for the thing to run.

This isn't a matter of the users being stupid and not knowing what's good. This isn't good. It has never been good.

But the JVM was never really part of the browser, it was a plug-in like Flash. If we had a way to include JVM byte code in a page and JVM had just as much access to the DOM as javascript then it would be useful.

Java moves ahead despite peoples continued misconceptions about it. There are js-based jvm bytecode interpreters: https://github.com/int3/doppio seems pretty nice.

Can't wait to see the rebirth of Java^W NaCl applets.

Seriously, though, if you never see the underlying JS, if you code and debug everything in your preferred language and the result is fast, why would you care what your program compiles to?

Nobody objects to having their programs compile to PE on Windows, nobody requires Microsoft to use ELF or Mach-O instead! Even though, nowadays, PE is a bunch of pieces of cloth sewed together, nobody cares as long as it works!

Don't despise modest beginnings or sloppy evolution. Sloppy evolution from a very modest beginning has achieved things that we haven't yet come close to matching through deliberate design, such as our own species. And it does this by always taking the next incremental step from what it has, with no regard for the greater elegance of some hypothetical master plan.

And yet if we had to either write in or compile all our code down to QBasic in order to make web apps, we would be justified in complaining about that.

A BASIC descendant (VBScript) very nearly did become the scripting language of the Web. If it had gone that way, I'd like to think that I would tolerate it and write useful apps with it, as long as it didn't mean that Microsoft would have lasting control over the spread and evolution of the Web platform.

No. If I want byte code, I'll use Java or a native app. This idea that a web browser should be an operating-system-in-a-box-over-http needs to stop.

JavaScript is not a bad language. If you're getting caught up in gotchas and 'quirky' behavior, why not just read EMCA-262 [1] ? It lays out all defined behavior of JavaScript so you'll know exactly what the interpreter is doing when it reads your code.

[1] http://www.ecma-international.org/publications/files/ECMA-ST...

> This idea that a web browser should be an operating-system-in-a-box-over-http needs to stop.

Why? The Web platform is the only non-proprietary platform that has serious market-share among end-users and mind-share among developers. Therefore, it's the only thing that has a serious chance of ending the dominance of proprietary platforms. IMO, that goal is important enough to override any aesthetic concerns that we developers might have.

> it's the only thing that has a serious chance of ending the dominance of proprietary platforms.

That has never been the end goal for HTTP or even the WWW. Furthermore, we have proprietary web platforms today: just look at Facebook, Google+, Twitter, etc. It's in fact MORE fragmented than the OS market is right now.

I mean, think about it: if you were trying to design a portable OS-as-a-service, would you REALLY be using a stateless protocol like HTTP for it? We've done a pretty good job of hacking together ways to maintain state over multiple requests, but the fact of the matter is that it's 100% garbage overhead that wouldn't exist at all if we just used a stateful protocol in the first place!

Concise and correct; there's really not much more to say on this topic.

JavaScript is successful because it is a hack in it's very core.

It is no different than targeting C.

Reply on news.ycombinator.com