Live data from Hacker News

What people in tech had to say about JavaScript when it debuted in 1995 (2017)

medium.com

201–210 of 241 posts

Re: What people in tech had to say about JavaScript when it debuted in 1995 (2017)

#201
post #111

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.

I used Remote Scripting as well. It was a reliable enough hack that we built a lot of stuff on it. But I don’t think it was intended to be used that way when Netscape released JavaScript in ‘95.

Re: What people in tech had to say about JavaScript when it debuted in 1995 (2017)

#202
post #194

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 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.

> The DOM is also very slow.

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

Re: What people in tech had to say about JavaScript when it debuted in 1995 (2017)

#203
post #177

Earlier 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…

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.

Re: What people in tech had to say about JavaScript when it debuted in 1995 (2017)

#204

Earlier 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.

No. The first is incoherent, the second ignores half my comment.

Re: What people in tech had to say about JavaScript when it debuted in 1995 (2017)

#205

Earlier 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.

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!

Re: What people in tech had to say about JavaScript when it debuted in 1995 (2017)

#206
post #149

Earlier 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.

agreed- maps was the real game changer. gmail was just okay

Re: What people in tech had to say about JavaScript when it debuted in 1995 (2017)

#207

Earlier 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.

I suggest that, if possible, try to set up a cheap server on a DO droplet or somewhere with a built in amount of latency and use that in your presentation.

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)

#209
post #5

The 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.

I remember those times. Things like DHTML clocks.

Re: What people in tech had to say about JavaScript when it debuted in 1995 (2017)

#210
post #203

Earlier 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.

> which means an operation might be executed zero or multiple times depending on the bind.

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.

Post reply on HN