4 ms·

I never worked much with JS, but from my experience I find it hard to imagine writing such a big application in JS. It is so easy to do things wrong in JavaScri

I never worked much with JS, but from my experience I find it hard to imagine writing such a big application in JS. It is so easy to do things wrong in JavaScript. Weak types, global namespace, ambiguous and unexpected behaviours.

nwienert 12y ago
I feel like people stick fingers in their ears and ignore the ecosystem whenever JS is mentioned. There's a wealth of transpilers and tools that fix all the problems mentioned here (if you even agree they are problems), and yet they are brought up every time. Weak types: Check out Facebook Flow or TypeScript. Global namespace: Not true with require/modules. Ambiguous/unexpected behavior... please explain? You could use any number of libraries to add consistency there. It's incredibly easy to include a JSLint file in your repo and as a git hook to ensure consistent syntax usage. ES6 introduces lots of nice features for writing code, and is usable today with transpilers.
- adamors 12y ago
  Yes but if you're using a language that transpiles to Javascript, you might as well use another language all together (for backend programming). Debugging becomes much simpler with a language that doesn't has to turn into something else. For frontend development, a lot of frameworks and libraries only work consistently with Javascript. I've looked at TypeScript for instance, and it indeed looks nice. But it has a bunch of edge cases with Angular and/or Backbone. You're just piling on complexity with these languages.
  - nwienert 12y ago
    Oh well, at this point we're moving into subjective opinion. But you need to write your frontend SPA with JS. And the isomorphic part, if designed from the ground up adds almost no extra code. So, really it's almost free to render first with Node, if you're starting a fresh SPA. I don't see why you wouldn't want to do it. And we can all agree the ES5 has some warts, so you may as well transpile. Whether it's ClojureScript, Coffee, Type, or anything else doesn't matter, I just think it's a problem solved. Webpack makes debugging them easy with sourcemaps and live-compilation. In fact you can get hot-reloading[1] in React. So your app re-compiles without reloading. I'm happy with ES6 + Flow. It's all ES6 syntax anyway, works with all libraries, and is fast to write, good looking, and functional. [1] https://github.com/gaearon/react-hot-loader https://github.com/gaearon/react-hot-loader
  - tracker1 12y ago
    If you write very modular code with good test coverage, the odds of you needing to fire up a debugger are greatly reduced. Regardless of the language you choose. Given JS has first-class functions, and many libraries to follow functional patterns. You can write very stable code, with almost no chance of side effects within a given function/context.
    - adamors 12y ago
      The problem is, that not everyone works on greenfield applications all the time. I never inherited modular, well tested javascript projects. I did, on the other hand, have to take over cobbled together jQuery, Backbone and Coffeescript applications.
      - nwienert 12y ago
        I think the real problem is that this has nothing to do with the article on hand. Yahoo is writing a greenfield application, and they are avoiding exactly those problems by using React. So, literally your pain point is exactly what they are writing about avoiding, and yet you still comment on this article with the same anti-JS nonsense.
- bad_user 12y ago
  Facebook Flow or TypeScript - still weak. On require/modules, that's a freaking mess. Ambiguous/unexpected behavior... nothing fixes it. To make matters worse, there's always the promise of some magical library or tool that's going to fix your problems, until you discover that it sucks, or that it is unmaintained, or that it doesn't interoperate with another library and then you're back to search between thousands of pieces of crap that do the same thing. I remember the days when people were having boners over CoffeeScript. Boy, that was a bad move.
  - Kiro 12y ago
    > Facebook Flow or TypeScript - still weak. How is it weak?
    - adamors 12y ago
      Flow was released literally last week. I guess calling it weak is going too far, but people in this comment thread refer to it like it's age old tech.
  - tracker1 12y ago
    I prefer straight JS over CoffeeScript/TypeScript/Flow etc... I don't find require/modules to be too much of a mess.. unless you are using a lot of really large tool-chains with deep dependencies... npm dedupe helps point out problems there. Breaking your logic into idempotent functional components without side effects as separate files/modules reduces a lot of what can be considered ambiguous or unexpected. If you work with a functional flow, avoiding OO in JS as much as prudent, you can get a lot done without nearly as much confusion. For now co/generators/promises get you really far along. In the future await/async will take it farther.
- ocfx 12y ago
  Flow is awesome
