Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Netscape and Sun Announce JavaScript (1995)

web.archive.org

Post reply on HN
Print view View original

391–400 of 476 posts

Re: Netscape and Sun Announce JavaScript (1995)

#391

Post by cubano »

colejohnson66 wrote: post #355
mlyle wrote: post #332

Earlier quoted context omitted.

Of course, there's murky things like Python which make bytecode compiled forms behind the scene. But there's a lot of magic involved in transforming Java to class files, and then there's a lot of further magic in resolving, loading, and eventually executing classes.

PHP does the same. It’s compiled to a bytecode before execution. But I don’t think it’s cached anywhere like Python (but that may have changed in the decade since I’ve used it)

It better be cached or else that would be a total tradegy... why wouldn't you automatically want to cache the prerendered pages whenever possible?

It's not like writing a basic cache is very hard...or just "borrow" one from an OS implementation.

Re: Netscape and Sun Announce JavaScript (1995)

#392

Post by tracker1 »

brundolf wrote: post #303
drblast wrote: post #294

Earlier quoted context omitted.

The industry is cyclical and to be forward thinking all you have to do is describe what's already happened and assume it will happen again. ;-) The things being done with JavaScript today are not new, nor is the idea that a server and client would coordinate to run interactive apps. That fundamental concept has been reimplemented in many different ways until we've landed on the current rube goldbergian monstrosity th…

I'm not surprised that the architecture isn't new, I'm surprised that web apps were already being talked about this way using JS specifically. JS's early design flaws are often written off as, "well it was never intended to be a real programming language like it is today". But from reading this, that doesn't sound to be the case.

I don't so much think of them as flaws... the first use case was form validation, and most of the fuzzy type coercion makes a ton of sense through that lens, where ''. 0, etc. coercion to falsy is easy for dealing with user input. It's also why it's one of my favorite options for ETL workloads.

It's just a matter of understanding the langauge. That said, it's been my favorite language since well before the "good parts" book.

Re: Netscape and Sun Announce JavaScript (1995)

#394

Post by ignoranceprior »

hcs wrote: post #254
edub wrote: post #190

it is interesting that the archive.org version of this press release has a semi-colon after AT&T; i can't remember if in 1995 we would write the code to be AT&T or if that came a bit later. perhaps the scraper thought it was an HTML entity starting with the & followed by the T and it added the semi-colon. or maybe it originally was posted in 1995 without the semi-colon and before it got indexed in 2002 by archive…

In the raw version of the archived page, found by adding "id_" after the URL[1], there is no semicolon. The link to netscape.com at the end is mysteriously missing still, "Additional information on Netscape Communications Corporation is available on the Internet at ," [1] https://web.archive.org/web/20020606002913id_/http://wp.nets...

Does this mean the Wayback Machine has a bug relating to how it handles HTML entities?

Re: Netscape and Sun Announce JavaScript (1995)

#396

Post by mlyle »

pwdisswordfish4 wrote: post #353
hi41 wrote: post #335

Earlier quoted context omitted.

Does this mean java .class falls in the middle of scripts and native executables? Is this analogy correct? For example, I think of native executable as Microsoft Word where you can doubleclick and launch it. Whereas with .class you have to run it on top of a jvm.

No. If you must insist on thinking of them as distinct from native executables, then consider them foreign executable instead—object files written for a different machine architecture and a different loader convention. There's really no middle ground they're occupying.

This is a very good way to put it.

The super pedant in me, of course, would say they're a sliver in the middle because they're targeted at running in a software-implemented VM instead of on a real machine architecture, and that this isn't all that different from in-memory interpreter bytecode or something like a .pyc written to disk...

But then something like the more complicated loaders for native executables is a sliver in the middle, too. And then you look at something like the AS/400 with super-high level "instructions" and these distinctions get super, super muddy.

Re: Netscape and Sun Announce JavaScript (1995)

#397

Post by kevin_thibedeau »

sdenton4 wrote: post #327
calibas wrote: post #291

Earlier quoted context omitted.

This is all semantics, but the idea was that Java is a "real" language for serious use and JavaScript is a "script" that's much easier to use and doesn't involve all the complications of a "real" programming language. It was only kind of true back then, and not even remotely true now. There really isn't a solid line you can draw between a "script" and a "programming language". To me, something like Python is right in…

