4 ms·

As a JavaScript developer I strongly resonate with the quote at 14:50 into the video. In summary all of the silicon industrys' chips at the time were full of d

As a JavaScript developer I strongly resonate with the quote at 14:50 into the video. In summary all of the silicon industrys' chips at the time were full of defects and often the same defects between various vendors. The industry was completely aware of this. The problem is that the original generation of chips were designed by old guys who figured it out. The current generation of chips (at that time) was designed by youngsters working in the shadow of the prior generation and not asking the right questions because they were not aware of what those questions were. A decade ago JavaScript developers had little or no trouble working cross browser, writing small applications, and churning out results that work reasonably well very quickly. It isn't that cross browser compatibility had been solved, far from it, but that you simply worked to the problem directly and this was part of regular testing. That older generation did not have the benefit of helpful abstractions like jQuery or React. They had to know what the APIs were and they worked to them directly. The biggest problem with this is that there weren't many people who could do this work well. Then shortly after the helpful abstractions appeared and suddenly there was an explosion of competent enough developers, but many of these good enough developers did not and cannot work without their favorite abstractions. These abstractions impose a performance penalty, increase product size, impose additional maintenance concerns, and complicate requirements. The ability to work below the abstractions is quickly becoming lost knowledge. Many commercial websites load slower now than they did 20 years ago despite radical increases in connection speeds. To the point of the video this loss of knowledge is not static and results in degrading quality over time that is acceptable to later generations of developers who don't know the proper questions to ask.

shams93 7y ago
Well I came from the pre jQuery era but the whole industry is obsessed with react. There are tons of tools available web components are becoming standard, ultimately using native apis is far more performent but it's also more standard and consistent and easier than the old days to write pure vanilla js.
- austincheney 7y ago
  I have heard people say this in justification of their framework, library, abstraction, whatever. The reality is that, from my experience, I can easily replace maybe 8 other JavaScript developers. I am not saying that out of arrogance or some uniformed guess at my radical superiority. I am saying this out of experience. It isn't because I am smart or a strong programmer. This has proven true for me, because when writing vanilla JS I am the bottleneck and the delay. I am not waiting on tools, performance delays, code complexity, or anything else. If there is bad code its because I put it there and I am at fault, and so I have nothing to blame but myself. Knowing this, and I mean as a non-cognitive emotional certainty, means I can solve the problem immediately with the shortest effort necessary or it isn't getting solved ever and that changes my priority of effort. It also means not tolerating a slow shitty product since you are fully in control (at fault). When people go through project management training I tell them there are only two kinds of problems: natural disasters and bad human decisions. When you can remove blame from the equation the distance between you and the problem/solution becomes immensely shorter.
chii 7y ago
> not asking the right questions because they were not aware of what those questions were. to me, this sounds like the NIH syndrome, and that those who are tasked with creating new stuff is either lacking in comprehensive education, as well as the "old guards" not transmitting the knowledge in a more permanent form (like a book). > many of these good enough developers did not and cannot work without their favorite abstractions i would argue that those were not "good enough", but is "barely know enough". My mantra for using a library is - if you could've written the library yourself, then use it. Otherwise, you dont know enough and using it as a blackbox is certainly going to lead to disaster in the future (for you or some other poor soul).
- noir_lord 7y ago
  > My mantra for using a library is - if you could've written the library yourself, then use it. Otherwise, you dont know enough and using it as a blackbox is certainly going to lead to disaster in the future (for you or some other poor soul). That is largely my attitude to using any package/library - if the entire dev team gets hit by a bus tomorrow can I maintain this (i.e. keep it working reliably in production), if the answer is no then I nearly always avoid it and if I can't I wrap it in my own layer so that I can replace it later. I've been an enterprise developer for a long time so my worldview is shaped by "this will likely stick around twice as long as anyone expects minimum" though.
  - Filligree 7y ago
    I have a friend with that attitude. It's led him to implementing his own encryption libraries, UI libraries and so forth, and... Well, I have to admit he's smart, but the software he writes outside of work is some of the worst I've ever used. Furthermore, I was able to crack his RSA implementation with a straightforward timing attack. Some things shouldn't be reimplemented. Perhaps he could have implemented them, then used something else? True, but that's a hard sell.
    - detaro 7y ago
      Surely you can at least estimate if you could have created/could maintain a library without actually doing a reimplementation, e.g. by diving into a bug or two?
