I'm not sure about this. The web is first and foremost a document platform. Adding scripting to it could cause security problems, hurt usability and destroy the reliability of this new approach some startups are trying called "web search" which promises to automate index directories. I also wonder what's the difference between Java and JavaScript, at first glance, they look very similar.
I don't see what's wrong with embedding a programming language in the browser. It's light weight, and rather simple.
As long as this stays in the browser, and is not also used server-side, I don't think there's much to worry about. Since it's designed to be Java like, I suspect most developers would opt to use server-side Java, and this in browser. This probably won't change.
You could just buy WebObjects from NeXT and build amazing dynamic web applications with the best GUI tools and a true object-oriented language.
It’s only $50,000 but surely everyone making real web apps can afford that. It’s a rounding error compared to what you’re paying Sun for your server hardware.
I’ve seen an interesting approach for a lightweight, Open Source server side scripting language by a Danish programmer. It’s called PHP/FI and has been created specifically to make handling forms and dynamically generated Web pages easier. It might even evolve to be an alternative to buying WebObjects.
I don't see how it's going to beat Perl, which already lets you do the same things, but inside a full-fledged programming language. Many webmasters and server admins have already learned some Perl, and it's considered very easy to use (and even easier when you try to read other people's code).
I looked at PHP/FI for my own homepage before, but it's really nothing more than a rudimentary template language, a slightly more powerful version of httpd's Server Side Includes. Rasmus (the developer) seems to be quite happy with keeping it simple. Perhaps you'll be lucky and he'll change his mind and convert it to a full scripting language. Heh, maybe we'll even get two frustrated undergrad students who hate Perl to rewrite the parser so they can use it to write their computer science project. Maybe you'll even be very lucky and somebody will decide to write a popular system for writing web journals in PHP/FI that would take over the world (but how many people would be so self-absorbed as to maintain a web journal anyway).
And you still don't have the database and hardware side covered. PHP/FI seems to support mSQL. mSQL is cheap for commercial use, but still not free, and it doesn't even support JOINs! And you also need a server. You also need a server. httpd used to be cool, but NCSA is no longer maintaining that. There's a serious of patches running around, so you could just run a patchy version of httpd, but how far will that take you? Next you need a proper OS to run that thing on, but while we're all waiting for GNU Hurd, there's a guy from Finland who made a free *nix OS that's been gaining quite some traction recently. These Scandinavian guys are full of surprises. Maybe you'll be lucky again and there's yet another guy in Finland waiting to unleash a free software SQL database with joins, who knows.
> I don't see how it's going to beat Perl, which already lets you do the same things, but inside a full-fledged programming language
I don't know if you've heard of CPAN - it was introduced less than 2 months ago (October '95) and it's fantastic: you can browse and download modules off the world-wide web without hunting down tarballs on obscure FTP servers! The number of Perl modules on CPAN is growing daily! Any functionality
a webmaster may want can be achieved using Perl CGI scripts - I highly recommend the latest CGI.pm (v2) whixhbyou can get from CPAN
I found a wicked email CGI script on there that is all that and a bag of chips. You can transfer the script into your cgi-bin directory and submit a form to it to collect feedback and all that.
Just put an animated mailbox icon on your home page that hyperlinks to a form page. Put the usual <INPUT> and <TEXTAREA> elements for "from", "subject", yada-yadda-yadda...
Then put in "hidden" type <INPUT> form elements for the "to" value. Totally make sure to make it hidden!
Add a submit button, and bada-bing, you're all set!
You can even send messages to your pager! Check the manual that came with it.
I don't know, Java is such a new untested language, I'm not sure anyone will choose it for CGI programming over C, or maybe something like Perl.
[outside of kayfabe, Java was really first released in May 1995, only a few months before this press release, and was mostly used for applets and desktop applications (building a web browser!) - server side usage came a while later]
I've taken a look at Java and its standard lib and it's really bad at the kind of text processing that 99% of CGI programming is. Hell, it doesn't even have regexps! To be fair, C is even worse, but that's why we have Perl.
Yes, this does not make much sense to me. I will stick with Java and Perl until I see a viable reason to Go to something else. Maybe someone will create an improved version of C++ (though my skills there are rather Rusty).
Yeah, you’d have to install yet another runtime on all of your nodes to support server-side JavaScript.
I’ve been playing around with this new language called Python. The indenting syntax takes a little getting used to, but the code is way more readable than Perl. Just be sure to set indent-tabs-mode: nil if you use Emacs.
Perl is the only way to go for serious CGI scripts. It’s so powerful, Python is limited and clunky by comparison. And a new language with syntactically important whitespace? Seriously? It will never displace Perl!
Eh, maybe. well, nice talking. I'm going to go back to writing CFML. My boss bought a bunch of licenses with our last funding round, so I have to use it. I don't think it's going to make it any easier to write our reverse auction site for pet food discount coupons (don't tell anybody - we're still in stealth,) but whatever.
Not true. For your Unix hosts, you just need to write a perl script to strip carriage returns before running a script written on Windows, and substitute LF for CR for scripts written on a Mac and for your Windows hosts write a Visual Basic program to add CRs to Unix scripts and add LFs after CRs for Mac scripts.
If you figure out how to write an AppleScript program to munge the Unix and Windows scripts, let me know. Manually fixing them in BBedit is getting to be a real drag.
I think it’s fine so long as they come up with a consistent way to package this JavaScript code into modules. It would be crazy to have 3-4 competing standards.
> 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 current weather readings in a region. A server-side JavaScript script might pull data out of a relational database and format it in HTML on the fly. A page might contain JavaScript scripts that run on both the client and the server. On the server, the scripts might dynamically compose and format HTML content based on user preferences stored in a relational database, and on the client, the scripts would glue together an assortment of Java applets and HTML form elements into a live interactive user interface for specifying a net-wide search for information.
JavaScript is obviously meant as a glue language. Component-based programming is quickly replacing binary files as the method of deployment with technologies like CORBA and COM (the base technology for OLE 2.0). Java Applets are Java's answer to portable, client-side UI component. But in order to integrate them with a static web page or with each other you need some glue code, and this is where JavaScript stands: write reusable components that unleash the full power of Java, and tie them up together using JavaScript glue code.
I expect that in the near future Sun will introduce a server-side component model to accompany Java applets. It'd be cool if they use some coffee-related name for that, idk, maybe Java Beans? This is going to revolutionize servers and everybody is going to throw away their cgi-bin/ folder with hacky perl scripts and move to components. Think about it! Instead of writing your own code, you can wire up mature components developed, each developed by an industry leader:
- Advanced Forms Applet by Microsoft
- Server components for converting submitted forms into Excel spreadsheets, also by Microsoft
- Database client developed by Oracle
- Automatic stock ticker from Bloomberg
- Integrated website search from Lycos
- News applet from CNN
Sun is graciously aware of the great danger posed by the first company on this list, but in their great foresight they are going to define generic interfaces for every common type of component, and insert clauses into their license that will allow them to sue companies which try to extend these interfaces in an anti-competitive manner. Now, if you want to switch from Excel to Lotus 1-2-3 or from Oracle to Sybase or Informix you're also free to do so. The same goes for your OS, as all Java components are fully platform-independent. This is truly the future!
> I suspect most developers would opt to use server-side Java, and this in browser
But why create a new language just for the browser? It clearly makes more sense to use Java in both the server and the browser. We could write little Java applications inside the browser; say we call them "applets"?
That's definitely server side JS, but I thought the person I was replying to meant a web server that was written in JS, but I suppose "powered" could mean that it just runs JS.
I saw that link elsewhere in this thread after my reply, and I also thought that this might have been what was being referred to.
I don't see the point of this; you can already achieve something quite similar by compiling GNU PITA (Processor of Interactive Text Activity) with J.P. Blacker patch on top of it, which is publicly available on his FTP server.
Then to get interactive content; you just pipe the content of each page to the pita daemon using UNIX sockets and write the output to a file descriptor in the /dev/screen directory (just compile and mount the "interactive-wp" filesystem on /dev/screen first, of course).
The only gotcha is to ensure compatibility between these components, but someone shared a compatibility matrix on IRC a while ago, Sio it's common knowledge at this point.
> I also wonder what's the difference between Java and JavaScript, at first glance, they look very similar.
JavaScript is a scripting language and therefore much easier to use. No slow compilation and build step, no complex and rigid type system yelling at you, no dependency hell. Just type the code in notepad and press f5 in the browser to see it run. You dont need to understand advanced concepts like classes or packages or exceptions. It is as simple to write as an Excel macro.
Java on the other hand requires professional programmers, which are a lot more expensive than web designers, and less fun.
> You mean those graphic design people who try to make the whole page as a GIF, like they're making a print brochure, and just don't get hypertext?
> Don't worry, they'll clue in or get left behind.
Time traveler here. People with this same mentality are still working in 2023, but instead of making the whole page an image, they're making the whole page a "web app". Almost three decades later, they still don't get hypertext.
Whole-page gifs were only necessary because of the lack of layout support in HTML. But with the recent introduction of the powerful TABLE-tag, HTML now has a future-proof layout model which will surely be enhanced further with more tags, giving a fine-grained control over typography and layout.
> JavaScript is a scripting language and therefore much easier to use.
There are already scripting languages available. Why not just use something like Tcl which is lightweight and easily embeddable? Why re-invent the wheel?
Some history can be found at least here [1] and [2]. Based on that, the original idea was to build something that was based on Scheme. Then Sun came to the picture. They already had Java and there was pressure to have something that looked like Java. Story was that you would Java for the big stuff and Javascript for more light-weight client-side tasks.
That (marketing) worked out pretty well. At least for me it took years to figure out what kind of language Javascript really was. Seeing jQuery for the first time was kind of revelation.
> There are already scripting languages available. Why not just use something like Tcl which is lightweight and easily embeddable? Why re-invent the wheel?
This just begs the question: why are there already multiple scripting languages available.
And this further begs the question: why are people still "re-inventing" the wheel by building new languages?
"There was once a dream that was Rome. You could only whisper it. Anything more than a whisper and it would vanish, it was so fragile. And I fear that it will not survive the winter."
Anyone arguing that you can't use words to mean what they obviously mean and that everyone takes them to mean, but instead must only use them to refer to obscure logical fallacies is clearly nuts and should be ignored.
> At the same time, I intend to use the phrase correctly in the future!
These kinds of dual usages come up pretty often, but in that spectrum I find this one very interesting because it is somehow very good at scratching some sort of intellectual/elitist itch in all of us. Both usages are fine, but one is more rare (but not too rare) and "came first" so is ostensibly more "correct." Which makes it very satisfying to bring up in these kinds of conversations :-)
There is great synergy in having the two complementary language using (almost) the same syntax. E.g. Both use ‘this’ to refer to the current object, ‘new’ to create a new object, ‘==‘ to compare values, both use the same Date library which is throughly tested and future proof, both have wrappers to turn primitives into objects etc.
Surely this will avoid a lot of mistakes when switcing between the two languages.
Wow, that’s exciting! Maybe I’m being too optimistic, but does this mean we’ll soon be able to write single pieces of code that can execute on both client- and server-side?
It sounds like pure Java will get us part of the way there thanks to applets – which are also supported in Netscape 2.0 – but JavaScript gives much more control of the whole page. I played with it in an early beta when it was called LiveScript and wrote a crossword puzzle that didn’t need to reload the page at all. Amazing! Now if I can write the backend part in Java and have it work the same way…
I can’t wait for the Java and JavaScript syntaxes to unite and make web page development simpler. Netscape and Sun HQs are just a handful of miles apart, so come on folks, don’t drag it out! Could we get this before the end of the year?
If they had to chose an existing scripting language, surely Perl would be the obvious choice? Perl is designed after how humans think, where other languages force you to think like a computer.
1) Introducing scripting to the web can introduce security concerns, but this is the wrong way to think about interconnected systems. By far the greater security concern is trust models built over anonymous connections. When you can eliminate anonymity or the security implications therein most of the security issues that arise from the availability of scripting are like wise mitigated.
2) The greatest difference between JavaScript and Java is that Java will force OOP on you, in JavaScript functions are first-class citizens, and the scope model is always lexical. I abhor OOP and completely avoid the ambiguity of inheritance and keyword pronouns when writing JavaScript. Always choose composition over inheritance. When I see people intentionally do otherwise I immediately assume they have no idea what they are doing.
This, when read using 2023 political correctness caused me to have to wipe coffee off of my laptop screen. I'm picturing HR paying me a visit because my last commit misgendered the Person object.
Clearly the right approach is to embed a native plugin into webpages so that an actually responsible company can be put in charge of building high performance and secure runtime for this. Let's call it FutureSplash.
Well, MDL has < > conses and ( ) conses. These have a different type tag, but are otherwise identical. MDL uses that to give the two different semantics, situationally.
But the web can change, to allow all kinds of online applications, running in a sandbox, so no one has to install anything, but can play games, write emails, share and edit images or whatever - all in the browser in one language. Ok, we might have to tweak js a bit, to get there ..
I agree, but I wouldn't worry too much. This just adds new functionalities that weren't previously possible using straightforward documents, and may save some bandwidth and time by reducing the need for back-and-forth request/response to CGI servers for doing small calculations that could take place on the client.
As this has no relevance for serving and requesting pure documents there will be no need for us to use a java-script capable web browser if all we want is to read websites.
Agree, if we are to go in this direction I’d rather wait and see what Microsoft is doing with VBScript next year. It uses the COM to access elements of the environment within which it is running. That’s the future. Or Perl.
I can’t see the security issues you are talking about. But if there are, I’m sure it will be patched in a future release - so nothing to worry about there.
I think they are exaggerating. They will just use it to animate some images on websites. What can go wrong? Nobody would be crazy enough to program large applications in such a slow and sketchy language.
I don't know, the world is full of crazy people. In the end this will be used so much, that it will be heavily optimized, so people will compile their normal languages towards it. I mean, I am obviously joking, but in a crazy world anything is possible.
> The web is first and foremost a document platform.
I'm here from the future to tell you there's never been much difference between an app UI and a document.
> Adding scripting to it could cause security problem
Everyone eventually gets their shit together after witnessing the catasrophically bad security issues caused by idiots desperately avoiding javascript with even worse ideas and implementations.
What the hell is an "object scripting language"? I'm skeptical, but if there's a natural mapping of JavaScript objects to HTML element hierarchies, and an easy way for JavaScript to parse structured information received from a server, I suppose it could be a good thing.
Btw the security problems are solved by having Java and JavaScript running in a secured “sandbox” isolated from the underlying system. So security issues will be a thing of the past.
I just want to say that I absolutely adore all of you making comments like it's Usenet back in the day.
Now do the Netscape open sources Mozilla announcement on /.
You're all making me remember what it was like to delve into the weird and wonderful world of httpd, perl cgi-bin, and Slackware 3. (My first Linux!! I kept wondering why the system was so aggressive because it said it wanted to bash me for making mistakes: "bash: syntax error"!)
I have fond memories of working on Sony Broadcast's Linux-based digital interactive TV servers in London. Then packing everything up and transporting it to Amsterdam for IBC 1999 (I think?). Setting everything up was a real slog, but I got to see a trade show spring up from a bare floor into an amazing variety of booths. The construction was crazy complex and I'm astounded that it came together in time.
Thank you all, from this old dude, for the huge nostalgia trip :)
Going through the comments and felt the same nostalgia. Everyone is pitch perfect with the tone of the conversation 30 years ago. Camps of "leave well enough alone", "not another language", "big corporations trying to cash in on this internet trend".
Back in the day, some of us were programming snobs. Personally guilty of making comments downplaying the value of HTML and JavaScript.
> … with JavaScript scripts used to modify the properties and behavior of Java objects
Something I didn’t know was a consideration in the original spec of JavaScript: some sort of Java applet interop. I really thought the name was just a nod to it being a curly-brace object-y language! Does anyone know what that looked like? I know of <object> to embed applets into the document, which you could pass arguments to via attributes set by JavaScript, but the wording in this doc sounds like JavaScript could somehow use Java object instances?
I remember using it to implement hardware key security for a website. A Java Applet loaded a JNI library, after exploiting a JRE security bug to escape confinement, which interacted with the hardware key. The JavaScript then handled all the "browsery" stuff like setting cookies.
Am I reading this correctly meaning you send a "some_variable_that_i_know_about=deleteAll()" via Javascript and it will just run `deleteAll()` method on a Java applet that has god knows what access it has to things on your machine?
Yes. Applets were very slow to load, and more dangerous than flash. I think applet was the first tag removed. But at the time, you could load up excel in a tag with the right com magic.
If the applet chooses to expose such a method; reflection is about finding out what methods are exposed. And while Java had plenty of security holes applets were definitely not supposed to have a lot of access to your computer.
Signed applets had access to your computer. Even just before they were completely removed from the browser, which was just 8 years ago. You had to click "confirm" here and there, but in the end it worked.
JavaScript was originally going to be called LiveScript, associated with LiveConnect. It was renamed for marketing reasons, because Java components were seen as the future for code on web pages, and it could script the interaction between different Java components (potentially from different sources).
That fact it could be used equally for components written in other languages, if they were ever supported by object tags in common web UAs is why it had a more generic name initially.
Was it even an exploit? I seem to recall reading something about code-signed applets being allowed to load native dlls by design. Which is crazy, one single "trust signature" dialog prompt from infecting a system with malware...
I mean I'm sure there were a million exploits that would bypass even the check and prompt, but that doesn't change the fact that it's pretty crazy that native code execution was part of the design with just one small incomprehensible trust dialog.
At first, people weren't worried about security. It was just a bunch of us nerds on there. You interacted with real people that didn't seem like they were trying to swindle you. The world still used paper checks for anything big, and credit/debit cards were there, but not like today. It wasn't that uncommon to write a check and ask the shop owner to cash it next week, at least in my poor household.
There wasn't "online banking" or "online identities" to steal, so it didn't seem all that important. The worst thing that would happen is you would lose access to a chat handle.
Nope, I used an actual exploit, a type confusion bug somewhere within the RMI that allowed to escape the applet's ClassLoader. It then allowed it to access COM objects and basically do everything it needed.
The result was a "zero-touch" installation, with seamless login experience. It was a really crazy time.
Wild. So any other website could then do the same thing as you, accessing the hardware key and all...? Did anyone stop to think maybe this wouldn't be the best way to expose a hardware key? I mean, if you care about security at all, which you probably do if you're even bothering with a hardware key...??!?! %-)
At least running an .exe should be somewhat obvious to computer literate people. When I saw those signed applet dialog prompts, even as a developer it was not obvious to me that it also meant granting unsandboxed x86 code execution to a .dll/.so from the internet.
I remember developing an "interactive CD" with an Encyclopedia in 1998, which distributed a customized version of IE 3.2 (IIRC using something called the "Internet Explorer Development Kit").
The search function consisted of Javascript code calling an applet (which did the search using an internal database implemented in pure data structures within the code) and writing the results in the HTML. The database inside the Applet was so big, that I had to split it in two to be able to compile it (or was it for it to run? I don't remember the exact issue).
That's 25 years ago. Wow.
That was a big draw back then, along with the ability to interact with ASF and Real AV objects. We did a lot of really useless sites that did that in the late 90s.
> A server-side JavaScript script might pull data out of a relational database and format it in HTML on the fly. A page might contain JavaScript scripts that run on both the client and the server.
This is exactly what we do with server-side rendering today, huh. So the originally intended uses of JavaScript included servers too.
> 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
Back in 2000 there was a the Helma Object Publisher, a web application framework, written in Java, based on Netscape’s Rhino, afair, and enabling serverside Javascript including a form of ORM which mapped the db into JS objects. Antville, for a time the biggest austro-german blogging community, was and I think still is written in it.
>> 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
> This, not quite so.
Well, technically, one can (and often does) use Javascript to send an asynchronous request to a server that -when programmed using a Java based framework- will probably modify the properties of one or more Java objects, i.e., some entity, etc.
They were essentially the same idea as WASM -- a portable machine code that runs on web browsers -- but a quarter of a century earlier.
I suspect Java applets fell out of fashion because they could only manipulate a rectangular area of the screen and not the DOM. Did the DOM even exist in 1995?
The problem with Java was flawed sandbox implementation. Every month there was escape sandbox vulnerability. People didn't keep their JVMs up to date. Installing JVM plugin for browser, between x86, amd64 Edge, IE, with multiple JVMs on the machine, was a holy mess.
So in the end it was security nightmare.
Jobs finally killed it, by declining to support Java on iPhones. So from that point it was doomed.
WASM is part of the browser. Browser vendors figured out how to keep their browsers evergreen. You don't need to install anything, it just works. It works on iPhones.
So, yes, idea was the same, but implementation was actually good and supported by everyone.
The vulnerabilities and constant updates where the final straw that killed Java applets, since they convinced browsers that the unpopular Java applets plugin was a liability more than an asset. Java's security story was broken from day 1, but back when Java applets were trying to gain a mindshare security awareness just not there, and almost-weekly nag screens asking you to update your JRE were not a thing yet.
It's also not the fact that users rejected the idea of apps that are restricted to a rectangle inside the web browser - after all, Flash and even ActiveX (to a limited degree) managed to churn out popular apps running inside a (badly) sandboxed rectangle. Some of the popular use cases (e.g. games) did not die, and are now faithfully served by WASM. Rectangle-constrained applets are obviously not good for every use case, but Java applets failed to succeed even at the places where Flash shined later.
Looking back, I think what killed Java applets was that they were just slow, ugly, hard to interact with and had bad developer experience. Developing HTML pages was easy - just a change/reload cycle. The same goes for cgi-bin scripts. Java applets required compilation, packaging and then testing, at the time when automated building tools were not there. IDEs with RAD designers that tried to improve the experience did come, but at least most Java IDEs I tried back then were quite cumbersome to use compared to incumbent native RAD tools like Delphi or Visual Basic.
In addition to that, Java applet support was initially spotty during the browser wars, and features such as JAR files and different JDK 1.1 (and later JDK 1.2) APIs were not evenly supported across Netscape Navigator and Internet Explorer[1]:
https://www.infoworld.com/article/2076251/applets--still-ess...
And then there's the slowness and ugliness. You really only had AWT available for your UI and graphics, and it sucked. It was ugly, buggy and slow. In theory, it shouldn't have been so, but the technology just wasn't ready and just wasn't
mature enough.
I think Flash was so wildly successful because it took an entirely different (and less ambitious) route at the beginning. Flash started as a multimedia player with user-friendly authoring tools. They later added ActionScript and Flash itself become the RAD tool that could penetrate the web frontend.
Ease of development and speed of loading really makes a difference.
I remember just sitting around looking at these Java Applets loading whole applications. While Flash games were snappy.
The moment you hit some webpage and it shows you a Java Applet loading bar you knew the website was useless basically.
I think this had quite a bit to with Java and the way it implemented UIs. Also just serving a whole bunch of unnecessary stuff. To be fair this eventually became an issue with JS as well, but not the the same degree compared to the network speed.
They fell out of fashion because you had to install JRE on the client machines and because they ended up with an icon in the Windows task bar that obnoxiously asked again and again to download a 100+ MB update week after week. Internet was slow, still a lot of 56 kbps modems, and many people never upgraded and ended up hating the experience. Flash was better looking and they had a much compelling reason to download it, games.
No, Applets were just clunky and slow-loading--that's why they weren't popular. Any website loading one would freeze up the whole machine. But there were definitely Java Applet games, and I happen to remember the last one I ever played: Minecraft.
Flash loaded quickly and seamlessly, but otherwise had all the same problems.
Damn, I remember playing creative minecraft back in 2010, a surprisingly good experience for a java applet embedded in the browser. All running on linux with fairly smooth opengl rendering. I also remember using a wrapper/front-end called world of minecraft that allowed you to run the jar outside of the browser and even had multiplayer support...
I think in the end they were basically replaced by Flash and Shockwave, which were much easier to use for what most people were using Java applets for. Then, of course, Flash was abandoned because Adobe, being Adobe, seemed to absolutely refuse to fix many of the huge security issues that Flash had. Steve Jobs then led the fight against Flash, and that basically leaves us at today.
Remember that even after JS was released it still took many years until it became fast enough to use for big applications. If I'm not wrong, Google Chrome was made partly with the explicit goal to have super fast JS.
While the limited facilities provided in the first generation of JavaScript and JScript for detecting events and manipulating HTML elements eventually came to be known as "DOM Level 0", it wasn't until 1998 that the first DOM specification was published. Source: https://en.wikipedia.org/wiki/Document_Object_Model
I never understood these books. Who reads a 1000 page book to learn a programming language? I bought this particular book some 10 years ago hoping to "master" javascript. The book was so dull that I could not even get to the 3rd chapter. There are books about much more complex subjects that wrap up in < 400 pages. What's really the market of these doorstop books?
There's a lot of value to having "everything in one place" during the learning process and later for reference, plus the convenient dead-tree format means bookmarks are instantly accessible. They're also written by competent people and edited by professionals. I'm a fan.
Of course when one's chosen tech is too new, and/or moving faster than the book publishing process then one is stuck with Stack Overflow, random blog posts and insufferable YouTube vids. Which all also go out of date within a year.
It’s mostly gone now with the Web but having a go to book used to / can still be a really good reference.
In the nineties ones like the Camel book for Perl were practically required reading in their fields.
They don't make a lot of sense now, reference material is generally kept in electronic form, often online not locally, both because it saves resources (paper, space to store it) and because things change and online content is so much easier & cheaper to keep up to date. That and things change faster ATM in most tech fields.
But think back to the late 90s when many, even devs, had little more than a slow and expensive (per-minute phone call costs) dial-up connection that blocked other calls while active, and having a local resource that you could flick through to find details makes a lot more sense. Also not having convenient easily portable devices with which to store and read the information makes a huge difference. Even if you did have a laptop it was bulky and the screen was not particularly nice to read from. Heck, desktop screens were headache inducing compared to modern kit (imagine a goldfish-bowl like CRT, 14" diagonal, less because you shrunk the display to avoid the really rounded bit at the edge, 15" if you were lucky, 17" if you were rich, displaying at 640×480 or maybe 800×600 resolution (maybe 1280×1024, again: if rich), in 16 or 256 colour depth so no font smoothing, with a pretty low refresh rate) making reading the information from the book much more pleasant even if you did have a local online copy at your fingertips.
Those books tended to have three parts and you weren't expected to read them all cover to cover:
1. Fundamentals, which you would probably read fully unless you had a fair amount of relevant experience of similar languages/environments in which case you'd skim to pick out the key differences.
2. Specific parts in detail, which you would read some sections of but ignore others until you needed them later. This might include worked examples of using common parts of the standard library and so forth.
3. Reference detail. This might be half the book or more, maybe two thirds in some cases. This you would not read as such, you would use it like a dictionary or mini-encyclopedia. That is the part that makes least sense in the modern world.
If you want a really extreme example: I had a copy of the the MS's C/C++ compiler, the full documentation for included a printed reference to the Windows API of the time (Win 3.x era). IIRC that stack of books, piled on the floor, came up to noticeably more than half my height. The vast majority of that was tools and API reference material, though small chunks were intended for more end-to-end reading.
The huge books did seem to hang around beyond their really useful period. I don't think I bought a dead tree like that as late as 2010, so your “about 10 years ago” is probably when they were well past prime. Even in their prime there were some really terrible examples (poor tutorial sections, reference sections that were out of date before they were even published, and full of errors on top of that).
Yeah, a lot of younger folks don't get this. In 1995, the web wasn't like today, only slower. There were no web search engines, only catalog pages like Yahoo. Documentation was often so hard to come by, View Source really was your only option if you wanted to learn newer techniques. That AND it was slow: a 14.4 modem downloaded 1MB every 10 minutes under optimal conditions (no one called while you were connected).
While the modern Internet has certainly changed how documentation is published, your suggested three-part breakdown seems as relevant today as it did when documentation was mostly delivered in print.
It's also worth pointing out that being able to skim comprehensive, reference-style documentation to get a general overview of a technology without getting bogged down in irrelevant-for-present-purposes detail is a useful skill to learn.
“As the art of reading (after a certain stage in one’s education) is the art of skipping, so the art of being wise is the art of knowing what to overlook.”
At the time there wasn't really a good search engine, Yahoo's hierarchy of interesting sites was just starting. No Slashdot and no Google to find it to see how to do things or fix particular problems. Not much OSS to take as an example. Online doc was dry and limited. Blogging only started in 1994 so not much out there yet. But as the web took off books quickly became almost irrelevant.
The framework obstacle course for developers took off. My particular path through it was POJS, YUI-ext, EXTJS, Dojo, jQuery, Backbone, Angular, React - probably about 2 years each give or take.
They were also language references. What we are googling now was in those books back then. The second half of 90s was the tipping point between books and web docs. Books were at least 6 months behind the web docs and web technology moved faster than today. It was less wide in scope but it changed a lot. Think about the times when Javascript changed a lot in the early 2010s. It was something like that.
You could dip into sections of these books and pick and choose what you needed to learn. I don't think I ever read most of the three or four hundred books I bought in the period from 1985 to 2006 in a linear fashion. By 2006 I'd mostly switched to learning new stuff from online sources.
Following that time frameworks like ASP or Coldfusion (?) had server side JavaScript for code snippets similar to what the browsers were doing on the client. So I think, the JavaScript on the server note here is more addressing the ASP use case then the nodejs one.
First, Sun should really have implemented its own browser. They basically already had something that shared most of what a modern browser can do when they did NeWS. Basically NeWS that loads postscript over the internet is most of what a modern browser does. Sun should really have done its own browser, rather then do the deal with Netscape.
Second, Sun had developed Self and made it really fast. It shares a lot with Java Script and would have served perfectly fine in that roll. But instead it took 15-20 years until some of the same people who worked on Self and later Strongtalk to make JS fast at Google. Java Script could have been fast as soon as it came out if it was based on Self, rather then scripted together in a few weeks by Netscape.
I think Sun systematically messed up with the whole software division staring in the 80s and got worse in the 90s. Amazing things like NeWS were kill, tons of bad ideas were adopted that around Java/Corba that were clunky.
> HotJava (later called HotJava Browser to distinguish it from HotJava Views) was a modular, extensible web browser from Sun Microsystems implemented in Java.
Are you saying they should have added JavaScript to their Java based browser?
I remember that and also remember them releasing a new version that literally didn't work on yahoo.com. I complained and they said some snarky comment about not complaining about things that were given for free.
That's Sun management for you. At Sun some people wanted to build a browser and really invest into it, but Sun made deal with Netscape instead. And the HotJava thing never had to many resources for development.
James Gosling tells stories of how hard it was and what it took to get basic demos running and then a little later its a product.
They really did mess up their software division. So much lost potential.
Sun, like many of the other Unix vendors of the time, wanted not only to invent the new world but to fully own and charge for it. Self only got open sourced long after it was of any interest or relevancy, NeWS never was, and the OpenLook stuff generally only got really "open" after Motif "standardized" (itself a joke since it never got actually used outside of proprietary-land) and it wasn't until well into the 21st century that the JDK became properly open sourced.
But in fact the relative openness of Java at the time it was launched seemed like a bright spot in this, and in part this was why it was so ascendant through the 90s.
BTW I like Self, but I actually don't think it would have made a good JS-equivalent in a document browser. It really is, like Smalltalk, something that wants to rebuild the whole world in its image, and not much of a "glue" language, like JS was initially pitched as.
The problem was they spend 10 year going on Java crazy but didn't actually develop many good products that made them money. At a time when IBM and others were actually making money from Java.
I think Self could be made into that, it just a challenge of API and how its integrated. And at the end of the day you want to have a full featured language fully integrated anyway, as JS basically became overtime.
Then they got excited about Java and renamed it which confused generations of programmers.
No one understood the power of JavaScript when it first came out. For example at first hardly anyone understood Closures, and the full power of JavaScript being a functional language.
And when Google made Google Maps which was dynamic unlike MapQuest it was a revelation and influenced so many people in what JavaScript (and the web) could do.
I always thought the name was just a little wink and a nod towards Java and nothing more. So I was surprised to see this in the press release:
> complementary to and integrated with Java
Was this ever true around the time, and if so was it ever really used? I know that now we have a couple of JS implementations on the JVM, like Nashorn, that would represent some level of integration (you could call JVM methods from JS) but the idea that Javascript was "integrated with" Java back in 1995 sounds a little far-fetched.
The whole point was to let websites interact with java applets on the site. If that’s not integration then what is? Either you’re splitting hairs or you’re forgetting that applets were touted as Java’s killer application at the time.
Well I was 9 years old in 1995, didn't get the internet until 1999, and only started programming in 2001 (and even then it was Perl + C) so that was an honest question from someone who didn't experience any of this first-hand.
If one of its original use-cases was to facilitate some kind of browser/applet integration then fair enough. But in the linked article there are only vague references to this that sound a bit weird or confused, like "the scripts would glue together an assortment of Java applets" or like "JavaScript will allow us to easily create personalized applets for the Excite service".
edit: looks like Bill Joy himself said "JavaScript will be the most effective method to connect HTML-based content to Java applets" in the article, but I'm still curious how deep this connection is, or if it's just hand-wavy "our new tech is great and I have to tie it to another currently-popular tech somehow"
Fwiw if you really are asking an honest question, consider not calling things a little far-fetched, esp if said things were true.
Anyway, I’m your age so I’m not 100% sure either but my understanding is that applets, for quite a while, were considered the software delivery platform of the future. Just open a webpage and get an entire end-user program running right there, no downloading or installing, nothing. It turned Netscape into something of a universal app store and people were very excited. JavaScript very much was intended to let the rest of the web page interface with the software program (the applet) running on it.
Your excite quote shows a key use case: ship a generic compile applet in a site which contains user-specific data, write a little JavaScript to send the data to the applet and poof, it’s personalized! Magic.
That success never happened though (and I’m not sure why), and most uses of applets I saw were of slow, ugly navigation menus with hover effects and stuff like that.
This isn't debate club or a courtroom, there aren't rules on how we can share how something sounds to us in an informal setting like this. If you want a nice discussion consider being a bit more polite, less confrontational and assuming good faith.
The intention was that Java components could be combined and scripted through JavaScript. Such a component-based development model had proven succesful in Visual Basic, and Netscape hoped to create something similar for client-side web development.
I think where I was confused is that the applets were already programmable and interactive, so I'm just not sure what throwing JS into the mix brings. But it could be that there's some functionality it gained (XHR, perhaps?) in the intervening period that it lacked at the time.
The thinking was that JavaScript was a scripting language and therefore much simpler to use than Java. So web designers who were not professional programmers could combine a few predesigned Java applets and script them using JavaScript.
Of course these days with package managers and build systems and TypeScript, JavaScript is a lot more complex than Java ever was.
Yes, applets were already interactive and programmable.
But they sort of ran "in a box", like Flash. So you have this particular rectangle in the page, inside of it something runs and works and does its thing... but outside of it, the rest of the page knows nothing of that.
What JavaScript was supposed to bring into the mix was that you might have a Java applet doing some "heavy-lift" stuff and then, you'd use the results of that to operate on other elements in the page. Like maybe you'd update a form, or some data in the HTML, or whatever. Also, obviously, the other way around. You might have some HTML controls that would then feed user data into the applet.
Yes, you could do everything inside the applet, but this offered an additional option.
> For example at first hardly anyone understood Closures
At first, closures weren't even available. I mean, in 1.0 and 1.1 you could only declare global functions. 1.2 introduced function expressions and closures. That was June 1997; the language was still changing quite a bit and it wouldn't be until ECMA standardization that things would become stable and clear enough for people to use. (Even though there would still be huge differences across browsers for years)
Arguably the real game-changer was GMail, which pre-dates GMaps. It introduced a lot of people to XHR, which was previously used only by people keen on XML/XSL.
The innovation of Gmail was “so much storage you never have to delete emails again”. The UI wasn’t too different from contemporary incumbents such as Hotmail.
It had that as well, and undoubtedly it was the main attraction, but iirc it was already not refreshing the whole page when clicking on the email index to read a single email - if not at launch, very shortly after. They later added "html mode" for compatibility with older browsers.
Storage was definitely the killer feature, but I remember thread view, good search and AJAX navigation to be significant improvements over eg hotmail at the time
It wasn't Gmail that started XHR though. Gmail wasn't even first online email service to use XHR. The first app to use XHR, which is also the first email service to use XHR was Outlook Web Access.
It's funny that Microsoft were the who were innovating with better features and a more coherent vision during the late browser wars, but they failed to capitalize on this innovation once they won the war and they could now just release IE6 with a shiny Media Bar and then fail to update it for 5 years. Nothing would ever go wrong, and no competitor could threat Microsoft, since all these toolbars everybody seem to adore are only compatible with Internet Explorer anyway. Yeah...
JavaScript was not very powerful when it came out though. It couldn’t modify the DOM (except input controls) and it couldnt perform background requests.
Maps was amazing but I remember being blown away by xmlHttpRequest and the dynamic search that autocompleted. It had hilariously little to do with XML.
Er, it had everything to do with XML. It was introduced to give pages the possibility to fetch XML (typically feeds) and render their content dynamically; which is basically what it ended up being used for, except XML feeds were then replaced by simpler files.
XML in XMLHttpRequest was first superseded by HTML and then by JSON. And JSON only because the JavaScript API for XML (aka. the DOM API) is the worst thing imaginable compared to the simplicity offered by JSON.parse and then the JS native representation of it as objects. The same ugly DOM API let to the advent and rule of jQuery.
The success of JSON has less to do with verbose/clunkiness but a lot with the available APIs in the JavaScript frontend.
> compared to the simplicity offered by JSON.parse
JSON.parse() came a lot later. People started with eval(), which lead to quite some problems (executing code returned from some third party service, what could go wrong ....) and then various other attempts at parsing.
I was curious about this so I looked it up. We didn't have JSON.parse and JSON.stringify in place worldwide until fourteen years later. Horrible times.
It is good to remember that that JavaScript is not the JavaScript of today even if the programming languge is the same (taking away the evolution).
For years JavaScript was only used for very small stuff like changing the color of a button in a mouse over.
The inflection point began lately with the inclusion of XMLHttpRequest [1] which enabled to have web apps instead of static pages with basic transaction forms. Then obviously another inflection point was NodeJS (and Google Chrome launch with the V8 engine).
My point is that the launch of JavaScript in 1985 is independent from it success later.
Beyond this, my personal opinion is that launching a VM specification would be better than announcing a specific programming language. WebAssembly comes very late to the game.
Wouldn't it be more accurate to say that V8 itself is the second inflection point?
NodeJS (which is just the V8 engine plus a server-side runtime environment) seems to owe a lot of its success to Google creating an actual fast, JIT-compiling JavaScript implementation in the form of V8.
In fact, the entire Cambrian explosion of new Javascript frameworks in the 2010s probably would not have taken place without V8 enabling them to run with acceptable performance.
The inflection point was later. Significant client-side logic in javascript was not a thing until gmail and google maps showed the way in 2004/2005. Even then it wasn’t until jquery in 2006 that the ball really started rolling. The browser could do it in 2001, but it took half a decade for web development to catch up.
What can today’s browsers do that web development hasn’t caught up to?
> What can today’s browsers do that web development hasn’t caught up to?
With WebGPU, WASM, WebXR, WebBluetooth, WebUSB, WebTransport and more already/soon enabled, I'm fairly sure we're just scratching the surface currently on what use cases can be built with today web technologies.
Also, things outside browsers are changing enough that the use cases also expand. Bandwidth, latency, availability and more are also improving, enabling fancy stuff we couldn't dream about some years ago. The other day one of the HN submissions loaded a multi-GB file for client-side evaluation of a Stable Diffusion model, as just one example.
I agree. GMail and Google Maps showed a complete different web but XMLHttpRequest was needed for that and was a milestone even if there was no web app to show at that time.
We should also take into account that Flash [1] was the technology that ate the limitations of the web. Flash was really powerful. More in a moment with low bandwidths around the world. For example this late 90 animation would be impossible to stream [2].
ActiveXObject("Msxml2.XMLHTTP") was important but it was introduced with IE 5 in 2001 and it was a few years before it was available everywhere. DHTML (D for Dynamic) started in 1997 or so with IE 4. XmLHtTpReQuEsT wasn't entirely novel -- people were using iframe tricks to make server requests. iframe hackery continued for a few years afterwards since xmlHTTPrequest support was still iffy.
Imagine if companies provided contact information on software releases today. You know, where you could call and a human being would pick up. Maybe you could even get some customer support!
I doubt you would get customer support from a press contact. Companies still provide phone numbers in these kinds of statements and just like then they don’t deliver support.
There is a special place in hell for the people on social media with followers who use that leverage to shame companies into priority customer support.
"@TimeWarner! My connection is down! Help me NOW!"
Funny enough they've more gone from being integrated with each other to being in some sense parallels of each other, if you're willing to stretch the definitions a little bit, as one of several languages executing on top of a VM (V8 and friends and the JVM).
"JavaScript is an easy-to-use object scripting language designed for creating live online applications that link together objects and resources on both clients and servers."
Interesting to note the mention of servers!
I actually forsee a wave of JavaScript innovation within the concept of a traditional backend server coming soon, and it's interesting to see them mention a server here.
I've forever been from the school of "Rule number 404: thou shall never use JavaScript on the server side.".
But with React 18 and the serverless wave, I can totally see myself writing backend controller code in TypeScript that gets deployed by Vercel in the near future.
We migrated our api server from flask Python to node-express-typescript. The gains of async, stricter typing and being able to share api schema types with frontend were totally worth it.
If Netscape hadn’t introduced and managed to establish their scripting language before Microsoft steamrolled them, then the standard language on the web would be Microsoft’s contemporary alternative which was VBScript — in other words, BASIC.
Yeah, people here seem to forget that Javascript had actual competition in the browser space back in the day. It was very likely the winning browser-side language would have been a proprietary one, which isn't the world I want to live in.
While I very much wouldn't want to live in this world too, I'm pretty sure VBScript was an answer to JavaScript. Internet Explorer 3.0 implemented both VBScript and JScript (Microsoft's slightly incompatible version of JavaScript) at the same time.
Microsoft of the 1990s seemed to never be able to decide whether they want to follow "Embrace, Extend and Extinguish" or NIH, so they usually both implemented slightly-incompatible versions of popular technologies, and then shoved in their own in-house technologies alongside.
That's how you got both ActiveX Controls and Java Applets (both sucked). That's how you got both Visual J++ and Visual Basic (J++ was superior), and later both J# and C# (this time C# was superior, but could you expect anything less from Anders Hejlsberg?). That's how you got both VBScript and JScript running on JScript (a little know fact that made it possible for me to script Windows 2000 machines without running through a decade's supply of vomit bags).
If there was no JavaScript, I think Microsoft would have gone with something like ActiveX, instead of rushing to deliver their own a quick and dirty implementation of a scripting language. But we wouldn't get an almost-decent scripting language embedded in every windows machine, and I would have had to automate all these machines using BATCH files!
Nah, if I were to go back in time I'd just push them to clean it up a bit before launch.
In the end, JS has been a net good for the industry. I don't work in it, but it's turned into something decent over the years though the frameworks around it are insane. But it took 15 years to get to this place and become a "grown up" tool, imho partially because of some odd choices early on.
Scoping: Especially initially, the scoping rules were really wonky.
OO: I am actually a fan of prototype inheritance (Self & LambdaMOO FTW) but the form implemented in JS was confusing for most people and they never understood it, esp given Java was ascendant at the time with its very strict and boring class-based model. I think some clarity was needed here. Lack of standardization around how to do objects, inheritance, encapsulation led to a total bizarre mixture of approaches and misunderstandings.
Essentially I just think having it passed over by some more sober minded language designer types who had research background in e.g. Scheme, Lisp, Self, etc. would have been good.
Going all in on JS instead of wasting time with the ill-fated Java applet stuff would have been good for the industry. It's what the industry ended up doing eventually anyways, but it took until the 2000s before this really clicked for people and they finally gave up on the various half-baked dynamic plugin solutions (Flash, ActiveX, Java applets, etc).
The "Java" in the name was/is a problem and led to a decade of stupidity. I understand how it happened, but it shouldn't of.
> Lack of standardization around how to do objects, inheritance, encapsulation led to a total bizarre mixture of approaches and misunderstandings.
That void never really existed. There was the right way to do it, basically the same way that ES6's class syntax actually works today, and then there were a bunch of people fooling themselves into believing that the impedance mismatch that resulted from writing code against their own derpy metaprogramming system they'd devised themselves was acceptable. The attitudes associated with that mindset never really went away—it's what drives the demand for stuff like Webpack, along with NodeJS's CommonJS-inspired approach to modularization infecting everything and the README for create-react-app providing list of steps to get someone up and running requiring them to download half a gigabyte of packages to their disk before they can successfully complete the Hello, World exercise, not to mention the abstraction (and resulting boondoggle) that is React itself.
If I put myself back there in the mid 90s, I actually don't think Netscape paid it (OO semantics & standards) much heed because the purpose of the language at the time really was just to add some minor scripting behaviour / actions to pages, not to build out applications.
Actual "serious" uses of JS didn't really ramp up until the end of the decade, and by then people were doing what you're saying, yes.
Netscape releasing a style guide with the language, and a set of standard libraries that used them, that would have helped.
But everyone back then was too distracted with "Java is the Future of the Browser" (Narrator: It Wasn't)
Sun had Self that was already incredibly fast. Instead of suffering threw 10+ years of terrible performance, we could have had a fast language back then.
No, no, Java is old and slow. Let's compile typescript to javascript, write the user interface in React and HTML (with some parts hidden in CSS files with some selector and expression magic to make it more fun), and WebAssembly for the performance critical stuff. Easy-peasy.
Why would you not want to make your application's build process dependent on a dozen plugins that will no longer be compatible with each other in the next version? Are you even a real programmer? /s
I know it's the fashion on HN to hate Javascript but it opened the gateway for programming to generations of people and made the web substantially more fun and useful in many ways. It's not Javascript's fault the language was ruined by SV and survellance capitalism.
I think that the way we build user interfaces today on the Web is fundamentally flawed. One need to learn JavaScript/TypeScript, then HTML and DOM, then CSS. Then most likely you need to learn Angular or React or Vue or whatever, some widget toolkit like Bootstrap, get accustomed with Webpack, minification, uglification, rely on countless MIT-licensed libraries whose authors may come and go because the base runtime (=the browser) just gives you DOM, CSS and plain JavaScript.
Did you ever tried implementing a desktop UI using an object-oriented multi-platform toolkit like SWT or QT or GTK? There are good chances that all the dependencies you will need are already "there", you learn the widget toolkit bindings for your preferred programming language and you can start. It's so much more productive and fun (at least for me) and most of the time you don't need to mess up with colors, styles etc. etc. because you will want the operating system to take care of that.
On the Web you have so much more freedom, because the web page is almost a canvas, but at the same time (for me at least) it looks way less productive and everytime I think of it, I always wonder why nobody is proposing anything better for the Web and the industry keeps on building layers of complexity on top of JavaScript/DOM/CSS.
> Then most likely you need to learn Angular or React or [...]
For a very loose definition of "need".
> Did you ever tried implementing a desktop UI using an object-oriented multi-platform toolkit like SWT or QT or GTK?
There's an abundance of desktop application code written in JS from the GTK+ folks themselves. They embraced SpiderMonkey (the Mozilla JS engine) years ago and have been shipping stuff on it for just as long. Anyone who has booted into the default desktop on Ubuntu—or any other installation running Gnome—has already come in contact with it, perhaps even today. That doesn't get a lot of attention, though, because it's not "squeaky": it isn't plagued by the same problems that people (stupidly) associate with "JavaScript" despite the fact that what they're really thinking of are problems with the NodeJS/NPM community in particular and its spectacular tooling + other webdev-oriented accomplishments. I.e., all the things it insists are requirements for the Modern Programmer—a mission which their detractors assist them on by perpetuating the story themselves (cf "need")...
I am not familiar with JS in GTK+, but if it's a JS binding for GTK+ it's exactly what I meant when I said that on the desktop you can implement a user interface using your preferred language as long as bindings exist for a decent widget toolkit.
And it sounds totally legit to me. If instead what you are referring to is something similar to Electron, that is something I "hate"; I understand it's a cheap way for a Web Developer to reuse the skills and build a desktop application, but the result is typically buggy, bloated, slow, and does not integrate properly with the desktop environment (fonts, colors, clipboard, accessibility are just the first things that come mind).
I'm responding to your thread—the one where in response to your suggestion that it would be a good thing if it were possible to prevent "this" (presumably the introduction of JS in 1995, the topic of the submission), the person replying to you wrote, "I know it's the fashion on HN to hate Javascript[...] It's not Javascript's fault the language was ruined by SV and survellance capitalism."
The things you're complaining about are not a JavaScript problem. They're a programmers-who-have-their-feet-firmly-planted-in-the-world-of-NPM-and-modern-webdev-tooling problem.
> something similar to Electron[...] is something I "hate"
Wait till you find out how Firefox itself (i.e. the UI and other application logic) is implemented: "DOM, CSS and plain JavaScript". Mozilla was doing Electron-style apps before Electron ever existed. Somehow it's a higher quality app than the sorts of things you had in mind when you brought up Electron. Again: that's because it's not a JavaScript problem.
Sure, I am not against JavaScript per se (although my preference goes to strongly typed languages), my first comment had a smiley at the end, I just firmly believe that the way we build UI for the Web today is flawed.
So don't build them that way. You could do worse than ignoring every piece of advice that is considered best practice in mainstream modern Web development.
Some really wild stuff about the genesis of JavaScript. I've never heard about HyperCard until now.
Great example of why it's so important to understand computer "innovations" with as much historical context as possible, so as not to fall into the pop-culture mindset, which completely ignores that which went before, and thus is extremely unlikely to create something new without that understanding.
I started with the Internet in the late 90s, so you could say I've been here most of the way, and I am still always fascinated by the stories and movies about the early days.
Not only does it stir up the memories of the craziness, but it reminds me that most of the things we do today are not that ground-breaking. The young generation of engineers is just relearning the lessons we did - with faster CPUs and bigger screens.
I know there many tongue and cheek comments here on this, but what a time to be alive back then. Can you imagine these same corporations agreeing on anything today to be an open standard used by all, documented in the open and working on collaboratively?
This was a watershed moment in technology for that alone
So this is the infamous communication that followed the move to add Java in the name just for marketing? Crazy how I still occasionally hear the confusion. Also interesting to see how strong was the object-oriented fad.
I remember using Lynx browser in around 1990, and telling a friend "this thing really needs a scripting language". Then I started using Netscape and kept saying "This thing really needs a scripting language". When Javascript was introduced, I was immediately a fan, dove right in, and never stopped. Knowing Javascript has been paying my bills for decades.
> "JavaScript is also a promising core technology for the new multimedia publishing tool that Macromedia is building."
I believe Bud Colligan may have been speaking about ActionScript in this quote, the scripting language found in their yet to be launched Macromedia Flash product. Of course, Flash is no more... and neither is Macromedia. Time flies!
If this is exciting for you then you'll love this podcast with Brendan Eich. Brendan Eich is the creator of JavaScript and co-founder of Mozilla and Brave.
Why do we even need this? If I want to animate text I can just use <blink> tags. Also, not everyone has high-speed dialup yet. Phone bills are going to go through the roof!!
And the web is far worse off I reckon after this weekend hack job - currently busy with React JS project using Bootstrap - so much effort for merely displaying stuff.
Static typing doesn't make everything fast by itself.
In fact once your static typing is sufficiently advanced, you run into many of the same problems in terms of optimizing.
What is actually baffling is that Sun had Self with super advanced compilation, the highest performant dynamic language and instead of using that, JS happened. And the people who did Self, then went off did Strongtalk HotSpot, then Java HotSpot then were bought by Sun again. And then eventually Google hired the exact same team to do the same thing for Chrome (and then later Dart).
So really just using Self would have saved a solid 10+ years of detours only to end up with what Sun had in its labs in 1992.
Javascript is a constant reinvent of the wheel. Sites had become much bigger and much slower contrary to JS crowd promises. Development is a devilish entanglement of tens of thousands of tiny libraries, and almost every one of them is changing several times a day. I do not do frontend programming now, but I see how slow it became compared to the old good Web 1.0. Monster frameworks that require changing hundreds of files daily, sometimes front development is behind backend development because of this burden and cognitive load.
And one fact which annoys me the most: in all other areas we are free to choose any language to do the job. But in the web we're forever stuck with one language which was quickly concocted in a few days and still to this day many of the original flaws remain.
I'm not a fan of JS myself in all honesty (just not my favourite language to code in), but I think your first point is more about front-end dev culture than flaws inherent to the language itself.
An alternative world could have existed where we have the same exact Javascript, without the culture of using "tens of thousands of tiny libraries" which change "several times a day". It was possible to avoid these faults while still keeping the language itself.
So I think it's unfair to say (as the comment you agreed with said) that Javascript is the worst thing to happen to the web, because all the cognitive load being pointed to comes from widespread human usage of the language rather than the language itself. That's on us.
Personally, I distinguish the culture of using tens of thousands of frameworks from JavaScript the scripting language by calling it all collectively JavaShit.
JavaScript is fine, but JavaShit and everyone who partakes in it are a plague.
> Sites had become much bigger and much slower contrary to JS crowd promises
Where are those people promising slimmer and faster websites compared to absolute no JS?
> Development is a devilish entanglement of tens of thousands of tiny libraries, and almost every one of them is changing several times a day
Nothing to do with JS. Many libraries is a symptom of popularity and them being tiny is caused by trying (unsuccessfully though) to send the absolute minimum over the wire.
> I see how slow it became compared to the old good Web 1.0. Monster frameworks that require changing hundreds of files daily
What web 1.0 was doing is completely different to what the current JS apps are doing. Good luck implementing Figma with the good old web 1.0. I'd even say good luck implementing it anything other than the current web-app dev stack or some custom native UI library which would take a millennia to develop.
> sometimes front development is behind backend development because of this burden and cognitive load
backend and frontend dev have completely different constraints. Doing frontend dev for a native app is also cognitively nearly completely different monster.
> in all other areas we are free to choose any language to do the job. But in the web we're forever stuck with one language
I mean you could always compile to JS and these days there are many good webassembly frameworks.
> still to this day many of the original flaws remain
But also almost always easy to avoid. It's a necessary evil for backward compatibility.
> Where are those people promising slimmer and faster websites compared to absolute no JS?
The crowd that claims, that reloading the page is bad and therefore there must be JS involved to only generate parts of the page dynamically.
> Nothing to do with JS. Many libraries is a symptom of popularity and them being tiny is caused by trying (unsuccessfully though) to send the absolute minimum over the wire.
I think it does have to do with JS: JS did not offer much. Many things were missing. Other things were so bad, that people build abstraction layers on top, to hide the uglyness of JS underneath and then published those layers as libraries. So the language itself has at the very least historically directly contributed to the current state of affairs of thousands of mini libraries. Even JS developers themselves don't trust JS or their own ability to work around JS' quirks, so they include left pad and other funny things.
> What web 1.0 was doing is completely different to what the current JS apps are doing. Good luck implementing Figma with the good old web 1.0. I'd even say good luck implementing it anything other than the current web-app dev stack or some custom native UI library which would take a millennia to develop.
Not the GP, but I am also against the Figma pipe dream designs being pushed onto the frontend developer. In my opinion a good web designer should know CSS well and know the implications of their design ideas before pushing them onto others. Want to make a design that has something, that is difficult to achieve without JS? Better think 5 times about whether you really need it and whether that design addresses fundamental functionality of the website.
> But also almost always easy to avoid. It's a necessary evil for backward compatibility.
Only by writing code you usually would not have to write in other language, to plaster over JS' faults, or by including lots of tiny libraries as dependencies, dooming your project in the long run.
It's the generic HN snark that pushes for no JS websites for everything, without considering the benefits of users having such a powerful VM that probably protected them from running random executables.
My web development practices were nurtured in the late 90s and early 00s.
Back then JavaScript was to be used solely for non-critical, nice-to-have optional functionality that would regardless not inhibit the user; using JavaScript was contingent on your website gracefully falling back to a perfectly usable state in its absense. If your page failed to load without JavaScript, you were doing it wrong. If your JavaScript hassled your users, you were doing it wrong.
I lament that that philosophy got thrown out the window some time in the early 2010s, which subsequently led to the hellscape of websites filled to its armpits with JavaShit that serve no good purpose which we see today.
That’s a bit of a rosy take of the web of the 90’s-00’s. Plenty of sites failed to render without JS, they just had a noscript tag that said “this site requires JavaScript”. Graceful degradation was ideal but often too much for sites that either weren’t small enough or who didn’t have the resources to implement it. If you were adding JS to a preexisting site, it was easier to do, but on a fresh build or redesign, timelines often meant some things just wouldn’t work but hopefully you could still navigate pages.
With the rise of mobile browsers, the ability for frameworks to solve cross-browser comparability, and the general acceptance that anything beyond trivial interaction required JS, catering to a tiny crowd that didn’t like having it turned on became very unimportant to most. I do agree that graceful degradation to a state that’s still functional is ideal and something I wish had stuck around.
You shouldn't be running random executables period. At one time people still had the common sense not to run code they wasn't vetted and that they trusted.
Your definition of common sense is not really common. Flash, for example, was one of the very early use cases of an ActiveX control. This unsafe technology was supported by Internet Explorer until the end. The IE11 engine is still an installable part of Windows 11. Netscape Navigator plug-ins also were binary code modules. NPAPI was supported by Google Chrome until 2015.
There were warnings from the beginning (both with ActiveX and NPAPI), but for most engineers, getting things done took precedence over trust issues. Youtube, for example, would not have been possible until much later without Flash.
In Windows-land and seldom elsewhere, it was more like "don't run random executables and don't open attachments and ask a sysadmin about the site/flash page/applet you're about to visit". I dare you to ask your grandma what is a .vbs file, without googling...
It was not really common sense. Most people ran all sorts of random codes. If they didn’t, it was because they didn’t know how to get online to find all the good viruses.
But, it was easier to avoid this common error before every site depended on it.
We no longer live in the era where the only people who use hardware that runs executables are philosopher kings with the capability of vetting them by looking at the code.
Probably it's the generic HN snark in revolt against the modern365 world, but the http/html/js kludge has been so effective and malleable that killed a lot of thriving cyberspaces (and for some it killed dialogue and public opinion entirely). But i'm sure the human race will outlive the web 2/3/4 circus.
OTOH, your's is the stereotypical response from an HNer blindly pushing for developer convenience without considering the benefits and drastic power shift away from the user getting just static document data sent vs yet another VM environment to do what desktop apps are already doing, badly ;)
There was a time when there were options and they died out because they weren’t as popular. VBScript and JScript to name a couple. Java is still around but I haven’t seen an applet in probably over a decade. Flash was a thing.
Never forget that the killshot to the back of Flash's head wasn't the technology itself being bad, but Apple's total refusal to support it on iPhones. Now the only thing keeping an entire generation worth of games alive is the Flashpoint Archive.
As much as I miss Newgrounds and grew up with Flash games, and used Flash for lots of art projects, it needed to go. The list of high score CVEs for Flash is 74 with a CVE score of 9 or higher. A decent number were exploits that made use of being able to execute code.
I don’t blame Apple for that decision, honestly. And I’m sure security wasn’t apple’s only reason of course, I’m not going to be naive about that. All around, we may be better off without it. It will also be missed - both can be true.
