Hacker News Reader

Comment by mjackson | Hacker News Reader

> As much as I love JavaScript, there are just some things I don’t want written in JavaScript – my shopping cart, for example.

After developing almost exclusively in JavaScript for the better part of the past year (and doing a lot more in the previous 6), I'm convinced that this mentality is going to start fading as more and more developers become more capable and productive with JavaScript.

There's nothing inherently wrong with the language that prevents you from writing sufficiently complex and reliable systems to power something like a shopping cart, or anything else for that matter. The main thing that is missing at this point is experience and maturity in the JavaScript community at large, which is quickly changing as more and more developers start embracing the language.

View on HN

It doesn't have an adequate type system. There are too many silent conversions. The syntax is very clunky. All the object systems feel hacky and they can't be relied on to interoperate with each other. Problems like no standardized threading support or decimal type could be resolved in the future. But the language as it exists currently lets you override everything, and that's the sort of thing that you can't remove in later versions because existing code will be using it. So it's always going to be possible to e.g. modify Object.prototype and then expect the method you added to be accessible on anything. And then that library breaks because you defined an object that already has a method with that name.

Yes, a sufficiently smart developer can write good code in Javascript. But there are very few people who I'd trust to write financial code in Javascript, and I think all of them would use a better language rather than expending the effort working around its deficiencies.

I think Typescript solves a lot of these problems. The type system is amazing, conversions are explicit. Syntax is slightly improved, built-in class system.

The others I don't really mind: I like writing event-loop code over threads, and have never once run into Object.prototype problems in the wild.

I hadn't heard of Typescript, but I think we'll be seeing a lot more efforts along these lines. Despite the pain and inelegance of compiling something to Javascript, I see two inexorable forces that will lead a lot of smart engineers in that direction.

First, running the same UI code on the front-end and back-end will enable the best performing apps across platforms. Imagine being able to run a rich client on a powerful PC that just talks to an API and does all the rendering as a single page app, while simultaneously being able to serve up pure HTML/CSS to mobile devices and search engines. Being able to run code on the server or client as needed solves too many problems to ignore.

But on the other hand, javascript flexibility and lack of type system will inevitably cause problems as the codebase grows unless you have a good lead developer to define standards and an iron-fisted approach to code reviews.

Personally I think coding standards are a stretch with a language as wild as javascript, and a higher level language to enforce certain things is the best way to reconcile these two problems. I can even imagine supplementing with something like (for instance) a Haskell library that lets you generate JS code for interfacing with the back-end in a provably correct fashion, and plugging that into the UI code.

Where have you been hiding? There's been a virtual explosion in the number of languages that compile down to JS[1] in just the past 1-2 years, and TypeScript is probably the youngest of them all. CoffeeScript[2] is another big one, I believe it's much more Ruby-like. There's even 7 projects involving Haskell.

1. http://altjs.org/

2. http://coffeescript.org/

Well I'm a Ruby guy so I'm definitely aware of Coffeescript, but mostly I'm just not starting a lot of greenfield projects these days :(

What's so good about TypeScript's type system and what problem does it solve?

Problems like I look at a function and have no clue about what it's arguments are.

JSDoc comments?

In general, I believe it will help make larger JS codebases more maintainable. Specifically it enhances the following:

- Refactoring e.g. easily globally change a class member's name

- Type safety e.g. it will bark if you pass a string where an int is expected

- General IDE handyness e.g. 'Go to definition'

A really good demo here: http://channel9.msdn.com/Events/Build/2013/3-314

the two best features of Typescript's type system IMHO are:

- structural typing for interfaces (which means that classes implicitly implement an interface if the definitions match)

- gradual typing (mainly the ability to convert between 'any' and other types implicitly, which makes it much easier to interact with JS libraries/port JS code to Typescript.)

More generally speaking, Typescript aims to solve the problem of maintaining large codebases by giving you the additional security of static typing. The idea is that many simple errors can often be caught by a compiler, but would be much more time-consuming to find otherwise.

JS already has this..

if (obj && obj.quack && typeof obj.quack == 'function') obj.quack(); //looks like a duck

Almost no one realizes this, but the main purpose of TypeScript is to negate one of JavaScript's greatest advantages which is the lack of typing. This is an advantage because it makes code easier to write and read.

The problem that TypeScript solves is that the web platform is in direct conflict with Microsoft's monopolies in PC gaming and business productivity software (Office). Confusing developers into thinking that JavaScript needs types leads them down the path of statically typed languages, i.e. C# and Microsoft's proprietary and closed .NET Framework and software ecosystem.

I think optional typing is better than no typing. It's useful for allowing APIs to be self documenting. It seems as if optional typing is going to get more and more popular. For example, see Google's optional typing in dart, where they actually recommend to not use types for local variables:

https://www.dartlang.org/articles/style-guide/#type-annotati...

I am not sure. I think that descriptive identifiers can indicate the type and be augmented by documentation.

They can. But both tend to get out of date as a codebase develops. It's very useful to have an automated tool that ensures the documentation lines up with the actual code - i.e. a type checker.

