4 ms·

I don't find writing JavaScript to be that hard. I don't get all of these compilers like this one, CoffeeScript, and TypeScript. Are people really that lazy tha

I don't find writing JavaScript to be that hard. I don't get all of these compilers like this one, CoffeeScript, and TypeScript. Are people really that lazy that they can't spend the couple days it takes to learn the syntax and gotchas of JavaScript?

justathrow2k 12y ago
I don't think laziness or a lack of desire to learn java script is the driving force for these projects. Rather, its simply for people who prefer a facade of strong types over their java script.
- jtwebman 12y ago
  What do strong types get you? Being I write a bunch of C# at work and almost all JavaScript at home I find types very limiting, so I still don't get why?
  - munificent 12y ago
    > all JavaScript at home Every language works pretty well for solo personal projects. It's when you scale up to dozens of team members and millions of lines of code that some things don't work as well.
  - justathrow2k 12y ago
    I'm sorry, are you hoping I provide an all encompassing answer that convinces you of its usefulness? I can't provide that. Like I said, its simply a matter of personal preference. You find types limiting, others find them helpful.
  - aquark 12y ago
    I find Typescript catches all sorts of typos that get missed in pure JS because I don't have 100% code coverage tests. Sure a JSLinter might catch some of those, but it won't find mis-spelled method names. Other benefits include not having to remember the 'interesting' rules around 'this' in pure JS (though that occassionally slips through in libraries that use it). Having saner (to my eyes) syntax for modules and encapsulation. And having intellisense support in Visual Studio reduces the effort of writing the code.
    - jtwebman 12y ago
      Both great points!
  - fsloth 12y ago
    When I implement a type zoo that models the problem I am solving I do not need to spend as much time reasoning about the semantics (with a good IDE) and the compiler warns me if I've done something odd and won't run the program if I've done something wrong. With a strong typesystem I can first figure out what I need to do, then write it (like a fews of hundreds of lines), compile it and be fairly confident that the program runs almost correctly. Static typesystem does not help with the bugs that have to do with bugs in algorithms (wrong iteration order etc.) but it let's me concentrate on those parts mostly. Static typing also functions as a self documentation - I see the intended program flow from the type signatures and do not need other means necessarily to figure out what the program flow is. To me types are like lego bricks and dynamic languages are like ducktape - both have their uses.
    - jtwebman 12y ago
      I just find them hand holding and limiting.
      - fsloth 12y ago
        Well said! I love it when I can get the computer to hold my hand and limit my actions. Personally I feel the limits of my cognition and enjoy when the computer assists in proofing the correctness of my programs. That way I can be more sure I don't do anything that breaks the program logic and that developers that come after me remain within the boundaries of correctness when modifying my code. Types don't help in design but they help in forming a coherent whole. I've figured out there are two constraint systems I can use to effectively write correct programs. One of them is a typesystem and the second is set theory. Granted, the most mainstream statically typed languages come with so much syntactical baggage and lack type hinting (C++, Java, C#) that they can effectively hide the elegance of types as a problem modeling tool. Types can be used just as a non-value adding anal-retentive bureaucratic baggage but that's not how they should be used. I'm professionally mostly a C++ programmer but did not really 'get it' until I familiarized myself with functional languages (Ocaml, F#) which helped me understand how to actually leverage a typesystem to help me write correct code instead of 'just using typedeclarations because the compiler is too stupid to figure out what I want to do'. To be precise, the languages themselves did not really teach me that much but the learning materials I used with those language did. When I need to do something small data processing in a jiffy I usually pick Python. For small programs few-liners in dynamic languages are usually a win.
