5 ms·

I have written maybe 200 lines of JavaScript in my life, and this article has strongly reinforced my desire to never have to write a single one more. The next t

by wz1000 8y ago

I have written maybe 200 lines of JavaScript in my life, and this article has strongly reinforced my desire to never have to write a single one more. The next time someone asks me what the problem with JavaScript is, I will send them this article. "Scheme for the browser" what a joke. Some excerpts for those that didn't have the strength to sit through the entire thing without pulling their hair out: > If you called Person('Fred') without new, this inside it would point to something global and useless (for example, window or undefined). So our code would crash or do something silly like setting window.name. > However, JavaScript also allows a function called with new to override the return value of new by returning some other object. Presumably, this was considered useful for patterns like pooling where we want to reuse instances: > However, new also completely ignores a function’s return value if it’s not an object. If you return a string or a number, it’s like there was no return at all. > And yet I still find it very confusing that a property called prototype does not give you a value’s prototype (for example, fred.prototype is undefined because fred is not a function). Personally, I think this is the biggest reason even experienced developers tend to misunderstand JavaScript prototypes. > However, some class implementations we wanted to target did not copy static properties (or set the non-standard __proto__), so the flag was getting lost Edit: And I missed the best/worst one yet: You can have MULTIPLE VERSIONS of the SAME DEPENDENCY running around in your codebase, interacting in ways that only god knows. In retrospect, this should have been obvious from the way javascript "imports" work, but, holy shit! If Satan himself had to design a language, he could not have done a better job. And I'm sure he would not have the stroke of genius required to make it the only programming language you can use if you want to target the most widely available platform for code in the world. The next time I have to allow NoScript to let some js in, I will wonder how many goat sacrifices went into making the thing work.

acemarke 8y ago
One of the points of the post was that you almost definitely don't need to worry about this yourself, especially if you're using React.
- wz1000 8y ago
  If you're going to be using any language seriously, you better understand how functions and objects and classes in that language work.
  - deleted 8y ago
    [deleted]
  - thatswrong0 8y ago
    I’ve been writing React for 3ish years and not once would knowing any of the weird details in the blog post have been useful for anything I’ve built.
  - adjkant 8y ago
    In most cases I'd agree, but essentially JS has gotten to the point that it's only usable if you write an entirely new language on top of it, like React/Vue/Angular have. All of them are basically to avoid the confusion that arises from the weird quirks of JS, like it's classes implementation. These languages then also try to integrate the few positives of JS into their paradigms, and IMO they are decently successful to the point of usability for a frontend.
    - pests 8y ago
      I don't understand how "React/Vue/Angular" is considered "an entirely new language." I use React primarily, so I'm going to speak from knowledge of that. It is very obviously a framework and it does one thing - handle your view. Depending on what you are doing, you may have very little react-specific code in your application. You have data fetching, caching, persistence, authentication, tons of things, not to mention business logic that needs to be implemented in just plain Javascript. Then out of that process you may have workers or other async background jobs happening which should not involve React at all.
      - reificator 8y ago
        While I agree with your point, your example of React literally adds a DSL that requires a pre-compilation step. It's not required[0], I get that, but it's still a new language. [0]: It may not be required, but it was created for a reason....