The "Open Web" is closed to one single language choice that was made for you by someone else. TypeScript is being developed, because Microsoft adapts to where the world is moving and they are just trying to avert the disaster that will happen when enterprises will actually start trying developing whole applications in JS. And Google is developing a higher-order version language as well. Nobody developed a language to run on top of Java, C#, C++, but there is a plenty of choice for JS: Dart, TypeScript, CoffeeScript etc.

> Nobody developed a language to run on top of Java

Clojure? Scala?

I said 'Java' not JVM.

Dart runs on top of JS? I thought it was a replacement for JS.

The primary mechanism for running Dart on the client is by compilation to JS. There is a DartVM that runs Dart directly, but its not bundled into any browsers except for a special version of Chromium ("Dartium") bundled with the Dart SDK so that the development cycle can proceed without a dart2js run at each iteration, but its not intended for general use that way.

> Nobody developed a language to run on top of Java, C#, C++

Because instead of developing languages to run on top of them, people just designed languages to run on the same platform. The browser environment is a special case where the only common feature of the platform that is available to target is JS, there's no common VM underlying it, so replacements target JS.

Though its worth noting that while it may be true that no one developed a language to run on top of C++, C++ was originally implemented as a language that was preprocessed into C and then fed to a C compiler, much the way that many JS alternatives are compiled to JS and then fed to a JS interpreter.

Holy mother of god, HOW is untyped code easier to read?!

I've been using TypeScript for experimenting with Node.js and while it's a great solution there's a few difficulties some might face with it:

-TypeScript definitions for many libraries, such as express are out of date and require modding to use.

-Visual Studio has no built in support for TypeScript with Node for debugging, but it has been mentioned as likely to be added by the TypeScript team eventually.

-There are third party plugins for Node in Visual Studio for debugging, but none support TypeScript yet.

I've found the best solution thus far is Intellij IDEA or WebStorm, as it has support for both Node and TypeScript.

fyi, webstorm 7 has good compiler support for typescript, but the ide intellisence/ syntax highlighting is still not great.

i use typescript professionally, i use vs2013 for writing code, webstorm for debugging / testing

This is why I hope and work towards making Dart succeed. Dart is very nice as server-side or command-line scripting language - the VM and dart:io provide a very node.js-like environment. It provides much more safety, structure and feedback to help guide developers towards better code than JavaScript.

Java and .NET are the only strongly typed languages used heavily as a web backend. Python, PHP, Ruby, and Node.js are all weakly typed.

Yeah this strikes me as the usual "language X sucks, because dynamic languages suck".

Not really, scripting has it's good uses. It's just wrong to use scripts to replace programming languages for all tasks.

A "scripting language" is a programming language. "Scripting" is a completely useless description, and is usually used to stoke a flamewar.

You are confusing dynamic/static vs strong/weak typing.

I think python & ruby are considered strongly typed, whereas javascript is weakly typed. strong/weak usually refers to implicit conversion or not.

Almost every shopping cart in existence right now is written in PHP, Python or Ruby, and they have much of the same "issues". Write tests, use a good bignum library, maintain code standards. Syntax is subjective, I find it pretty nice when following a certain style.

Almost nobody modifies Object.prototype, and we now have plenty of APIs to deal with that - defineProperty, seal, freeze, etc.

Was just going to say, a large percentage of online shopping is based on open source e-commerce solutions, most of which are written in PHP. Which shares (and possibly overshadows) Javascript's problems.

What's the big deal with getting bignum into js? Everything else I can agree with, but not having 64bit int support in a server side language has to hurt. (just look at most node db adapters and bigints are handled as strings)

Okay, aside from some scientific functions, what do you really need from an integer that 52bits isn't enough for?

It's not about storing large numbers, but math precision. For example:

    0.3 * 3 => 0.8999999999999999

A few rounding mistakes and you have a huge mess.

You seemed to have jumped from talking about integers to floating point!

And the example you have given is a problem with all floating point implementations, not just Javascript. You will get that exact same answer in C, Java, etc.

The only way to avoid this is to represent rational numbers directly, without simplification. For example:

  (3/10) * 3 => (9/10)

There are no integers in js, all numbers are floats. What you want to do is represent all values as integers choosing an arbitrary precision, then only do integer math.

In the example given, using node-bignum and assuming our precision is a thousand of a cent:

    big(30000).mul(3) => 90000

Of course you'd get the same result in plain javascript with these numbers, but then you'd have to handle everywhere an operation could return decimals, and using bignum you have "unlimited" precision > 52bits.

I agree with what you are saying. It's just that you gave a floating point multiplication example, where an integer multiplication with overflow would have been a relevant example.

Here's a relevant example,

    2^26 * 2^26 == 2^52

may not hold in javascript because it only supports 52 significant binary digits. Whereas other languages usually support 64 significant binary digits.

++ yes. for those not aware, all numbers in javascript are 64bit floats.

that said, you could still write your own bigint class if you need precision beyond that.

