8 ms·

> 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 exclusiv

• lmm 13y ago
  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.
  • embwbam 13y ago
    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.
    • dasil003 13y ago
      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.
      • k3n 13y ago
        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/ http://altjs.org/ 2. http://coffeescript.org/ http://coffeescript.org/
        • dasil003 13y ago
          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 :(
    • Kiro 13y ago
      What's so good about TypeScript's type system and what problem does it solve?
  • deleted 13y ago
    [deleted]
  • spankalee 13y ago
    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.
  • rpedela 13y ago
    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.
    • hackula1 13y ago
      Yeah this strikes me as the usual "language X sucks, because dynamic languages suck".
      • CmonDev 13y ago
        Not really, scripting has it's good uses. It's just wrong to use scripts to replace programming languages for all tasks.
        • hackula1 13y ago
          A "scripting language" is a programming language. "Scripting" is a completely useless description, and is usually used to stoke a flamewar.
    • lsiebert 13y ago
      You are confusing dynamic/static vs strong/weak typing.
      • deleted 13y ago
        [deleted]
    • veemjeem 13y ago
      I think python & ruby are considered strongly typed, whereas javascript is weakly typed. strong/weak usually refers to implicit conversion or not.
  • ricardobeat 13y ago
    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.
    • adamors 13y ago
      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.
    • troyk 13y ago
      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)
      • tracker1 13y ago
        Okay, aside from some scientific functions, what do you really need from an integer that 52bits isn't enough for?
        • ricardobeat 13y ago
          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.
          • hrjet 13y ago
            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)
  • peterhunt 13y ago
    If you use jshint (it will yell at you when using == with non-null) much (all?) of these problems go away.
    • greg5green 13y ago
      Unfortunately, concatenation can still be a mess if you don't know how it works. And sometimes in spite of knowing how it works.
  • ronreiter 13y ago
    Once ES6 will kick in, things will get better. Right now it's definitely a shit storm.
    • CmonDev 13y ago
      Yeah, things will be so much better in year 2050.
• marcuswestin 13y ago
  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 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?)
  • mjackson 13y ago
    > 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.
    • marcuswestin 13y ago
      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. :)
• badman_ting 13y ago
  > 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.
• svachalek 13y ago
  I can understand some trepidation around actual checkout but seriously, how much linguistic fortitude do you need to implement a shopping cart?
  • jeffasinger 13y ago
    Exactly this, I'd be far more concerned about which datastore was used for a shopping cart than which programming language.
• GrinningFool 13y ago
  Developing things with the language has never been the problem. Coming back and maintaining them a year later is a different story.
• rpedela 13y ago
  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.
• ramblerman 13y ago
  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.