7 ms·

Little bit off topic but is there anyone like me in community having a problem with liking javascript? I have worked with javascript for years but it was alway

Little bit off topic but is there anyone like me in community having a problem with liking javascript? I have worked with javascript for years but it was always for DOM manipulation. When it comes to building an app with javascript, i feel like it is too fragile to depend on. Anyone can help me to get rid of this feeling?

__mrwhite__ 12y ago
Any particular reason why you feel like server-side JavaScript feels fragile? Also if by DOM manipulation you mean libraries like jQuery, have you tried more declarative approaches found in frameworks like Angular and React?
- loxs 12y ago
  Few reasons: 1. Cooperative multitasking. Really? In 2014? Hello? 2. Weakest of weak typing. undefined is not a function? Anyone? 3. Everyone can override everything. 4. Conventions, that's the only way you can build software in JS. Anyone know of a person who doesn't break conventions? Having programmed in something like Erlang, which IMHO is the sanest technology available today for doing web, JS feels horrible.
  - throwawayaway 12y ago
    I struggled to find anything I liked about javascript. Other than ease of deployment.
    - mhd 12y ago
      For enterprise companies the ability to move programmers around from frontend to backend (or demand that they're doing both at the same time) is probably a benefit. Not a good idea, but that's rarely a hindrance for both enterprisey and startup "human resources" management. Reminds me a bit of how we treated torchbearers and henchmen in D&D...
    - kyllo 12y ago
      First-class functions and closures are nice if you're coming from Java.
      - empthought 12y ago
        Those are in Java now. Always have been, really, with a lot of boilerplate.
        woah 12y ago
        But really, anything in Java requires a lot of boilerplate.
        kyllo 12y ago
        No, they aren't. The only thing "first-class" in Java is classes. They added lambda expressions in Java 8 but they still must be defined inside of a class method. It is still illegal to define a function outside of a class in Java. And Java methods are still not lexical closures; there are some tricks you can do to sort-of emulate this but closures are not a language feature.
        empthought 12y ago
        > The only thing "first-class" in Java is classes. And lo and behold, they have decided that an anonymous class with only one method is equivalent to an anonymous function object, and given us syntactic sugar to invoke it without the class declaration boilerplate. You're essentially doing the same as complaining that conditionals aren't a Smalltalk language feature.
        kyllo 12y ago
        An anonymous inner class with only one method. The "inner" is important. It still has to exist inside of an explicitly declared class. Also, a variable holding a reference to a lambda function cannot be called as a function (no function pointers). Contrast with JavaScript, where functions are first-class, can be declared at top level, can be passed as arguments to and returned by other functions, can be called by dereferencing a variable, can be nested, can be partially applied, etc. The minimal syntactic sugar for anonymous inner classes added in Java 8 doesn't even begin to approach the power of the function support in languages like JavaScript. Language-level support for this stuff matters.
  - timothya 12y ago
    1. This is rarely a problem. You want to be careful about writing code that will take a long time to execute, but most long-running APIs are async which helps a lot. 2. Weak typing is a nice feature for prototyping, but for larger projects, a stronger type system is better at catching bugs. Many JavaScript programmers (myself included) are used to using separate systems to check types for them. My team uses the Closure Compiler, which, along with compiling the JS to a more optimized version, is also happy to check all your types and fails to build if your types don't line up. 3. Again, I believe this is something that you can make sure that the compiler catches. And, of course, anyone can write bad code (in any language); if you're overwriting stuff halfway across the codebase, then that's "bad code" and you should avoid doing that (and during the code review stage, you should be making sure that your coworkers don't do that either). 4. Like for any language, have guidelines for how you write code, and enforce some of your conventions with the compiler and with linting tools. It leads to a more consistent codebase.
  - jonesetc 12y ago
    > 1. Cooperative multitasking. Really? In 2014? Hello? I find this sentiment odd. Obviously it's not ideal for many workloads, but for some things it's the sane option. I work with Tornado in python at work and cooperative multitasking is probably the thing I'm thankful for the most. The server is very IO bound, so it keeps logic seemingly synchronous but hasn't shown any throughput issues thus far.
  - deleted 12y ago
    [deleted]
  - stepstep 12y ago
    All of these are valid points except 1. Node's async IO is one of its strengths. Contrast with Rails, for example, where the standard practice for concurrency is to spawn multiple processes (or, less commonly, threads). How many Rails processes can you fit on one machine? 5-10? Node can handle thousands of concurrent connections, all on a single thread. And when you hit those limits, you can always continue scaling with multiple processes like you would with Rails. Doing CPU-bound computation in your application server is an anti-pattern. IO-bound computation, however, is where Node excels. The thing to realize is that pre-emptive multitasking is costly. It is convenient for the programmer (the programmer doesn't need to worry about blocking and locking up the rest of the program), but it comes at a cost. Lightweight "green" threads, or equivalently, Node's evented dispatch mechanism, are a much more efficient use of the CPU. For applications composed of short-lived computations (e.g., < 1ms), it doesn't make sense to interrupt them and context switch. It's more performant to let them complete and then switch. You just have to make sure you aren't doing any CPU-intensive computations in the app server—which you probably shouldn't be doing anyway. The downside of Node's approach is callback hell. And that's why we have Go.
    - phamilton 12y ago
      loxs argument (and as an Elixir guy I fully agree with him) is that those options are all terrible. The Erlang VM (BEAM) is extraordinary in how it solves that problem. It's both preemptive and green threads. It supports SMP and clusters across nodes out of the box. I highly recommend taking a look at BEAM and how different it is from everything else out there.
    - loxs 12y ago
      Cooperative vs. Preemptive multitasking is not the same as Light threads vs. OS threads/processes. Erlang (and also Haskell for example) does preemptive multitasking with light threads. And that's what I'm talking about. Yeah, preemptive multitasking may be costly. But as you say, when you have lots of users, most of their tasks are sleeping or waiting for timers. That's where preemptive multitasking excels. You can have millions of sleeping tasks and several (at times) doing real work. That's why Erlang is "scalable" and node.js is not. Especially if you need to have state in your workers and if you need them to live longer. Saying that node's cooperative multitasking excels in IO-bound computation is a clear sign that you haven't tried Erlang.
  - twerquie 12y ago
    I'm no zealot, and don't think these are absolute truths by any means but I've worked extensively on enterprise solutions in both C#/.Net and Node.js and can respond to your points below. 1. It turns out the reactor pattern is a good way to build network servers that scale reasonably well with minimal developer effort. In my experience developers tend to avoid writing threaded code in synchronous languages, and threads don't show up very often in run-of-the-mill solutions. To be sure, JavaScript's lack of threads is a blemish, but oddly it forced the community to focus heavily on distributed architectures, and as a result most of the tooling encourages distributed systems, which is a win for some common use cases. 2. Type safety is a hotly debated topic and I don't think you can find resolution on this one. For some people, "weakest of weak typing" is a benefit. 3. Static vs. dynamic, see #2. 4. Do you mean that everything must be enforced by convention instead of static code analysis, compile-time checks and type safety? If so, I think you're making the same point three times. Erlang is a beautiful language and may be the most correct in some sense, but doesn't look nearly as attractive to the kinds of teams I work on when you start to consider developer availability, library ecosystem, tooling, ISP support, documentation and community.
    - romaniv 12y ago
      I think your answers to 2-3 are not real answers. You're not giving an explanation that would convince someone who doesn't share your opinion. You're simply saying that you don't care about there concerns with nothing to demonstrate that your viewpoint is somehow more valid.
      - twerquie 12y ago
        I'm just conceding that these argument cannot be won. Tomes have been written and the argument becomes unproductive very quickly. It's like people who believe in God arguing with those who do not. It's not about JavaScript or Node, it's about your entire belief system. They're both good, in both cases.
      - woah 12y ago
        Are you really trying to get into a strong/weak typing argument here? Please. Take it elsewhere.
  - nwienert 12y ago
    I think really what happens is Node enables a new type of stack[1]. It doesn't actually really step on anything new the SPA's aren't already doing. Instead it moves to become isomorphic, so initial render is done by Node, but still the data sources, validation, and heavy backend logic all stays behind an API. That API could certainly be Erlang powered. Also to respond to your points... 1. This I see as the most valid argument, but not a deal-breaker (see Walmart, LinkedIn using Node without problems scaling). 2. Check out Flow by Facebook [2] or TypeScript. 3. Not true with require/modules. 4. It's incredibly easy to include a JSLint file in your repo and as a git hook. [1] http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/ http://nerds.airbnb.com/isomorphic-javascript-future-web-app... [2] http://flowtype.org/ http://flowtype.org/
  - Kiro 12y ago
    > Having programmed in something like Erlang, which IMHO is the sanest technology available today for doing web Erlang feels very complicated. I mainly build simple CRUD apps. Would I still benefit from using Erlang?
  - spion 12y ago
    1. Yeah, Erlang beats JS in that regard without contest. Still, its better than and conditions race deadlocks. (Few mainstream platforms solve this really well and Erlang is one of them). 2,3,4. TypeScript, Flow, PureScript add varying degrees of strictness, checking and purity (from low to high, in that order)