I feel like "requires compilation" is a good first order differentiator. And "has a somewhat sane type system" is another.

tcc is fast enough to run C code (or langs targeting C) as scripts.

Re: Netscape and Sun Announce JavaScript (1995)

#398

Post by moron4hire »

ahlschwede wrote: post #184
overkill28 wrote: post #36

I still don't know why they stuck the "Java" name on JavaScript. Very confusing when the two languages are completely unrelated. > Java programs and JavaScript scripts are designed to run on both clients and servers, with JavaScript scripts used to modify the properties and behavior of Java objects, so the range of live online applications that dynamically present information to and interact with users over enterpris…

Before Ajax one way to do Web 2.0 style interactions was to hide a Java applet in an invisible iFrame and feed data back and forth from the page using JavaScript. I think people forget that the early web had a proliferation of plug-ins. JavaScript was most often used as glue between HTML and plug-ins which had fewer platform incompatibilities than the browsers. One of the reasons Flash became the dominant plug-in was…

IFrames were invented later (and initially, only in IE). You also didn't ever need to put the applet in a separate frame. You could just put the applet on the page. Indeed, putting it in a frame would have defeated the purpose, because there was no way to communicate across frames at the time.

Re: Netscape and Sun Announce JavaScript (1995)

#399

Post by brundolf »

tracker1 wrote: post #392
brundolf wrote: post #303

Earlier quoted context omitted.

I'm not surprised that the architecture isn't new, I'm surprised that web apps were already being talked about this way using JS specifically. JS's early design flaws are often written off as, "well it was never intended to be a real programming language like it is today". But from reading this, that doesn't sound to be the case.

I don't so much think of them as flaws... the first use case was form validation, and most of the fuzzy type coercion makes a ton of sense through that lens, where ''. 0, etc. coercion to falsy is easy for dealing with user input. It's also why it's one of my favorite options for ETL workloads. It's just a matter of understanding the langauge. That said, it's been my favorite language since well before the "good part…

I use JS every day; I would say I like it. I would even say that in 2020, if you know what you're doing, it's a pretty good language on the whole.

But I don't think it's controversial to say that the following were objectively bad decisions (in hindsight, of course, but still):

- Automatic casting behavior between the core types (you're the only person I've ever heard suggest that this might be a good thing)

- Automatic semicolon insertion

- A core Date object that lacks basic control over time-zones and reasoning about time-zones

- Assigning to an undeclared variable silently creates a global

- Allowing duplicate function parameter names where later ones just hide the earlier ones

- Distinction between undefined and null (this one might have a few defenders)

Some of these are now prevented by "strict mode". Others have been patched-over, for example by the addition of === which prevents casting behavior for comparisons at least. Others can be bridged by libraries (Moment.js) or by best-practices (use foo == null to smooth over the null/undefined distinction, never use a value's implicit falsiness in a conditional, etc).

But the point is that JavaScript has this giant asterisk that will never go away, of things you need to do/avoid/utilize in order to get the most basic behaviors right.

Re: Netscape and Sun Announce JavaScript (1995)

#400

Post by moron4hire »

bdcravens wrote: post #237
atum47 wrote: post #123

I bought a book, when I was about 12-15 years old, called DHTML (Dynamic HTML). It blew my mind to see things moving across the screen with just code. Keep in mind that I learned pure html when I was 10, my websites were all very static (apart from a animated GIF here and there). The only way you could do a cool menu, effect or animation, was with Java Applet (which I learned after purchasing a online Java course tha…

In the late 90s/early 2000s you'd search (probably with Altavista) for a DHTML script that did a given thing (and often it wouldn't even be that dynamic, and might be something as simple as form validation; "DHTML" was kind of a catch-all phrase)

Only in the same way that people still use terms incorrectly. DHTML was the progenitor for the editing of styles on DOM objects that we do today. It has a specific meaning. Depending on how you did the form validation (highlighting input fields, or revealing error messages, rather than using an alert box or performing the validation on the server and generating a new page), it absolutely could have been DHTML.
Post reply on HN