ttty2 8y ago
You don't write js because you like, is because is a competitive advantage: - Write in one language only for both client and server side. Why is good? You just need js devs, no need to duplicate validation and other logic. I'm making a game right now and has js on the backend. I want to make the game single player, now I can just import a file from the client side and <<Boom!>> now is single player. If your backend is in java, good luck to make it single player. - Compare a website to an installable app. Who is more likely to gain more customers all things being equal? If you click on a link from google, is more likely to browse a website rather than installing an app. You could compile java to js, but is a nightmare to debug and you are far away from the real code. You will have a lot of issues. There are more benefits of js of course.
- adjkant 8y ago
  I really don't get how JS on the client and the server is any real advantage - besides sharing some syntax, the models and paradigms are so drastically different it might as well be two different languages. Why make the server so bad when you don't have to? I think JS has its place despite it's flaws, but for the sake of sanity I can't imagine ever using it on the backend by choice. If you want the ease of express, use Flask. If you can't write your backend in something else and use the same devs, you have bad devs. It's not that hard to pick up a language if you understand the concepts needed to write a client and a server.
  - deleted 8y ago
    [deleted]
  - thinkloop 8y ago
    The backed's job is to give the frontend what it needs, so at some point it has to make the objects that the fontend will consume and instantiate. That point at which the two realms join is a source of lots of potential reuse, from model objects, to the business rules surrounding their use and structure. Also consider things like validation, javascript-driven server-side rendering, etc
  - finchisko 8y ago
reificator 8y ago
I've written many times that, and I don't hate the language. But man does it have some footguns. Tools without flaws are not the tools that get used for real work. Sometimes you have to suck it up and learn the quirks in the tools you have. That's not to discourage work on improving the current situation, just an observation on practicality.
ta567657567 8y ago
I don't understand why you're getting downvoted, completely agree. I'm hoping WebASM can save the browser from this foul language. Don't even get me started on server-side JS; if it were a nice, sane scripting language, I'd agree, but the amount of hoops, translators, hackish dev tools etc that have been thrown into the mix to wrangle it into a workable experience... it's too much.
- ravenstine 8y ago
  I get your hope for WASM, but I'm not so optimistic. That's not because I don't think that WASM would allow for "better" languages(I personally like and prefer JavaScript), but the future you are suggesting might cause even more fracturing in the web development community than already exists with frameworks and changes in ECMAScript. Arguably, such fracturing already exists with frontend frameworks. But what will that be like when we become fractured by language? Plenty of people like and prefer JavaScript, but seem to be at least as many people who would rather use an entirely different language on the frontend. I know someone will want to chime in and point out that WASM will still need to interact with JavaScript, but that's not really the point; once JavaScript as a language can be effectively ignored by the developer, that complicates our occupation in terms of interoperability. One of the great things about web development was that workflows could be different but, at the end of the day, the end product is(was?) essentially HTML, CSS, and JavaScript. There were only so many languages we needed to learn in order to write servers, and at the end of the day we just needed to make something respond to HTTP requests. I chose web development because it wasn't going to pigeonhole me as much as other fields of software engineering; one can, or could, take their web development skills from one company and easily apply them to another, no matter the scale. Today, we have a constantly evolving browser language, several frontend frameworks and rendering libraries, not just PHP; ASP; and Perl for the server but Python; Ruby; Java; Elixir; Node.js; Groovy, and a wide variety of toolchains and transpilation setups. Now, we're going to open the frontend floodgates to different language runtimes, and along with them even more frontend debugging tools? This field is becoming way less fun. It's not that I don't understand the desire for choice or to simply not use JavaScript, but I doubt that as humans we won't naturally take the freedom given to us and use it to our detriment.
danabramov 8y ago
Author here :-) I don't think I disagree with you. JS has its warts and some of them are... weird. The web delivery mechanism has always been its killer feature, not the language. And for web delivery mechanism to work, it needs to maintain backwards compatibility. In practice, however, I think a lot of these things become irrelevant because JS subcommunities carve out reasonable subsets of the language. For example when using React you almost never need to care about prototypal (or even normal) inheritance because it's explicitly discouraged by React. And in the future, we might not need to encourage classes when writing components altogether. If you limit yourself to avoiding some features then it's not such a bad language after all.
- perfunctory 8y ago
  > If you limit yourself to avoiding some features then it's not such a bad language after all. Unfortunately that's not possible unless you never interoperate with other code.