- rtpg 12y ago
  not OP, but some issues I get with JS are mainly due to refactoring. I think the tooling isn't as mature as in other languages, and moving around code has proven difficult (oh the joys of `this`!) Software development is one part creation, one part understanding existing software, and one part changing existing stuff. Javascript has proven a bit difficult on the last part.
  - woah 12y ago
    This is likely an issue caused by code that is too monolithic in nature. Writing idiomatic node code involves making many small npm modules. Refactoring becomes very easy within the tiny code base of a module, and moving them around is a matter of require them somewhere else.
    - tracker1 12y ago
      Not just via npm, but structuring your project via directory/file hierarchies that limit the amount of work in one file/module. Avoiding the use of OO contexts and this helps a lot in terms of avoiding side effects, and improving testing and predictability as well.
Igglyboo 12y ago
I'm in the same boat. It's a necessary evil though and it's not going anywhere anytime soon so I try and force myself to like it, CoffeeScript helps, planning to try out TypeScript soon as well.
virmundi 12y ago
I'm working on it now. https://leanpub.com/javascriptesbasuracaliente https://leanpub.com/javascriptesbasuracaliente. I don't think you can necessarily overcome the deep-seated knowledge that the language is hot garbage. You can learn to use tools to reduce it and understand the language enough to realize where its truly horrific spots.
gdulli 12y ago
I don't find it fragile but like Java, PHP, and Perl it's also just not a pleasure to use the way Python is due to Python's design and quality of its community packages.
calebm 12y ago
I've been leaning toward functional programming and libraries-over-frameworks for a while now (influenced largely by the Clojure community), and when I realized that the Javascript world embraces these views, I was able to make peace with Javascript.
swah 12y ago
For the browser, no. Its native there and that's fine by me. But on the server, yes, I have that feeling.
romaniv 12y ago
Same here, to a greater extent. Why? At the highest level, because it's a language that was chosen based on a whim (not merit) and is now being extensively worked on and showed down everyone's throats. I like languages, plural. I like new languages. I like to have a choice. (And no, I cannot "simply chose something else" if I have to work with people who say every other choice is invalid by default. And yes, this is the mentality I commonly see.) In a way, JavaScript is the new Java. The core language (syntax, available directives) hasn't changed much since the time everyone deservedly hated it. Its performance was optimized, it got many more libraries and it is still the only language supported by browsers. But the question is, why all of this applies to JavaScript and not Python/Ruby/whatever? A lot of its benefits people claim simply weren't around when they chose to stick with it. It's like saying you chose IIS over Apache because of features of C# 5.0 and ignoring the fact that you chose IIS in 2004, where C# 5.0 was not around. It's a dishonest argument. Speaking of which. How can people claim that JS benefits from the same language running on client and server when 90% of server-side libraries do not work on the client and there are potentially major differences even in core library (e.g. forEach)? Also, a huge part of JS ecosystem are kludges, crutches and workarounds that make the stack way, way more complex that it should be. (E.g. source maps. Imagine someone minifying PHP for faster parsing and then asking everyone to use some source mapping technology for debugging. They would be laughed out of any conference or discussion.) This mentality permeates everything. I mean, seriously, require directives need to be implemented as a library? Namespace isolation is a closure-based hack? Can you imaging stuff like that being tolerate for any other language?
- woah 12y ago
  Are you kidding me? Source maps allow you to debug preprocessed as well as minified code. This allows seamless integration of multiple languages into the same ecosystem, libraries, etc.
  - romaniv 12y ago
    You develop a language that is sent to the client in plain text. Then you write a lot of code in it. Then you realize that with so much code, file transfers take too long. You write a utility to strip out spaces and comments, as well as change variable names so files are smaller. Okay, so now you have unreadable plaintext files. After juggling minified and unminified version of the same code for some years you realize that debugging like that sucks. You develop a new format that allows you to map minified and unminified files. This format requires support on the browser side, as well as in the minification utility, and it also requires the author of the minified library to provide you with two additional files. You declare victory and pat yourself on the back. The whole process only takes a few years. Meanwhile, people debugged binaries for several decades before your language even been developed. Do you see anything wrong with this picture?