- manish_gill 12y ago
  True, there's a plethora of JS tools someone can use. The problem is that they have to be discovered. And there's no standard. I found out about Browserify 2 days ago and realised all the problems it could have solved for me. Now I have to migrate the code I have to it. JS ecosystem is confusing. See: https://news.ycombinator.com/item?id=7074307 https://news.ycombinator.com/item?id=7074307 Utilities should be a part of the language's "battery". Ambiguous/Unexpected behaviour: I mean I can redirect you to the popular "Wat" talk. Moreover, isn't that the entire premise of "Javascript: The Good Parts" anyway?
  - spion 12y ago
    Flow isn't mature enough yet, but even TypeScript eliminates pretty much the entire Wat talk. Also, it compiles to CommonJS, which means it works well with both node and browserify. Yes, we need a blessed, "batteries included" stack for JS made of components that play nicely together. Here is a nice list to get started with (IMO, ymmv) 1. TypeScript or Flow 2. React 3. Promises: bluebird, when or p-promise 4. Observables: rxjs or most (they play well with promises) 5. immutable-js for immutable data structures 6. lodash and/or Ramda.js 7. browserify
    - tracker1 12y ago
      Going to make a few points of contention... 1. Not a problem, though I don't use either, I tend to use very small modules (not necessarily via npm, but require'd in my own project, or outside modules) 2. React, and even the Yahoo flux tools are pretty nice. React by itself is less useful. 3. I'd go with es6-promise here, which complies with the spec. I wrote i-promise as a module to give an ES6 compatible promise library, or native as available. 4. Observables are pretty evil... the whole flux architecture is to avoid direct observations in favor of a unidirectional data flow.. but that's more opinion. 5. completely agreed... immutable data flows work to prevent side effects. Even if you don't use these libraries, avoiding side effects is a big thing. 6. Also agreed, though you can usually get the parts you want without the weird deep dependency chains in lodash. 7. Agreed here, though webpack is interesting, imho it breaks too much with node's approach to includes, and doesn't work as well with reusing code on the server-side (imho). Other things to look into include csp, streams, events and the gulp build tool.
- notastartup 12y ago
  don't you feel that if you a language's short coming is addressed by adding more of it in the form of duct tapes is problematic? I love javascript when it was doing simple things on the DOM, not trying to recreate the desktop in the browser, making it render across different devices and browsers, making it crawlable by running a headless qtwebkit process to serve pages that google can't see, using a slow and unstable document storage database often advertised with an old javascript engine requiring you to write chains of callbacks for even the simplest operations, all in the back of my mind believing that somehow all this complexity has helped me, why, look around everybody's doing it. This Java/PHP/Apache garbage that has worked well but didn't feel cool or fad enough? Let's kick it.
- edwinnathaniel 12y ago
  You assume everybody uses these tools... in unity, harmony, and applying the best practices (that are not established yet). You assume all libraries in JS is mature, well-supported, and will be there in the next 4 years at least. I echoed other comments: JS ecosystem is unstable and confusing at the moment. Case and point: EmberJS. I have to use ember-cli, npm, bower, and broccoli. Some of them overlap.
  - sehr 12y ago
    None of those overlap. NPM is used for build tools along with broccoli, and bower is used for application code. Ember cli packages them together.
- tall 12y ago
  I do these things. But will my neighbor do the same?

nwienert 12y ago

I feel like people stick fingers in their ears and ignore the ecosystem whenever JS is mentioned. There's a wealth of transpilers and tools that fix all the problems mentioned here (if you even agree they are problems), and yet they are brought up every time. Weak types: Check out Facebook Flow or TypeScript. Global namespace: Not true with require/modules. Ambiguous/unexpected behavior... please explain? You could use any number of libraries to add consistency there. It's incredibly easy to include a JSLint file in your repo and as a git hook to ensure consistent syntax usage. ES6 introduces lots of nice features for writing code, and is usable today with transpilers.

adamors 12y ago
Yes but if you're using a language that transpiles to Javascript, you might as well use another language all together (for backend programming). Debugging becomes much simpler with a language that doesn't has to turn into something else. For frontend development, a lot of frameworks and libraries only work consistently with Javascript. I've looked at TypeScript for instance, and it indeed looks nice. But it has a bunch of edge cases with Angular and/or Backbone. You're just piling on complexity with these languages.
- nwienert 12y ago
  Oh well, at this point we're moving into subjective opinion. But you need to write your frontend SPA with JS. And the isomorphic part, if designed from the ground up adds almost no extra code. So, really it's almost free to render first with Node, if you're starting a fresh SPA. I don't see why you wouldn't want to do it. And we can all agree the ES5 has some warts, so you may as well transpile. Whether it's ClojureScript, Coffee, Type, or anything else doesn't matter, I just think it's a problem solved. Webpack makes debugging them easy with sourcemaps and live-compilation. In fact you can get hot-reloading[1] in React. So your app re-compiles without reloading. I'm happy with ES6 + Flow. It's all ES6 syntax anyway, works with all libraries, and is fast to write, good looking, and functional. [1] https://github.com/gaearon/react-hot-loader https://github.com/gaearon/react-hot-loader
- tracker1 12y ago
  If you write very modular code with good test coverage, the odds of you needing to fire up a debugger are greatly reduced. Regardless of the language you choose. Given JS has first-class functions, and many libraries to follow functional patterns. You can write very stable code, with almost no chance of side effects within a given function/context.
  - adamors 12y ago
    The problem is, that not everyone works on greenfield applications all the time. I never inherited modular, well tested javascript projects. I did, on the other hand, have to take over cobbled together jQuery, Backbone and Coffeescript applications.
    - nwienert 12y ago
      I think the real problem is that this has nothing to do with the article on hand. Yahoo is writing a greenfield application, and they are avoiding exactly those problems by using React. So, literally your pain point is exactly what they are writing about avoiding, and yet you still comment on this article with the same anti-JS nonsense.