tannhaeuser 8y ago
I'd say JavaScript works well enough for its original goal - simple DOM manipulation in response to UI events. IMHO the trouble comes from folks who want to use it for all kinds of over-reaching frameworks. The moment you have to discuss enumerating properties of classes, prototypes, etc., JavaScript's lack of typing becomes painfully obvious and there are just much better languages to spend your time on. I also like the original practical vision for node.js/CommonJS as an escape from the metaprogramming excess that has become Java.
perfunctory 8y ago
I guess your downvoters have some sort of Stockholm syndrome. Javascript is a giant mess and all attempts to fix it seem to make it even worse. Having a sane language in the browser would be the single biggest boost to overall productivity. That alone would push the global gdp up by 5%. At the very least.
- fitpolar 8y ago
  You can’t critique Javascript. It’s one of the unspoken laws of the internet, but consistent with it reaching religious status. The “Javascript blasphemy must be silenced” crowd is a huge reason why we have this problem. The culture reminds me of Flash 10 years ago. It’s incredibly ironic, they’re their own worst enemies. Fortunately we now have WASM...

by wz1000 8y ago

acemarke 8y ago

One of the points of the post was that you almost definitely don't need to worry about this yourself, especially if you're using React.

wz1000 8y ago
If you're going to be using any language seriously, you better understand how functions and objects and classes in that language work.
- deleted 8y ago
  [deleted]
- thatswrong0 8y ago
  I’ve been writing React for 3ish years and not once would knowing any of the weird details in the blog post have been useful for anything I’ve built.
- adjkant 8y ago
  In most cases I'd agree, but essentially JS has gotten to the point that it's only usable if you write an entirely new language on top of it, like React/Vue/Angular have. All of them are basically to avoid the confusion that arises from the weird quirks of JS, like it's classes implementation. These languages then also try to integrate the few positives of JS into their paradigms, and IMO they are decently successful to the point of usability for a frontend.
  - pests 8y ago
    I don't understand how "React/Vue/Angular" is considered "an entirely new language." I use React primarily, so I'm going to speak from knowledge of that. It is very obviously a framework and it does one thing - handle your view. Depending on what you are doing, you may have very little react-specific code in your application. You have data fetching, caching, persistence, authentication, tons of things, not to mention business logic that needs to be implemented in just plain Javascript. Then out of that process you may have workers or other async background jobs happening which should not involve React at all.
    - reificator 8y ago
      While I agree with your point, your example of React literally adds a DSL that requires a pre-compilation step. It's not required[0], I get that, but it's still a new language. [0]: It may not be required, but it was created for a reason....

ttty2 8y ago

You don't write js because you like, is because is a competitive advantage: - Write in one language only for both client and server side. Why is good? You just need js devs, no need to duplicate validation and other logic. I'm making a game right now and has js on the backend. I want to make the game single player, now I can just import a file from the client side and <<Boom!>> now is single player. If your backend is in java, good luck to make it single player. - Compare a website to an installable app. Who is more likely to gain more customers all things being equal? If you click on a link from google, is more likely to browse a website rather than installing an app. You could compile java to js, but is a nightmare to debug and you are far away from the real code. You will have a lot of issues. There are more benefits of js of course.

adjkant 8y ago
I really don't get how JS on the client and the server is any real advantage - besides sharing some syntax, the models and paradigms are so drastically different it might as well be two different languages. Why make the server so bad when you don't have to? I think JS has its place despite it's flaws, but for the sake of sanity I can't imagine ever using it on the backend by choice. If you want the ease of express, use Flask. If you can't write your backend in something else and use the same devs, you have bad devs. It's not that hard to pick up a language if you understand the concepts needed to write a client and a server.
- deleted 8y ago
  [deleted]
- thinkloop 8y ago
  The backed's job is to give the frontend what it needs, so at some point it has to make the objects that the fontend will consume and instantiate. That point at which the two realms join is a source of lots of potential reuse, from model objects, to the business rules surrounding their use and structure. Also consider things like validation, javascript-driven server-side rendering, etc
- finchisko 8y ago

reificator 8y ago