marknutter 12y ago
Are you kidding? I can't remember the last time a node.js or javascript related article on the HN homepage didn't have a barrage of highly up-voted "javascript sucks" themed comments. I'm beginning to wonder the opposite - is there anyone like me in the community that doesn't have a problem liking javascript?
- serve_yay 12y ago
  No kidding.

__mrwhite__ 12y ago

Any particular reason why you feel like server-side JavaScript feels fragile? Also if by DOM manipulation you mean libraries like jQuery, have you tried more declarative approaches found in frameworks like Angular and React?

loxs 12y ago
Few reasons: 1. Cooperative multitasking. Really? In 2014? Hello? 2. Weakest of weak typing. undefined is not a function? Anyone? 3. Everyone can override everything. 4. Conventions, that's the only way you can build software in JS. Anyone know of a person who doesn't break conventions? Having programmed in something like Erlang, which IMHO is the sanest technology available today for doing web, JS feels horrible.
- throwawayaway 12y ago
  I struggled to find anything I liked about javascript. Other than ease of deployment.
  - mhd 12y ago
    For enterprise companies the ability to move programmers around from frontend to backend (or demand that they're doing both at the same time) is probably a benefit. Not a good idea, but that's rarely a hindrance for both enterprisey and startup "human resources" management. Reminds me a bit of how we treated torchbearers and henchmen in D&D...
  - kyllo 12y ago
    First-class functions and closures are nice if you're coming from Java.
    - empthought 12y ago
      Those are in Java now. Always have been, really, with a lot of boilerplate.
      - woah 12y ago
        But really, anything in Java requires a lot of boilerplate.
      - kyllo 12y ago
        No, they aren't. The only thing "first-class" in Java is classes. They added lambda expressions in Java 8 but they still must be defined inside of a class method. It is still illegal to define a function outside of a class in Java. And Java methods are still not lexical closures; there are some tricks you can do to sort-of emulate this but closures are not a language feature.
        empthought 12y ago
        > The only thing "first-class" in Java is classes. And lo and behold, they have decided that an anonymous class with only one method is equivalent to an anonymous function object, and given us syntactic sugar to invoke it without the class declaration boilerplate. You're essentially doing the same as complaining that conditionals aren't a Smalltalk language feature.
        kyllo 12y ago
        An anonymous inner class with only one method. The "inner" is important. It still has to exist inside of an explicitly declared class. Also, a variable holding a reference to a lambda function cannot be called as a function (no function pointers). Contrast with JavaScript, where functions are first-class, can be declared at top level, can be passed as arguments to and returned by other functions, can be called by dereferencing a variable, can be nested, can be partially applied, etc. The minimal syntactic sugar for anonymous inner classes added in Java 8 doesn't even begin to approach the power of the function support in languages like JavaScript. Language-level support for this stuff matters.
- timothya 12y ago
  1. This is rarely a problem. You want to be careful about writing code that will take a long time to execute, but most long-running APIs are async which helps a lot. 2. Weak typing is a nice feature for prototyping, but for larger projects, a stronger type system is better at catching bugs. Many JavaScript programmers (myself included) are used to using separate systems to check types for them. My team uses the Closure Compiler, which, along with compiling the JS to a more optimized version, is also happy to check all your types and fails to build if your types don't line up. 3. Again, I believe this is something that you can make sure that the compiler catches. And, of course, anyone can write bad code (in any language); if you're overwriting stuff halfway across the codebase, then that's "bad code" and you should avoid doing that (and during the code review stage, you should be making sure that your coworkers don't do that either). 4. Like for any language, have guidelines for how you write code, and enforce some of your conventions with the compiler and with linting tools. It leads to a more consistent codebase.
