Netscape and Sun Announce JavaScript (1995)

Post by syncsynchalt » Fri, Dec 04, 2020, 10:05 PM UTC

newyorker2 wrote: post #11

> JavaScript is analogous to Visual Basic in that it can be used by people with little or no programming experience to quickly construct complex applications. >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 ove…

Post by pmontra » Fri, Dec 04, 2020, 10:11 PM UTC

Lammy wrote: post #342

AntiRush wrote: post #295

Earlier quoted context omitted.

Philip Greenspun has a great review of Netscape LiveWire from the time. https://philip.greenspun.com/wtr/livewire.html You can see that the current JavaScript tooling complains are nothing new under the sun: So what used to be a few keystrokes in Emacs or Netscape Gold now requires three steps: edit the .html file recompile the .web file restart the LiveWire app from the appmgr

This quote is adorable considering the size of most pages today: "This approach has several disadvantages, the first of which is speed. You are gratuitously transporting potentially many kilobytes of data back and forth across the network."

Post by cubano » Fri, Dec 04, 2020, 10:14 PM UTC

ezekiel68 wrote: post #313

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 agree with your basic premise. However, in this particular instance, what would have been the historical equivalent ("already happened") of scripts sent by the server to the client during the request response cycle, which could perform layout and logic in the client? If you're simply referring to code that could run on both client and server, your point is clearer to me.

Post by evan_ » Fri, Dec 04, 2020, 10:19 PM UTC

colejohnson66 wrote: post #351

evan_ wrote: post #349

In the beginning JavaScript was created. This has made a lot of people very angry and has been widely regarded as a bad move.

> widely regarded as a bad move. By who? You? Because there’s tens (hundreds) of thousands of programmers and thousands of companies working on JavaScript. Just because many here consider JavaScript bad doesn’t mean everyone does. JavaScript has many problems, but it’s not “widely regarded” as bad.

Post by cubano » Fri, Dec 04, 2020, 10:21 PM UTC

giovannibonetti wrote: post #315

brundolf wrote: post #284

What stands out to me is how much more foresight they had than I'd thought about the ways JS would be used: > With JavaScript, an HTML page might contain an intelligent form that performs loan payment or currency exchange calculations right on the client in response to user input. A multimedia weather forecast applet written in Java can be scripted by JavaScript to display appropriate images and sounds based on the c…

Running the same logic and the same technology in the server and the client was mandatory for realtime multiplayer games since the 1990s. See this article from Valve [1] for a briew overview of how client side prediction works. You should also have the server process the data to avoid cheating by modificating the client app. [1] https://developer.valvesoftware.com/wiki/Latency_Compensatin...