Earlier quoted context omitted.
They do deserve some credit for intentionally introducing that feature to the browser as a standard feature, but the notion of fetching data without reloading the page wasn't novel at all. That's what Java applets and plugins were for. I'm also pretty sure they weren't the first to fetch data from the server without reloading, because people were doing all sorts of novel things in the mid-90s with plugins. The reason…
Loading into a hidden or pixel-sized iframe (or ilayer in NS) was a thing before XMLHttpRequest as well. In what would now seem a scary technique, you would use JS to load more JS (plus data, of course) that would put the new data into the iframe's host page.
What people in tech had to say about JavaScript when it debuted in 1995 (2017)
201–210 of 241 posts
Re: What people in tech had to say about JavaScript when it debuted in 1995 (2017)
#202I 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 t…
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.
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.
Re: What people in tech had to say about JavaScript when it debuted in 1995 (2017)
#203Earlier quoted context omitted.
I don't understand the comparison between jQuery and lisp/Haskell, can you elaborate?
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 y…
The use of method chaining in jQuery is cool, but it is not very similar to Haskell.
Re: What people in tech had to say about JavaScript when it debuted in 1995 (2017)
#204Earlier quoted context omitted.
jQuery was invented for basically two reasons, neither of them about making JavaScript suck less. 1. Introduce a "chaining" API. 2. Paper over the differences between how browsers implemented the DOM, with events being the big issue. Note that the DOM is not JavaScript and JavaScript is not the DOM. The DOM is a language-agnostic API for manipulating markup-based documents.
So in other words: 1: to fix js chaining 2: to fix js compatibility Ergo to make js suck less.
Re: What people in tech had to say about JavaScript when it debuted in 1995 (2017)
#205Earlier quoted context omitted.
You didn't even need first class functions for setInterval. setInterval also accepted a string!
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.
Re: What people in tech had to say about JavaScript when it debuted in 1995 (2017)
#206Earlier quoted context omitted.
Complex javascript apps just weren't a thing...hell, it took google writing Gmail (2004) to really show everyone that a large SPA using javascript was even possible. After Gmail...things really started to move in the javascript world...people started to put effort into both the runtimes and the libraries.
It wasn't gmail -- it was google maps that really made everyone look again at javascript. Although MS added XMLHTTPRequest, it took something like google maps that pushed it further than anyone thought at the time to make JS a real thing.
Re: What people in tech had to say about JavaScript when it debuted in 1995 (2017)
#207Earlier quoted context omitted.
You didn't even need first class functions for setInterval. setInterval also accepted a string!
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.
When I was learning callbacks I saw people use the "setInterval" example and while it did help to an extent, the real world implementation still left a good deal to be desired.
Re: What people in tech had to say about JavaScript when it debuted in 1995 (2017)
#208Re: What people in tech had to say about JavaScript when it debuted in 1995 (2017)
#209The release of JavaScript was deeply confusing to me as a developer back then. Java applets and Macromedia Flash were already touted by their vendors as the one true way forward for interactivity. The scripting language released at about the same time seemed like an oddball. It's easy to forget, but for years after its introduction JavaScript didn't work well. It was extremely slow, limiting the complexity of what co…
Back when I first played with Javascript I don't think anyone even used the name. Tutorials were all about "DHTML", where you were building "Dynamic HTML" by writing Javascript to move items around.
Re: What people in tech had to say about JavaScript when it debuted in 1995 (2017)
#210Earlier quoted context omitted.
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 y…
Method chaining (aka. fluent syntax) is not really comparable to bind. Bind is nested lambdas, which means an operation might be executed zero or multiple times depending on the bind. In method chaining, each call will be executed exactly once, unless an exception is thrown. The use of method chaining in jQuery is cool, but it is not very similar to Haskell.
That's what the jQuery API does behind the scene of the chained calls. That's one of the key reasons of its success actually.
$(".foo").foo().bar() will execute n times, for each of the n DOM elements you matched with ".foo", including one or zero.