- jonesetc 12y ago
  > 1. Cooperative multitasking. Really? In 2014? Hello? I find this sentiment odd. Obviously it's not ideal for many workloads, but for some things it's the sane option. I work with Tornado in python at work and cooperative multitasking is probably the thing I'm thankful for the most. The server is very IO bound, so it keeps logic seemingly synchronous but hasn't shown any throughput issues thus far.
- deleted 12y ago
  [deleted]
- stepstep 12y ago
  All of these are valid points except 1. Node's async IO is one of its strengths. Contrast with Rails, for example, where the standard practice for concurrency is to spawn multiple processes (or, less commonly, threads). How many Rails processes can you fit on one machine? 5-10? Node can handle thousands of concurrent connections, all on a single thread. And when you hit those limits, you can always continue scaling with multiple processes like you would with Rails. Doing CPU-bound computation in your application server is an anti-pattern. IO-bound computation, however, is where Node excels. The thing to realize is that pre-emptive multitasking is costly. It is convenient for the programmer (the programmer doesn't need to worry about blocking and locking up the rest of the program), but it comes at a cost. Lightweight "green" threads, or equivalently, Node's evented dispatch mechanism, are a much more efficient use of the CPU. For applications composed of short-lived computations (e.g., < 1ms), it doesn't make sense to interrupt them and context switch. It's more performant to let them complete and then switch. You just have to make sure you aren't doing any CPU-intensive computations in the app server—which you probably shouldn't be doing anyway. The downside of Node's approach is callback hell. And that's why we have Go.
  - phamilton 12y ago
    loxs argument (and as an Elixir guy I fully agree with him) is that those options are all terrible. The Erlang VM (BEAM) is extraordinary in how it solves that problem. It's both preemptive and green threads. It supports SMP and clusters across nodes out of the box. I highly recommend taking a look at BEAM and how different it is from everything else out there.
  - loxs 12y ago
    Cooperative vs. Preemptive multitasking is not the same as Light threads vs. OS threads/processes. Erlang (and also Haskell for example) does preemptive multitasking with light threads. And that's what I'm talking about. Yeah, preemptive multitasking may be costly. But as you say, when you have lots of users, most of their tasks are sleeping or waiting for timers. That's where preemptive multitasking excels. You can have millions of sleeping tasks and several (at times) doing real work. That's why Erlang is "scalable" and node.js is not. Especially if you need to have state in your workers and if you need them to live longer. Saying that node's cooperative multitasking excels in IO-bound computation is a clear sign that you haven't tried Erlang.
