6 ms·

I note that all those ecstatic quotes are from executives. Because the way I remember it, technical people hated it with a passion, from its design to its impl

I note that all those ecstatic quotes are from executives. Because the way I remember it, technical people hated it with a passion, from its design to its implementation. In fact, the most popular JS projects have always been to avoid writing ES5, its DOM API, or depending of one of its implementation: - scriptaculous: we hate even the basic types, so we monkey patch our own code into it. - jquery: don't use any of the language paradigms and use ones from Lisp and Haskell. Avoid "this". Don't touch the DOM. In fact, don't code, just make a few calls and pass parameters. And we rewrite the whole damn browser API to avoid incompatibilities. - GWT: write JS from Java. - underscore and co: let's rewrite typeof, the equality sign and array manipulation methods. And provide an stdib for god sake. - coffeescript: we like Python and ruby but must do JS. - React: HTML in JS now please. And magic DOM. Oh, and prototyping is horrible, lets use classes. And we strongly advice immutability, but do what you please... - webpack and babel: ES6 and 7 are not here yet, but ES5 is so bad we will setup an entire ecosystem dedicated to make believe they are. Also pretend import works like in other languages. - typescript: ok, we were wrong, ES7 is not enough. Not nearly enough. Please make intellisense works. Now, in 2020, JS is finally not so horrible to work with. You can use map(), () => and "..." and fake namespaces. Which is amazing to access the crazy cool plateforms that the modern browsers and the web are. So I guess, in a way, this quote from the AOL guy was true.

thiht 7y ago
I don't understand the comparison between jQuery and lisp/Haskell, can you elaborate?
- BiteCode_dev 7y ago
  For Haskell, when doing: $("foo").stuff().bar().res() jQuery feels like the list monad, if you see chaining as similar to bind and $() not so far from return. And for Lisp, jquery provided error handlers instead of relying on native try/except. Of course, it's more inspired from it than the real thing, but it's far from any JS paradigm of the time. Remember that JS didn't even have map() and the only place you used your first class functions was to setInterval. Plus the joke is funnier that way :)
  - nicoburns 7y ago
    You didn't even need first class functions for setInterval. setInterval also accepted a string!
    - BiteCode_dev 7y ago
      Wow, I just tried: setInterval('console.log(1 + 1)', 1000); And it works. It's a big eval(). Stealing this for my next JS training, beginners always have a hard time with callbacks, so it's a good first step to actually explain the benefits of callbacks.
      - deleted 7y ago
        [deleted]
      - spyke112 7y ago
        Why would you direct new comers attention to eval'esque functionality? They should stay far far away from it. Come to think of it, everyone should stay away from eval functionality!
        BiteCode_dev 7y ago
        Because students can understand "code being run every x seconds" easier than "reference to function being resolved then called every x seconds". Once they do, you show the problems with it and show why callbacks are better. When it comes to pedagogy, I'll use every trick I can. And I always win.
        nicoburns 7y ago
        I feel like you could start with manually calling the function, and then introduce callbacks as a way to get your code to run in response to some event. A callback is no different to a regular function after all. If your way works, then it works though I suppose.
        inkeddeveloper 7y ago