jaabe 7y ago
There is too much copy pasting in web-development. I mean, we still use the MVC pattern to run almost all our web-apps because the MVVM pattern would require us to hire additional developers to do the same thing. Between Ajax and JQuery we can build things that are perfectly reactive and come with the added benefit of being extremely easy to debug. They can’t run offline, and if we need to build something that does, then we’ll turn to something like angular/react/ (typically Vue, because we actually use Vue components in our MVC apps from time to time, but which one is beside the point). When we interview junior developers about this, they often think we’re crazy for not having access to NPM, but we’re the public sector, we need to know what every piece of our application does. That means it’s typically a lot easier to write our own things rather than to rely on third party packages.
- icebraining 7y ago
  Can you explain on how MVVM requires more developers vis-a-vis MVC? And why would jQuery not work offline?
  - jaabe 7y ago
    It’s several times more complicated to build business logic on both the front and the backend. It’s several times more complicated to debug something that runs on the clients device than something that runs on your server.
arendtio 7y ago
Actually, I don't think that abstractions are the problem. I mean, the whole OSI model is made of abstractions. Abstractions are at the core of software development. And I also don't think that Jquery is the problem. Jquery just made JS worth learning. Before you had to spend an insane amount of time just working out implementation specifics that changed every few months. However, the point where I do agree with you is that we have a performance issue with JS. And I am not talking about slow JS engines. I am talking about developers who are not aware of how costly some operations are (e.g. loading a bunch of libraries). Yes, that is an issue that naturally arises with abstractions, but to conclude that abstractions themselves are the problem is wrong. I think the problem is more about being aware of what happens in the background. You don't have to know every step for every browser and API, but loading 500KB of dependencies before even starting your own scripts is not going to be fast in any browser.
- austincheney 7y ago
  The abstractions aren't making this problem the developers without a willingness to work under the abstractions are. I wrote this following tool in less than 90 minutes 5 years ago because I had some time left over before presentations at a company hack-a-thon. I updated it recently at about another 90 minutes of time. https://github.com/prettydiff/semanticText https://github.com/prettydiff/semanticText That tool was trivial to write and maintain. It has real utility value as an accessibility tool. I could write that tool because I am familiar with the DOM, the layer underneath. Many developers are not even aware of the problems (SEO and accessibility) this tool identifies much less how to write it. jQuery won't get you the necessary functionality.
  - mercer 7y ago
    Why are so many of your comments of a gate-keeping, self-congratulatory nature, or blanket criticisms of others? I find it frustrating because I do think you have plenty of valuable stuff to say, but you're consistently presenting it in a rather unappealing package and I don't really understand what you get out of that.
    - 7y ago

shams93 7y ago

Well I came from the pre jQuery era but the whole industry is obsessed with react. There are tons of tools available web components are becoming standard, ultimately using native apis is far more performent but it's also more standard and consistent and easier than the old days to write pure vanilla js.

austincheney 7y ago
I have heard people say this in justification of their framework, library, abstraction, whatever. The reality is that, from my experience, I can easily replace maybe 8 other JavaScript developers. I am not saying that out of arrogance or some uniformed guess at my radical superiority. I am saying this out of experience. It isn't because I am smart or a strong programmer. This has proven true for me, because when writing vanilla JS I am the bottleneck and the delay. I am not waiting on tools, performance delays, code complexity, or anything else. If there is bad code its because I put it there and I am at fault, and so I have nothing to blame but myself. Knowing this, and I mean as a non-cognitive emotional certainty, means I can solve the problem immediately with the shortest effort necessary or it isn't getting solved ever and that changes my priority of effort. It also means not tolerating a slow shitty product since you are fully in control (at fault). When people go through project management training I tell them there are only two kinds of problems: natural disasters and bad human decisions. When you can remove blame from the equation the distance between you and the problem/solution becomes immensely shorter.

chii 7y ago