- twerquie 12y ago
  I'm no zealot, and don't think these are absolute truths by any means but I've worked extensively on enterprise solutions in both C#/.Net and Node.js and can respond to your points below. 1. It turns out the reactor pattern is a good way to build network servers that scale reasonably well with minimal developer effort. In my experience developers tend to avoid writing threaded code in synchronous languages, and threads don't show up very often in run-of-the-mill solutions. To be sure, JavaScript's lack of threads is a blemish, but oddly it forced the community to focus heavily on distributed architectures, and as a result most of the tooling encourages distributed systems, which is a win for some common use cases. 2. Type safety is a hotly debated topic and I don't think you can find resolution on this one. For some people, "weakest of weak typing" is a benefit. 3. Static vs. dynamic, see #2. 4. Do you mean that everything must be enforced by convention instead of static code analysis, compile-time checks and type safety? If so, I think you're making the same point three times. Erlang is a beautiful language and may be the most correct in some sense, but doesn't look nearly as attractive to the kinds of teams I work on when you start to consider developer availability, library ecosystem, tooling, ISP support, documentation and community.
  - romaniv 12y ago
    I think your answers to 2-3 are not real answers. You're not giving an explanation that would convince someone who doesn't share your opinion. You're simply saying that you don't care about there concerns with nothing to demonstrate that your viewpoint is somehow more valid.
    - twerquie 12y ago
      I'm just conceding that these argument cannot be won. Tomes have been written and the argument becomes unproductive very quickly. It's like people who believe in God arguing with those who do not. It's not about JavaScript or Node, it's about your entire belief system. They're both good, in both cases.
    - woah 12y ago
      Are you really trying to get into a strong/weak typing argument here? Please. Take it elsewhere.