mettamage 7y ago
> - webpack and babel: ES6 and 7 are not here yet, but ES5 is so bad we will setup an entire ecosystem dedicated to make believe they are. Also pretend import works like in other languages. They just peeked over at their low level programming neighbours and realized what they did to avoid programming assembly and program C instead was a smart idea.
z3t4 7y ago
JavaScript has a very high learning curve. But it becomes great once you are fluent. When manipulating the DOM it kinda sucks that you can't just monkey-path attributes, you have to use el.setAttribute. The DOM is also very slow. But the DOM do a lot of work - ever tried to make your own UI framework from scratch only using low level GUI calls? z-index, styling with CSS, screen-reader support, etc.
- austincheney 7y ago
  > The DOM is also very slow. https://news.ycombinator.com/item?id=22391509 https://news.ycombinator.com/item?id=22391509 > I still have people argue with me that the DOM is slow even though all the evidence and browser vendors claim updates to the DOM is simply switching a bit in memory. In other words many web developers have utterly no idea how their platform works. I guess not much has changed in 25 years. Most developers still fear the language, have no idea how it works, and will do everything in their power to pretend this language is some other language. > ever tried to make your own UI framework from scratch only using low level GUI calls? z-index, styling with CSS, screen-reader support, etc. https://news.ycombinator.com/item?id=22321333 https://news.ycombinator.com/item?id=22321333
  - z3t4 7y ago
    I meant creating a GUI from scratch. Creating a GUI using the DOM is easy. Working with the DOM overall is simple. What I mean is that the DOM do so much work for us (that we take for granted). What I mean by slow is for example adding a element to the screen, or updating some text. Compared to for example everything that happens on the screen in a 3d game. I do everything using vanilla JS and I cannot understand why anyone would use a web framework, (although most web project does). I do however have a vague memory that the learning curve was fairly steep, as I have been working with vanilla JS for over 20 years. (whereas the average developer has only used JS for one year) it wasn't until I started to use JS full stack (with Node.JS) that I started to like it!
    - piva00 7y ago
      I worked with vanilla JS for some time (before Prototype.js or jQuery existed) and used a bunch of incantations of different libraries and frameworks over the years and I cannot understand why anyone would choose to use JS for platforms where you can use any other language (aka... any platform that isn't a browser). No construct or design decision of JS is better than in other languages, the lack of a basic standard library hurts a lot. Dependency management was inexistent until recently, the same for a lot of basic constructs, data types and other utilities that should be baked into any modern language. The current landscape of JS is so convoluted and with such a varying level of quality that is intractable for me just trying to get things done without getting into the community and everything around it, it's not an easy tool to use and it's not an ergonomical one. I have used JS for the past 15+ years for different kinds of software and I dislike it, not intensely but I'd never choose to work solely on JS. Yes, you can be productive in it but there are much better tools for most of the job it does around, its only power was to be the only language you could use to script a browser and I hope that WASM kills that.
deleted 7y ago
[deleted]
inkeddeveloper 7y ago
Are you okay?
Pmop 7y ago
I've just began to learn ES5 and ES6. I've compiled a small list of JS quirks, things that I'd take for granted because they're well stablished in other high level programming languages. For instance, 'for/in' picks the keys instead of the values of either array or dictionary ( object in JS terms I think), dictionary doesn't have a keys 'method' but you can call Object.keys for that functionality, arrays are key/value indexed, so array['a']=1 is valid, and so on. I've lost a little while just laughing when I learned about how ES5 does OO. JS oftentimes reminds of Apple: there's the industry standard or some already well stablished way of doing things, and they go like "Well, flip it. We're doing our own way, just because".

thiht 7y ago

I don't understand the comparison between jQuery and lisp/Haskell, can you elaborate?

BiteCode_dev 7y ago
For Haskell, when doing: $("foo").stuff().bar().res() jQuery feels like the list monad, if you see chaining as similar to bind and $() not so far from return. And for Lisp, jquery provided error handlers instead of relying on native try/except. Of course, it's more inspired from it than the real thing, but it's far from any JS paradigm of the time. Remember that JS didn't even have map() and the only place you used your first class functions was to setInterval. Plus the joke is funnier that way :)
- nicoburns 7y ago
  You didn't even need first class functions for setInterval. setInterval also accepted a string!
  - BiteCode_dev 7y ago
    Wow, I just tried: setInterval('console.log(1 + 1)', 1000); And it works. It's a big eval(). Stealing this for my next JS training, beginners always have a hard time with callbacks, so it's a good first step to actually explain the benefits of callbacks.
    - deleted 7y ago
      [deleted]
    - spyke112 7y ago
      Why would you direct new comers attention to eval'esque functionality? They should stay far far away from it. Come to think of it, everyone should stay away from eval functionality!
      - BiteCode_dev 7y ago
        Because students can understand "code being run every x seconds" easier than "reference to function being resolved then called every x seconds". Once they do, you show the problems with it and show why callbacks are better. When it comes to pedagogy, I'll use every trick I can. And I always win.
        nicoburns 7y ago
        I feel like you could start with manually calling the function, and then introduce callbacks as a way to get your code to run in response to some event. A callback is no different to a regular function after all. If your way works, then it works though I suppose.
        inkeddeveloper 7y ago

mettamage 7y ago

> - webpack and babel: ES6 and 7 are not here yet, but ES5 is so bad we will setup an entire ecosystem dedicated to make believe they are. Also pretend import works like in other languages. They just peeked over at their low level programming neighbours and realized what they did to avoid programming assembly and program C instead was a smart idea.

z3t4 7y ago

JavaScript has a very high learning curve. But it becomes great once you are fluent. When manipulating the DOM it kinda sucks that you can't just monkey-path attributes, you have to use el.setAttribute. The DOM is also very slow. But the DOM do a lot of work - ever tried to make your own UI framework from scratch only using low level GUI calls? z-index, styling with CSS, screen-reader support, etc.

austincheney 7y ago
> The DOM is also very slow. https://news.ycombinator.com/item?id=22391509 https://news.ycombinator.com/item?id=22391509 > I still have people argue with me that the DOM is slow even though all the evidence and browser vendors claim updates to the DOM is simply switching a bit in memory. In other words many web developers have utterly no idea how their platform works. I guess not much has changed in 25 years. Most developers still fear the language, have no idea how it works, and will do everything in their power to pretend this language is some other language. > ever tried to make your own UI framework from scratch only using low level GUI calls? z-index, styling with CSS, screen-reader support, etc. https://news.ycombinator.com/item?id=22321333 https://news.ycombinator.com/item?id=22321333
- z3t4 7y ago
  I meant creating a GUI from scratch. Creating a GUI using the DOM is easy. Working with the DOM overall is simple. What I mean is that the DOM do so much work for us (that we take for granted). What I mean by slow is for example adding a element to the screen, or updating some text. Compared to for example everything that happens on the screen in a 3d game. I do everything using vanilla JS and I cannot understand why anyone would use a web framework, (although most web project does). I do however have a vague memory that the learning curve was fairly steep, as I have been working with vanilla JS for over 20 years. (whereas the average developer has only used JS for one year) it wasn't until I started to use JS full stack (with Node.JS) that I started to like it!
  - piva00 7y ago
    I worked with vanilla JS for some time (before Prototype.js or jQuery existed) and used a bunch of incantations of different libraries and frameworks over the years and I cannot understand why anyone would choose to use JS for platforms where you can use any other language (aka... any platform that isn't a browser). No construct or design decision of JS is better than in other languages, the lack of a basic standard library hurts a lot. Dependency management was inexistent until recently, the same for a lot of basic constructs, data types and other utilities that should be baked into any modern language. The current landscape of JS is so convoluted and with such a varying level of quality that is intractable for me just trying to get things done without getting into the community and everything around it, it's not an easy tool to use and it's not an ergonomical one. I have used JS for the past 15+ years for different kinds of software and I dislike it, not intensely but I'd never choose to work solely on JS. Yes, you can be productive in it but there are much better tools for most of the job it does around, its only power was to be the only language you could use to script a browser and I hope that WASM kills that.

deleted 7y ago

[deleted]

inkeddeveloper 7y ago

Are you okay?

Pmop 7y ago

I've just began to learn ES5 and ES6. I've compiled a small list of JS quirks, things that I'd take for granted because they're well stablished in other high level programming languages. For instance, 'for/in' picks the keys instead of the values of either array or dictionary ( object in JS terms I think), dictionary doesn't have a keys 'method' but you can call Object.keys for that functionality, arrays are key/value indexed, so array['a']=1 is valid, and so on. I've lost a little while just laughing when I learned about how ES5 does OO. JS oftentimes reminds of Apple: there's the industry standard or some already well stablished way of doing things, and they go like "Well, flip it. We're doing our own way, just because".