I've written many times that, and I don't hate the language. But man does it have some footguns. Tools without flaws are not the tools that get used for real work. Sometimes you have to suck it up and learn the quirks in the tools you have. That's not to discourage work on improving the current situation, just an observation on practicality.

ta567657567 8y ago

I don't understand why you're getting downvoted, completely agree. I'm hoping WebASM can save the browser from this foul language. Don't even get me started on server-side JS; if it were a nice, sane scripting language, I'd agree, but the amount of hoops, translators, hackish dev tools etc that have been thrown into the mix to wrangle it into a workable experience... it's too much.

ravenstine 8y ago
I get your hope for WASM, but I'm not so optimistic. That's not because I don't think that WASM would allow for "better" languages(I personally like and prefer JavaScript), but the future you are suggesting might cause even more fracturing in the web development community than already exists with frameworks and changes in ECMAScript. Arguably, such fracturing already exists with frontend frameworks. But what will that be like when we become fractured by language? Plenty of people like and prefer JavaScript, but seem to be at least as many people who would rather use an entirely different language on the frontend. I know someone will want to chime in and point out that WASM will still need to interact with JavaScript, but that's not really the point; once JavaScript as a language can be effectively ignored by the developer, that complicates our occupation in terms of interoperability. One of the great things about web development was that workflows could be different but, at the end of the day, the end product is(was?) essentially HTML, CSS, and JavaScript. There were only so many languages we needed to learn in order to write servers, and at the end of the day we just needed to make something respond to HTTP requests. I chose web development because it wasn't going to pigeonhole me as much as other fields of software engineering; one can, or could, take their web development skills from one company and easily apply them to another, no matter the scale. Today, we have a constantly evolving browser language, several frontend frameworks and rendering libraries, not just PHP; ASP; and Perl for the server but Python; Ruby; Java; Elixir; Node.js; Groovy, and a wide variety of toolchains and transpilation setups. Now, we're going to open the frontend floodgates to different language runtimes, and along with them even more frontend debugging tools? This field is becoming way less fun. It's not that I don't understand the desire for choice or to simply not use JavaScript, but I doubt that as humans we won't naturally take the freedom given to us and use it to our detriment.

danabramov 8y ago

Author here :-) I don't think I disagree with you. JS has its warts and some of them are... weird. The web delivery mechanism has always been its killer feature, not the language. And for web delivery mechanism to work, it needs to maintain backwards compatibility. In practice, however, I think a lot of these things become irrelevant because JS subcommunities carve out reasonable subsets of the language. For example when using React you almost never need to care about prototypal (or even normal) inheritance because it's explicitly discouraged by React. And in the future, we might not need to encourage classes when writing components altogether. If you limit yourself to avoiding some features then it's not such a bad language after all.

perfunctory 8y ago
> If you limit yourself to avoiding some features then it's not such a bad language after all. Unfortunately that's not possible unless you never interoperate with other code.

tannhaeuser 8y ago

I'd say JavaScript works well enough for its original goal - simple DOM manipulation in response to UI events. IMHO the trouble comes from folks who want to use it for all kinds of over-reaching frameworks. The moment you have to discuss enumerating properties of classes, prototypes, etc., JavaScript's lack of typing becomes painfully obvious and there are just much better languages to spend your time on. I also like the original practical vision for node.js/CommonJS as an escape from the metaprogramming excess that has become Java.

perfunctory 8y ago

I guess your downvoters have some sort of Stockholm syndrome. Javascript is a giant mess and all attempts to fix it seem to make it even worse. Having a sane language in the browser would be the single biggest boost to overall productivity. That alone would push the global gdp up by 5%. At the very least.

fitpolar 8y ago
You can’t critique Javascript. It’s one of the unspoken laws of the internet, but consistent with it reaching religious status. The “Javascript blasphemy must be silenced” crowd is a huge reason why we have this problem. The culture reminds me of Flash 10 years ago. It’s incredibly ironic, they’re their own worst enemies. Fortunately we now have WASM...