- nwienert 12y ago
  I think really what happens is Node enables a new type of stack[1]. It doesn't actually really step on anything new the SPA's aren't already doing. Instead it moves to become isomorphic, so initial render is done by Node, but still the data sources, validation, and heavy backend logic all stays behind an API. That API could certainly be Erlang powered. Also to respond to your points... 1. This I see as the most valid argument, but not a deal-breaker (see Walmart, LinkedIn using Node without problems scaling). 2. Check out Flow by Facebook [2] or TypeScript. 3. Not true with require/modules. 4. It's incredibly easy to include a JSLint file in your repo and as a git hook. [1] http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/ http://nerds.airbnb.com/isomorphic-javascript-future-web-app... [2] http://flowtype.org/ http://flowtype.org/
- Kiro 12y ago
  > Having programmed in something like Erlang, which IMHO is the sanest technology available today for doing web Erlang feels very complicated. I mainly build simple CRUD apps. Would I still benefit from using Erlang?
- spion 12y ago
  1. Yeah, Erlang beats JS in that regard without contest. Still, its better than and conditions race deadlocks. (Few mainstream platforms solve this really well and Erlang is one of them). 2,3,4. TypeScript, Flow, PureScript add varying degrees of strictness, checking and purity (from low to high, in that order)
rtpg 12y ago
not OP, but some issues I get with JS are mainly due to refactoring. I think the tooling isn't as mature as in other languages, and moving around code has proven difficult (oh the joys of `this`!) Software development is one part creation, one part understanding existing software, and one part changing existing stuff. Javascript has proven a bit difficult on the last part.
- woah 12y ago
  This is likely an issue caused by code that is too monolithic in nature. Writing idiomatic node code involves making many small npm modules. Refactoring becomes very easy within the tiny code base of a module, and moving them around is a matter of require them somewhere else.
  - tracker1 12y ago
    Not just via npm, but structuring your project via directory/file hierarchies that limit the amount of work in one file/module. Avoiding the use of OO contexts and this helps a lot in terms of avoiding side effects, and improving testing and predictability as well.