bad_user 12y ago
Facebook Flow or TypeScript - still weak. On require/modules, that's a freaking mess. Ambiguous/unexpected behavior... nothing fixes it. To make matters worse, there's always the promise of some magical library or tool that's going to fix your problems, until you discover that it sucks, or that it is unmaintained, or that it doesn't interoperate with another library and then you're back to search between thousands of pieces of crap that do the same thing. I remember the days when people were having boners over CoffeeScript. Boy, that was a bad move.
- Kiro 12y ago
  > Facebook Flow or TypeScript - still weak. How is it weak?
  - adamors 12y ago
    Flow was released literally last week. I guess calling it weak is going too far, but people in this comment thread refer to it like it's age old tech.
- tracker1 12y ago
  I prefer straight JS over CoffeeScript/TypeScript/Flow etc... I don't find require/modules to be too much of a mess.. unless you are using a lot of really large tool-chains with deep dependencies... npm dedupe helps point out problems there. Breaking your logic into idempotent functional components without side effects as separate files/modules reduces a lot of what can be considered ambiguous or unexpected. If you work with a functional flow, avoiding OO in JS as much as prudent, you can get a lot done without nearly as much confusion. For now co/generators/promises get you really far along. In the future await/async will take it farther.
ocfx 12y ago
Flow is awesome
manish_gill 12y ago
True, there's a plethora of JS tools someone can use. The problem is that they have to be discovered. And there's no standard. I found out about Browserify 2 days ago and realised all the problems it could have solved for me. Now I have to migrate the code I have to it. JS ecosystem is confusing. See: https://news.ycombinator.com/item?id=7074307 https://news.ycombinator.com/item?id=7074307 Utilities should be a part of the language's "battery". Ambiguous/Unexpected behaviour: I mean I can redirect you to the popular "Wat" talk. Moreover, isn't that the entire premise of "Javascript: The Good Parts" anyway?
- spion 12y ago
  Flow isn't mature enough yet, but even TypeScript eliminates pretty much the entire Wat talk. Also, it compiles to CommonJS, which means it works well with both node and browserify. Yes, we need a blessed, "batteries included" stack for JS made of components that play nicely together. Here is a nice list to get started with (IMO, ymmv) 1. TypeScript or Flow 2. React 3. Promises: bluebird, when or p-promise 4. Observables: rxjs or most (they play well with promises) 5. immutable-js for immutable data structures 6. lodash and/or Ramda.js 7. browserify
  - tracker1 12y ago
    Going to make a few points of contention... 1. Not a problem, though I don't use either, I tend to use very small modules (not necessarily via npm, but require'd in my own project, or outside modules) 2. React, and even the Yahoo flux tools are pretty nice. React by itself is less useful. 3. I'd go with es6-promise here, which complies with the spec. I wrote i-promise as a module to give an ES6 compatible promise library, or native as available. 4. Observables are pretty evil... the whole flux architecture is to avoid direct observations in favor of a unidirectional data flow.. but that's more opinion. 5. completely agreed... immutable data flows work to prevent side effects. Even if you don't use these libraries, avoiding side effects is a big thing. 6. Also agreed, though you can usually get the parts you want without the weird deep dependency chains in lodash. 7. Agreed here, though webpack is interesting, imho it breaks too much with node's approach to includes, and doesn't work as well with reusing code on the server-side (imho). Other things to look into include csp, streams, events and the gulp build tool.
notastartup 12y ago
don't you feel that if you a language's short coming is addressed by adding more of it in the form of duct tapes is problematic? I love javascript when it was doing simple things on the DOM, not trying to recreate the desktop in the browser, making it render across different devices and browsers, making it crawlable by running a headless qtwebkit process to serve pages that google can't see, using a slow and unstable document storage database often advertised with an old javascript engine requiring you to write chains of callbacks for even the simplest operations, all in the back of my mind believing that somehow all this complexity has helped me, why, look around everybody's doing it. This Java/PHP/Apache garbage that has worked well but didn't feel cool or fad enough? Let's kick it.
edwinnathaniel 12y ago
You assume everybody uses these tools... in unity, harmony, and applying the best practices (that are not established yet). You assume all libraries in JS is mature, well-supported, and will be there in the next 4 years at least. I echoed other comments: JS ecosystem is unstable and confusing at the moment. Case and point: EmberJS. I have to use ember-cli, npm, bower, and broccoli. Some of them overlap.
- sehr 12y ago
  None of those overlap. NPM is used for build tools along with broccoli, and bower is used for application code. Ember cli packages them together.
tall 12y ago
I do these things. But will my neighbor do the same?