They're 64bit floats, but you get 52 bits of integer precision... You're as likely to hit issues as you are with a 32bit int.. the big difference is you need to use Math.round() if you want to multiply/divide in order to get to a whole number again.. Even with a 64-bit integer, you can suffer from overflow, it's only a matter of where.. and even with 32bit environments there have been work arounds for larger numbers/precision.. with JS there are bignum libraries for this.

I don't need "an integer bigger than 52 bits". I need a way to represent (fixed-precision) decimals exactly, and do arithmetic with them, preferably without performance being too terrible or the code looking too horrible. And I'd like it to be a standard implementation, or conform to a standard interface, so that a library ecosystem can build up with support for this type.

If you use jshint (it will yell at you when using == with non-null) much (all?) of these problems go away.

Unfortunately, concatenation can still be a mess if you don't know how it works. And sometimes in spite of knowing how it works.

Once ES6 will kick in, things will get better. Right now it's definitely a shit storm.

Yeah, things will be so much better in year 2050.

Devil advocating:

I coded exclusively in javascript from 2006-2011. Most of that time was spent at Meebo, where we authored one of the most sophisticated JS application in existence at the time. It was great stuff!

I've worked extensively with node.js 2011-mid2013, launching multiple backends written partially and exclusively in node. Lots of fun!

On https://github.com/marcuswestin I maintain multiple widely used open source projects, much of it JS.

In the past 4 weeks I've rewritten my current product's entire nodejs backend to a statically typed language. Why? Because static type analysis allows you to develop more accurate code faster and with lower maintenance cost.

I've been a strong advocate for "javascript everywhere" for a long time. However, these days I believe that there is exactly one fantastic use case for javascript: delivering rich application experiences in web browsers.

So you may be right: perhaps this line of arguing is fading. But in that case I'm a real outlier.

(and with all that said, the most important thing to consider is this: what tool will best allow you and your team to build and maintain your intended product?)

> Because static type analysis allows you to develop more accurate code faster and with lower maintenance cost.

This statement may be true for you, but it's not for everyone.

It's a dangerous argument because it assumes that static types are going to somehow magically turn bad code into good code, or (by extension) bad coders into good ones.

Static typing is a not a solution to the problem of any deficiencies in the language, but rather the problem of people shooting themselves in the foot with it. It's admittedly a related problem, but a separate one.

I also said:

> (and with all that said, the most important thing to consider is this: what tool will best allow you and your team to build and maintain your intended product?)

I'd defend the statement you quoted like this: all languages are type. Dynamic languages simply have exactly one expression type, "any". Specifying multiple types affords you strictly beneficial abilities. Static type checks is probably the most significant. Performance improvements and highly specific and accurate code editing assistance (e.g auto suggest) can also be significant.

But yes, you're absolutely right. Nothing but sincere effort, lots of practice, and critical thinking can make you a better programmer.

At the same time, a great carpenter becomes even so much better with a properly weighted hammer and an accurate lever.

In what language are you rewriting the backend?

Bet it's Java.

So what is the other static language? I see go programs on your github account also Objective C.

I very much agree with this. While it's definitely fun to build apps in Node, especially when you need one really simple thing to happen with enormous capacity in terms of requests per second, I prefer to build my backend in Rails and frontend in Ember.js, because I feel JavaScript is best used as a frontend language, and Rails is really great at making RESTful APIs as well as encapsulating business logic far away from the JS frontend app. I much prefer writing Ruby rather than JavaScript, but I appreciate JS and know it well enough to do a good job.

And rails is particularly better/easier to implement a backend in than NodeJS + crudify/restify/express, or any number of other tools?

I've not used anything that allows for as easy modularity as node+npm lend themselves to... just because it's JS doesn't mean it's spaghetti that has blurry code sharing between the client and server.. it's not all meteor, even if that does have a lot to offer.

> There's nothing inherently wrong with the language that prevents you from writing sufficiently complex and reliable systems to power something like a shopping cart, or anything else for that matter.

In other words, it's Turing complete. That's great but not exactly an argument for using JS server-side so much as a reason why it is possible. I love JS, but I also know what it was designed for.

You're kind of quoting him out of context

> I believed, and still do believe, that statically typed languages are exactly what you want in the guts of your business logic.

He wasn't making a case against javascript for his shopping cart but rather against dynamic languages.

Now, you could certainly disagree with that as well, but it opens the discussion to a more correct one vs why you believe javascript is a mature language. Something the author actually agrees with.

I can understand some trepidation around actual checkout but seriously, how much linguistic fortitude do you need to implement a shopping cart?

Exactly this, I'd be far more concerned about which datastore was used for a shopping cart than which programming language.

Yeah I generally agree. With the builtin addition of require() and reasonable scoping rules, Node.js has turned Javascript into a weak-typed, memory-managed C. There is still the 64-bit integer and large decimal problem, but otherwise that is great. I don't see why the entire backend cannot be Node.js.

Developing things with the language has never been the problem.

Coming back and maintaining them a year later is a different story.

Reply on news.ycombinator.com