Igglyboo 12y ago

I'm in the same boat. It's a necessary evil though and it's not going anywhere anytime soon so I try and force myself to like it, CoffeeScript helps, planning to try out TypeScript soon as well.

virmundi 12y ago

I'm working on it now. https://leanpub.com/javascriptesbasuracaliente https://leanpub.com/javascriptesbasuracaliente. I don't think you can necessarily overcome the deep-seated knowledge that the language is hot garbage. You can learn to use tools to reduce it and understand the language enough to realize where its truly horrific spots.

gdulli 12y ago

I don't find it fragile but like Java, PHP, and Perl it's also just not a pleasure to use the way Python is due to Python's design and quality of its community packages.

calebm 12y ago

I've been leaning toward functional programming and libraries-over-frameworks for a while now (influenced largely by the Clojure community), and when I realized that the Javascript world embraces these views, I was able to make peace with Javascript.

swah 12y ago

For the browser, no. Its native there and that's fine by me. But on the server, yes, I have that feeling.

romaniv 12y ago

Same here, to a greater extent. Why? At the highest level, because it's a language that was chosen based on a whim (not merit) and is now being extensively worked on and showed down everyone's throats. I like languages, plural. I like new languages. I like to have a choice. (And no, I cannot "simply chose something else" if I have to work with people who say every other choice is invalid by default. And yes, this is the mentality I commonly see.) In a way, JavaScript is the new Java. The core language (syntax, available directives) hasn't changed much since the time everyone deservedly hated it. Its performance was optimized, it got many more libraries and it is still the only language supported by browsers. But the question is, why all of this applies to JavaScript and not Python/Ruby/whatever? A lot of its benefits people claim simply weren't around when they chose to stick with it. It's like saying you chose IIS over Apache because of features of C# 5.0 and ignoring the fact that you chose IIS in 2004, where C# 5.0 was not around. It's a dishonest argument. Speaking of which. How can people claim that JS benefits from the same language running on client and server when 90% of server-side libraries do not work on the client and there are potentially major differences even in core library (e.g. forEach)? Also, a huge part of JS ecosystem are kludges, crutches and workarounds that make the stack way, way more complex that it should be. (E.g. source maps. Imagine someone minifying PHP for faster parsing and then asking everyone to use some source mapping technology for debugging. They would be laughed out of any conference or discussion.) This mentality permeates everything. I mean, seriously, require directives need to be implemented as a library? Namespace isolation is a closure-based hack? Can you imaging stuff like that being tolerate for any other language?

woah 12y ago
Are you kidding me? Source maps allow you to debug preprocessed as well as minified code. This allows seamless integration of multiple languages into the same ecosystem, libraries, etc.
- romaniv 12y ago
  You develop a language that is sent to the client in plain text. Then you write a lot of code in it. Then you realize that with so much code, file transfers take too long. You write a utility to strip out spaces and comments, as well as change variable names so files are smaller. Okay, so now you have unreadable plaintext files. After juggling minified and unminified version of the same code for some years you realize that debugging like that sucks. You develop a new format that allows you to map minified and unminified files. This format requires support on the browser side, as well as in the minification utility, and it also requires the author of the minified library to provide you with two additional files. You declare victory and pat yourself on the back. The whole process only takes a few years. Meanwhile, people debugged binaries for several decades before your language even been developed. Do you see anything wrong with this picture?

marknutter 12y ago

Are you kidding? I can't remember the last time a node.js or javascript related article on the HN homepage didn't have a barrage of highly up-voted "javascript sucks" themed comments. I'm beginning to wonder the opposite - is there anyone like me in the community that doesn't have a problem liking javascript?

serve_yay 12y ago
No kidding.