px1999 12y ago
I'm working with a singlepage webapp that consists of ~1.5MLOC serverside(+other) and an additional ~100KLOC of javascript (not including libraries). Refactoring and maintaining consistency are the two big problems we have with Javascript. It's easy enough to write javascript that works and does what we need it to do. The challenges come in when you start having separate components that need to interoperate. eshint/jshint etc take you only so far (preventing you from dumping things into the global scope, avoiding typos). AMD etc can take you a bit further with async loading, and give a better [more consistent] pattern for exporting things than saying to devs "just put your stuff in an IIFE". FB Flow looks helpful, but it's trying to solve a difficult problem, and unfortunately doesn't work so well with our code thanks to ONE bad decision made a long time ago to rely on declaration hoisting ("unreachable code" :( ). Anyways, knowing that your code isn't going to work before you start spinning up the application saves a lot of time. Knowing that you can rename a method/function and have no undefined errors come out of it is great. Being able to look up usages of a method across the entire codebase is also useful. Eventually if Microsoft decide to spend resources on it, TypeScript might get CodeLens (which is on its own all manner of cool+useful). Having class syntax means that you don't need to worry about external consumers accessing properties that they shouldn't be (+gets rid of silly conventions like underscore private members/methods). JS is a great language, and it's powerful, but when you're writing large quantities of stuff, sometimes you need structure. Particularly when it's a large team and there are people of wildly varying experience, ranging from near-zero JS experience to people who have used it for a decade or more.
- jtwebman 12y ago
  Unit tests fix the changing methods issue as well as making sure it will run when you run it. Types don't save you from that anymore then JSLint would as both can have logic errors. Browserify can help with breaking your code down into smaller reusable modules for the client side and node you want to make your modules as small as possible? From the sounds of it you fell into the one big huge application that does everything problem instead of breaking it up. The same issues would have happen if you would have done that in any other language. Varying experience doesn't mean you can give them TypeScript or CoffeeScript and not mess something up. You should still put code reviews and training in place though I do agree JavaScript lets you shoot yourself in the foot much easier. You can hide variables through closures and sorry not a fan of getters and setters, I feel they are a anti-pattern (http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html http://www.yegor256.com/2014/09/16/getters-and-setters-are-e...). The one thing that would be nice would be knowing where your code is called. Though if you are using NPM and Browserify then that can be easier as well. I agree though that the tools are not as nice as Visual Studios find callers and the intellisense isn't that good ether but I am willing to trade them for the flexibility of not having to declare types and the simplicity of not having to work around types with generics, interfaces, and casting. So I think there is structure in Javascript you just have to learn the best ways of implementing it. Yes Javascript makes it a little easier to shoot yourself in the foot but you can still do it with CoffeeScript, TypeScript, or even in C# and Java, we learn from our mistakes. I fell to be successful in Javascript you really need to keep it small and re-factor often but that really is the same in all languages.

justathrow2k 12y ago

I don't think laziness or a lack of desire to learn java script is the driving force for these projects. Rather, its simply for people who prefer a facade of strong types over their java script.

jtwebman 12y ago
What do strong types get you? Being I write a bunch of C# at work and almost all JavaScript at home I find types very limiting, so I still don't get why?
- munificent 12y ago
  > all JavaScript at home Every language works pretty well for solo personal projects. It's when you scale up to dozens of team members and millions of lines of code that some things don't work as well.
- justathrow2k 12y ago
  I'm sorry, are you hoping I provide an all encompassing answer that convinces you of its usefulness? I can't provide that. Like I said, its simply a matter of personal preference. You find types limiting, others find them helpful.
- aquark 12y ago
  I find Typescript catches all sorts of typos that get missed in pure JS because I don't have 100% code coverage tests. Sure a JSLinter might catch some of those, but it won't find mis-spelled method names. Other benefits include not having to remember the 'interesting' rules around 'this' in pure JS (though that occassionally slips through in libraries that use it). Having saner (to my eyes) syntax for modules and encapsulation. And having intellisense support in Visual Studio reduces the effort of writing the code.
  - jtwebman 12y ago
    Both great points!
- fsloth 12y ago
  When I implement a type zoo that models the problem I am solving I do not need to spend as much time reasoning about the semantics (with a good IDE) and the compiler warns me if I've done something odd and won't run the program if I've done something wrong. With a strong typesystem I can first figure out what I need to do, then write it (like a fews of hundreds of lines), compile it and be fairly confident that the program runs almost correctly. Static typesystem does not help with the bugs that have to do with bugs in algorithms (wrong iteration order etc.) but it let's me concentrate on those parts mostly. Static typing also functions as a self documentation - I see the intended program flow from the type signatures and do not need other means necessarily to figure out what the program flow is. To me types are like lego bricks and dynamic languages are like ducktape - both have their uses.
  - jtwebman 12y ago
    I just find them hand holding and limiting.
    - fsloth 12y ago
      Well said! I love it when I can get the computer to hold my hand and limit my actions. Personally I feel the limits of my cognition and enjoy when the computer assists in proofing the correctness of my programs. That way I can be more sure I don't do anything that breaks the program logic and that developers that come after me remain within the boundaries of correctness when modifying my code. Types don't help in design but they help in forming a coherent whole. I've figured out there are two constraint systems I can use to effectively write correct programs. One of them is a typesystem and the second is set theory. Granted, the most mainstream statically typed languages come with so much syntactical baggage and lack type hinting (C++, Java, C#) that they can effectively hide the elegance of types as a problem modeling tool. Types can be used just as a non-value adding anal-retentive bureaucratic baggage but that's not how they should be used. I'm professionally mostly a C++ programmer but did not really 'get it' until I familiarized myself with functional languages (Ocaml, F#) which helped me understand how to actually leverage a typesystem to help me write correct code instead of 'just using typedeclarations because the compiler is too stupid to figure out what I want to do'. To be precise, the languages themselves did not really teach me that much but the learning materials I used with those language did. When I need to do something small data processing in a jiffy I usually pick Python. For small programs few-liners in dynamic languages are usually a win.

px1999 12y ago

I'm working with a singlepage webapp that consists of ~1.5MLOC serverside(+other) and an additional ~100KLOC of javascript (not including libraries). Refactoring and maintaining consistency are the two big problems we have with Javascript. It's easy enough to write javascript that works and does what we need it to do. The challenges come in when you start having separate components that need to interoperate. eshint/jshint etc take you only so far (preventing you from dumping things into the global scope, avoiding typos). AMD etc can take you a bit further with async loading, and give a better [more consistent] pattern for exporting things than saying to devs "just put your stuff in an IIFE". FB Flow looks helpful, but it's trying to solve a difficult problem, and unfortunately doesn't work so well with our code thanks to ONE bad decision made a long time ago to rely on declaration hoisting ("unreachable code" :( ). Anyways, knowing that your code isn't going to work before you start spinning up the application saves a lot of time. Knowing that you can rename a method/function and have no undefined errors come out of it is great. Being able to look up usages of a method across the entire codebase is also useful. Eventually if Microsoft decide to spend resources on it, TypeScript might get CodeLens (which is on its own all manner of cool+useful). Having class syntax means that you don't need to worry about external consumers accessing properties that they shouldn't be (+gets rid of silly conventions like underscore private members/methods). JS is a great language, and it's powerful, but when you're writing large quantities of stuff, sometimes you need structure. Particularly when it's a large team and there are people of wildly varying experience, ranging from near-zero JS experience to people who have used it for a decade or more.

jtwebman 12y ago
Unit tests fix the changing methods issue as well as making sure it will run when you run it. Types don't save you from that anymore then JSLint would as both can have logic errors. Browserify can help with breaking your code down into smaller reusable modules for the client side and node you want to make your modules as small as possible? From the sounds of it you fell into the one big huge application that does everything problem instead of breaking it up. The same issues would have happen if you would have done that in any other language. Varying experience doesn't mean you can give them TypeScript or CoffeeScript and not mess something up. You should still put code reviews and training in place though I do agree JavaScript lets you shoot yourself in the foot much easier. You can hide variables through closures and sorry not a fan of getters and setters, I feel they are a anti-pattern (http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html http://www.yegor256.com/2014/09/16/getters-and-setters-are-e...). The one thing that would be nice would be knowing where your code is called. Though if you are using NPM and Browserify then that can be easier as well. I agree though that the tools are not as nice as Visual Studios find callers and the intellisense isn't that good ether but I am willing to trade them for the flexibility of not having to declare types and the simplicity of not having to work around types with generics, interfaces, and casting. So I think there is structure in Javascript you just have to learn the best ways of implementing it. Yes Javascript makes it a little easier to shoot yourself in the foot but you can still do it with CoffeeScript, TypeScript, or even in C# and Java, we learn from our mistakes. I fell to be successful in Javascript you really need to keep it small and re-factor often but that really is the same in all languages.