> not asking the right questions because they were not aware of what those questions were. to me, this sounds like the NIH syndrome, and that those who are tasked with creating new stuff is either lacking in comprehensive education, as well as the "old guards" not transmitting the knowledge in a more permanent form (like a book). > many of these good enough developers did not and cannot work without their favorite abstractions i would argue that those were not "good enough", but is "barely know enough". My mantra for using a library is - if you could've written the library yourself, then use it. Otherwise, you dont know enough and using it as a blackbox is certainly going to lead to disaster in the future (for you or some other poor soul).

noir_lord 7y ago
> My mantra for using a library is - if you could've written the library yourself, then use it. Otherwise, you dont know enough and using it as a blackbox is certainly going to lead to disaster in the future (for you or some other poor soul). That is largely my attitude to using any package/library - if the entire dev team gets hit by a bus tomorrow can I maintain this (i.e. keep it working reliably in production), if the answer is no then I nearly always avoid it and if I can't I wrap it in my own layer so that I can replace it later. I've been an enterprise developer for a long time so my worldview is shaped by "this will likely stick around twice as long as anyone expects minimum" though.
- Filligree 7y ago
  I have a friend with that attitude. It's led him to implementing his own encryption libraries, UI libraries and so forth, and... Well, I have to admit he's smart, but the software he writes outside of work is some of the worst I've ever used. Furthermore, I was able to crack his RSA implementation with a straightforward timing attack. Some things shouldn't be reimplemented. Perhaps he could have implemented them, then used something else? True, but that's a hard sell.
  - detaro 7y ago
    Surely you can at least estimate if you could have created/could maintain a library without actually doing a reimplementation, e.g. by diving into a bug or two?

jaabe 7y ago

There is too much copy pasting in web-development. I mean, we still use the MVC pattern to run almost all our web-apps because the MVVM pattern would require us to hire additional developers to do the same thing. Between Ajax and JQuery we can build things that are perfectly reactive and come with the added benefit of being extremely easy to debug. They can’t run offline, and if we need to build something that does, then we’ll turn to something like angular/react/ (typically Vue, because we actually use Vue components in our MVC apps from time to time, but which one is beside the point). When we interview junior developers about this, they often think we’re crazy for not having access to NPM, but we’re the public sector, we need to know what every piece of our application does. That means it’s typically a lot easier to write our own things rather than to rely on third party packages.

icebraining 7y ago
Can you explain on how MVVM requires more developers vis-a-vis MVC? And why would jQuery not work offline?
- jaabe 7y ago
  It’s several times more complicated to build business logic on both the front and the backend. It’s several times more complicated to debug something that runs on the clients device than something that runs on your server.

arendtio 7y ago

Actually, I don't think that abstractions are the problem. I mean, the whole OSI model is made of abstractions. Abstractions are at the core of software development. And I also don't think that Jquery is the problem. Jquery just made JS worth learning. Before you had to spend an insane amount of time just working out implementation specifics that changed every few months. However, the point where I do agree with you is that we have a performance issue with JS. And I am not talking about slow JS engines. I am talking about developers who are not aware of how costly some operations are (e.g. loading a bunch of libraries). Yes, that is an issue that naturally arises with abstractions, but to conclude that abstractions themselves are the problem is wrong. I think the problem is more about being aware of what happens in the background. You don't have to know every step for every browser and API, but loading 500KB of dependencies before even starting your own scripts is not going to be fast in any browser.

austincheney 7y ago
The abstractions aren't making this problem the developers without a willingness to work under the abstractions are. I wrote this following tool in less than 90 minutes 5 years ago because I had some time left over before presentations at a company hack-a-thon. I updated it recently at about another 90 minutes of time. https://github.com/prettydiff/semanticText https://github.com/prettydiff/semanticText That tool was trivial to write and maintain. It has real utility value as an accessibility tool. I could write that tool because I am familiar with the DOM, the layer underneath. Many developers are not even aware of the problems (SEO and accessibility) this tool identifies much less how to write it. jQuery won't get you the necessary functionality.
- mercer 7y ago
  Why are so many of your comments of a gate-keeping, self-congratulatory nature, or blanket criticisms of others? I find it frustrating because I do think you have plenty of valuable stuff to say, but you're consistently presenting it in a rather unappealing package and I don't really understand what you get out of that.
  - 7y ago