These quotes don't sound right. I was working for an ISP around 1995ish and telling people how to set up Trumpet WinSock and MacTCP and Internet Explorer. Java wasn't even public yet, was it? Someone wanted an interactive web page, so I used Perl and CGI.
"JavaScript is a great way to get cross-platform scriptable access to databases and move the resulting data into Macromedia Shockwave, where it can be rendered, animated and made into live interactive multimedia for the Internet."
Live interactive multimedia? At 3.6KB/s? I remember a T1 (24 simultaneous calls) being a big deal, now my phone seems to have about 40 times the bandwidth.
A lot of familiar stuff came out around that general time, but it didn't spring forth fully formed. Someone was creating what would become eBay at the time too, but that doesn't mean it was a thing yet.
Maybe these are all genuine quotes, but they feel like they are from someone who thinks of 1995, 1998, 2002, etc. as all being "a long time ago".
But your question is equivalent to “what Nation could be the next United States”.
Possible serious answers to your question... which language might be on every device in 10 years... some successor to Solidity might Trojan horse it’s way in. If Facebook built a, like, a “Facebook Platform” or something like that, that could be on every device. Other than that, it’s hard to imagine.
JavaScript came from an era of global platforms. That’s over, now we’re in the era of fractured platforms. I don’t think we’ll see another global platform in a long time. It would need a major new selling point (like Solidity has) that can’t be replicated on existing platforms.
I guess my 2 wild guesses for the long-term future might be either or both 1) a visual/block programming tool (which perhaps might perhaps be more usable in virtual reality type environments) or 2) natural language programming (programming in English and/or other natural languages), which might be more usable in both virtual reality and chat environments.
Go, maybe? Or is it not flawed enough and not criticized enough? Or is it already used too heavily?
Because the way I remember it, technical people hated it with a passion, from its design to its implementation.
In fact, the most popular JS projects have always been to avoid writing ES5, its DOM API, or depending of one of its implementation:
- scriptaculous: we hate even the basic types, so we monkey patch our own code into it.
- jquery: don't use any of the language paradigms and use ones from Lisp and Haskell. Avoid "this". Don't touch the DOM. In fact, don't code, just make a few calls and pass parameters. And we rewrite the whole damn browser API to avoid incompatibilities.
- GWT: write JS from Java.
- underscore and co: let's rewrite typeof, the equality sign and array manipulation methods. And provide an stdib for god sake.
- coffeescript: we like Python and ruby but must do JS.
- React: HTML in JS now please. And magic DOM. Oh, and prototyping is horrible, lets use classes. And we strongly advice immutability, but do what you please...
- webpack and babel: ES6 and 7 are not here yet, but ES5 is so bad we will setup an entire ecosystem dedicated to make believe they are. Also pretend import works like in other languages.
- typescript: ok, we were wrong, ES7 is not enough. Not nearly enough. Please make intellisense works.
Now, in 2020, JS is finally not so horrible to work with. You can use map(), () => and "..." and fake namespaces. Which is amazing to access the crazy cool plateforms that the modern browsers and the web are.
So I guess, in a way, this quote from the AOL guy was true.
https://news.ycombinator.com/item?id=22391509
> I still have people argue with me that the DOM is slow even though all the evidence and browser vendors claim updates to the DOM is simply switching a bit in memory. In other words many web developers have utterly no idea how their platform works.
I guess not much has changed in 25 years. Most developers still fear the language, have no idea how it works, and will do everything in their power to pretend this language is some other language.
> ever tried to make your own UI framework from scratch only using low level GUI calls? z-index, styling with CSS, screen-reader support, etc.
JS oftentimes reminds of Apple: there's the industry standard or some already well stablished way of doing things, and they go like "Well, flip it. We're doing our own way, just because".
$("foo").stuff().bar().res()
And for Lisp, jquery provided error handlers instead of relying on native try/except.
Of course, it's more inspired from it than the real thing, but it's far from any JS paradigm of the time. Remember that JS didn't even have map() and the only place you used your first class functions was to setInterval. Plus the joke is funnier that way :)
They just peeked over at their low level programming neighbours and realized what they did to avoid programming assembly and program C instead was a smart idea.
It's easy to forget, but for years after its introduction JavaScript didn't work well. It was extremely slow, limiting the complexity of what could be built with it. There were problems galore with cross-browser compatibility of what was written. There was no reliable vector graphics or canvas system, so you really couldn't do much graphically. The DOM interface was hard to understand to be charitable. It didn't run outside of the browser, so how dare you call yourself a developer if you were using it?
To the extent that developers knew JavaScript existed at all, it was not considered a programming language.
These things started to change in the early 2000. So deeply ingrained with the disgust for JavaScript, that it took a very long time for the consensus to emerge that you could actually build very complex software on a post-V8 runtime.
The promise of the web was cross platform applications that required no installation. Microsoft's fear was that cross platform applications would make the operating system irrelevant and reduce Windows lock-in. Both Sun (with Java) and Netscape wanted Microsoft's worst fears to happen.
This was the era of Embrace-Extend-Extinguish. So Microsoft embraced the web and added a variety of extensions that only worked on Internet Explorer and Windows. The browser wars followed, which Microsoft resoundingly won.
Along the way, Microsoft demonstrated the power of their browser by doing everything that they could to encourage people to write web applications that would only run on Internet Explorer. Which, of course, only ran on Windows. One of the things that they did was write web versions of Microsoft applications using various Microsoft extensions.
One of those applications was Microsoft Outlook. Which needed to poll the server and find out if there was new mail. For that purpose they wrote the first version of the XmlHttpRequest object. This was in 1999 and they thought nothing more of it...until gmail and then Google Maps came out in 2004 and demonstrated what could be done with it.
The next thing you know, everyone is talking AJAX. Mozilla makes the web accessible to the world. And then Google decided to throw serious energy into a better JavaScript runtime (aka V8) because they wanted to be able to write more sophisticated applications.
And the result is that Microsoft's nightmare has now been realized. But none of it could have happened without that fateful decision to supply the missing piece for a ton of applications of having an asynchronous way to go back for more data without loading another web page.
In 1999 I worked on a contract for Levi's in SF and clearly remember using JavaScript to pull data from a huge hierarchy of product styles and presenting it to the end user as a widget where they could add/remove/move entries around. I remember abusing the cookies API to save the latest client state between page refreshes as it was the only real way to do that at the time. Something like this would have been a total pain in the ass without logic in the browser. In fact, I may have been replacing some sort of Java Applet or ActiveX widget which did something similar in a slower, less flexible way.
So whether it was a huge success outside of corporations or not, I was using it to make a living pretty much from day one.
Early JavaScript sucked bad. It sucked small planets.
As PG said 2005 about Web 2.0. http://www.paulgraham.com/web20.html
>Basically, what "Ajax" means is "Javascript now works."
PHP is a good example of Worse is Better, because it won over the competition, despite its flaws.
HTML vs xHTML as well. Bash, maybe?
But JS didn't win. It was the only one there.
In actual fact, most people try to avoid JS whenever possible, instead using TS or other languages that compile down to JS.
Saying people love JavaScript because it’s the most popular is like saying people love McDonald’s because it sells the most burgers
[*] since we don’t have Java applets or Flash apps anymore. Writing in other languages still means transpiling to JS in the end
I decided I was going to have none of that amateur stuff or reliance on what is now referred to as “browser chrome” (though if the term even existed back then, I surely wasn’t aware of it).
So I looked into this JavaScript thing, and wrote my first ever script embedded into a button:
onclick=“javascript.history.go(-1)”
I was so proud of myself. For about a year users of my school’s website were visibly amazed.
We should not forget Macromedia Flash, it was a very interesting option offering a better programming language but it was not an standard with an open source reference.
Actionscript 2: basically Javascript, when I was writing stuff in AS2 my O'Riley pocket JS guide saw a lot more use than the pocket AS guide.
Actionscript 3: completely ECMAScript4, Macromedia/Adobe was on the standards board for that, but then Mozilla went a different way, I think, it is a giant mess [1]. Also AS3 was a lot more verbose than AS2 which did not endear it to the people with one foot in art and one in programming that was a large part of Flash's user base.
"JavaScript allows Internet applications to easily connect to production databases such as CA-OpenIngres"
"We plan to integrate our automatic document indexing and abstracting technology to leverage the power and functionality of JavaScript. "
"Illustra’s unique extensible Object-Relational architecture makes it an ideal intelligent queryable store for content management applications using Java and JavaScript objects"
"JavaScript is a great way to get cross-platform scriptable access to databases and move the resulting data into Macromedia Shockwave"
"The creation of a general, standard scripting language for Java development will accelerate adoption of this new, exciting technology for delivering dynamic, live content to the consumer."
You could replace "JavaScript" with "Machine Learning" or "Blockchain" in the above quotes, and they would make just as much sense.
Metroworks built dev tooling and IDE's the where big on Mac's back in the day and they where awesome for their time.
Another fun fact is that they had a huge accounting scandal around the dotcom crash involving a 35 day month! They ended up settling for around 300kk USD.
Edit: They settled for 225kk USD. Sanjay got 12 years in prison and an 8kk USD fine.
- (hopefully redundant) client-side validation - some styling (CSS was also brand new) - basic animation (eg: changing the on-hover appearance of stuff) - form "tweaking" (eg: disabling/hiding parts of a form dynamically based on other field values).
It wasn't really for writing apps in, just for adding small enhancements to apps that did their real work server-side.
In all seriousness, everyone was in on Java. Even Microsoft (Everyone was in on Java, even Microsoft (https://en.wikipedia.org/wiki/Visual_J%2B%2B). So most of us saw browser plugins and applets as the future, and some of those plug-ins were very impressive in those days.
JavaScript was seen as a glue language to manipulate components built in better languages. We thought there was going to be a rich component marketplace that was going to be embedded in web pages. We didn't think we'd still be mucking around with HTML and DOM manipulations.
It's not that JavaScript solved that, it's that it's built into the browser such that you can't really skip it. Like the Java and Flash engine, a web browser is also a fat bloated leaky client. However, if you toss the first two, you are then dealing with 1 fat client instead of 3 fat clients. It's easier to keep 1 FC up to date than 3.
According to CEOs and other businessmen making statements for the press hype machine.
https://slashdot.org/story/01/10/23/1816257/apple-releases-i...
Have an upvote.
I was not impressed. On the client side I would use it for very few things and when I tried the server side version I decided that I would rather stick with Perl and CGI. Although I did not like Perl, I could get things done with it. (Oh, I just remember: also Cold Fusion!)
My opinion of Javascript has not improved over the years. I worked with Javascript for a while and in complex enough problems that my name ended up on 2-3 patents and patent applications. I no longer work on the web, but I have occasional need for Javascript and I always hate my time with it.
This will be an unpopular opinion, but frankly I am perplexed by its popularity, because it is neither simple nor elegant.
As Encyclopedia Brittanica (!! who'd have thought) puts it,
JavaScript was developed in 1995 at Netscape Communications Corp. and was conceived of as a companion to Java. It was originally called Mocha and then LiveScript before Netscape received a marketing license from Sun.[0]
And then it became 'a dialect of ECMAScript'...
If you're going to do in browser development, what choice so you have? I can understand server-side JavaScript, mostly to avoid cognitive load from learning two languages.
Otherwise, I think WebAssembly is a lot more promising of a technology.
I mean the quality he did put into it argues for he thought it was really cool, but perhaps he is so much of a craftsman he wouldn't put in less effort on something he considered to be a bad idea (unfortunately not many people have this admirable quality
This article brings me back to a time when every product had a bunch of these "empty suit" quotes about it. The person never said that stuff, it was all written for them. I remember being on a project where marketing fluff was "said" by someone who had no idea what was going on and, besides, the product wasn't doing anything, let alone what he claimed the technology enabled it to do.
Still true, but ironic to hear a huge telco monopoly say it.
What does that language offer that JS can’t match, and what trade offs does it make to get there? I suppose you’d have to write a hypothetical spec for dom APIs, etc that don’t exist in the target language, and then pretend to use it and see what the pain points/unexpected pleasures are.
Most of the memes are faux retro. The fiji water bottle is representative of the vaporwave aesthetic from 2016 or so. The font animation is also super modern, circa early 2010s. It's all fake.
They should have pulled more stuff from Geocities archive. This is not how things were.
My favorite early js story is writing a “life cycle of stars” app in 4 hours in 1997 and getting a full high school semester worth of credit for it :-)
After Gmail...things really started to move in the javascript world...people started to put effort into both the runtimes and the libraries.
Updates were often committed live using remote scripting (A precursor to AJAX) and we did a lot of DOM manipulation to update content in-place. At that time, we targeted IE because Netscape's support for DOM manipulation was abysmal.
While I have to give Gmail credit where it's due, I have to give Firefox the real credit for doing the hard work and finally releasing an alternative to IE that kicked JavaScript into high gear. If Gmail had never happened, it would have only been a matter of time before SPAs were going to become a thing. There were more of us doing it before Gmail than most people realize.
https://en.wikipedia.org/wiki/Oddpost
It also felt more like an app than gmail ever has given it had the "standard" 3 panel look of most desktop email apps (same as most of them do today like Thunderbird/Outlook/Apple's Mail)
And before that Outlook had a browser version that acted like a SPA since 1997.
https://en.wikipedia.org/wiki/Outlook_on_the_web
In fact I'm pretty sure that's why Microsoft introduced XMLHttpRequest
I think the v8-runtime changed a lot for Javascript, although it was already normal to use then
Maybe users like native applications because native app programming sucks and it weeds out people who carelessly build things like that.
I don't know what you were doing in 1995 and 1996, but I was building Javascript apps. They were "a thing" for me at least.
And nearly impossible to debug on top of that. Firebug didn't come around until 2005, and AFAIK that was the first interactive debugger for Javascript. In fact, I remember spending a lot of time debugging without even console.log() support - window.alert() was the only weapon you had for the longest time. Not to mention every Javascript implementation's frustrating habit of just throwing up a blank page instead of an error message if anything was wrong...
I wonder how history would have looked like if Scheme had been used instead, as was the original intention.
Or perhaps, Lua.
However, I don't think the limitation was the language. The biggest limitation really were bug ridden browsers. Trying to get something to work across all browsers was incredibly challenging because so many basic features simply didn't work.
Had the syntax been based on scheme, my guess is scheme's reputation would have suffered. I think people have a tendency to blame the thing that they understand the least, so I could see people blaming scheme for the browser's failings.
Also, I went to a university that taught SICP and I'm sorry to say it wasn't popular. Again, when things didn't work, there was a tendency to blame the thing that was least understood.
I could see a Lua-like syntax being approachable, but even that wouldn't have helped. Again, the biggest problem with JavaScript was being tethered to buggy browsers that often failed when you asked them to do simple things.
But I like the idea of angle brackets for content and parentheses for script.
1. Introduce a "chaining" API.
2. Paper over the differences between how browsers implemented the DOM, with events being the big issue.
Note that the DOM is not JavaScript and JavaScript is not the DOM. The DOM is a language-agnostic API for manipulating markup-based documents.
The solution (for CRUD makers) is to make common desktop GUI idioms part of a standard instead of emulate them all. This includes but is not limited to: MDI windowing (as an option), modal panels, drop-down menus, tabs, combo boxes, editable column-expandable data grids, expandable trees, tool bars, and a decent multi-select widget instead of using (just) the Ctrl key. HTML frames were helpful, but have since been deprecated. Somebody found them too useful? Mobile land is too different from desktop land. Forcing a lowest common denominator is bad for business IT productivity.
That's not exactly accurate, you could actually do some server-side things with it and I knew people who did it (late 90s, early 00s) - although I never understood why and the company went bankrupt in the end.
I haven't forgotten, and I will never forget.
JavaScript was hard.
I remember writing complex graphic applications in Director. But I think it took at least 10 years before the same was possible in JavaScript.
Prior to that, it was really just form validation and cool DHTML interactions.
I also wonder why AJAX is not called AJAJ?
Who do you imagine is going to find this advice compelling?
And STILL doesn't, at least for anything non-trivial. New browser brands or version often "break" a lot of libraries and code. It's not really JS's fault: HTML wasn't meant to be emulate real desktops, and shoehorning it to do so has made a giant tangled multi-layer mess.
Browser standards should be split into three focus areas:
1. DOC: Document-oriented for text display and editing. It would be similar to existing browser but with more word-processing-like features. [I removed "read only"]
2. GUI: Mouse-centric stateful GUI markup for data-oriented "productivity" CRUD applications.
3. ART: charts, games, music, and movies.
The one-size-fits-all "standard" mostly failed (job security aside), time to split and focus. Let's admit we f!!! up as an industry.
When has it happened that browsers have broken standardized features? Browsers have gone through large lengths to stay backwards compatible. It's hard for me to think of things that have been broken besides nonstandardized stuff (like plugins, or things that only worked in one browser to begin with like IE).
IE ran on Mac but, in a super-fun fashion, wasn't exactly the same IE, IIRC.
There was a period, pre-Camino (Mozilla fork before Firebird/Firefox for Mac got good), pre-Safari, where IE was the single best browser for Macs, yet still wasn't as good as IE on PC...
The old MS/Apple relationship is kind of weird almost like the Gates/Jobs relationship. For you young folks it may be hard to believe but Excel started as a Mac App.
XmlHttpRequest + JSON formalized this type of data transfer.
That made it appropriate for intranet applications, but not the internet.
The majority of webpages did not use it, or it was used very sparingly for things like form validation.
Old versions of IE would have a dialog pop up if there was any kind of error during execution which happened frequently.
I don't know exactly when the tides turned on this attitude. In 2000 the above were not controversial opinions. By 2010 it was gone, and I saw people call it crazy talk, but it probably happened earlier than that. Probably things like gmail in 2004 were a turning point.
document.writeln("Hello world!");
To me as a regular user, JavaScript was only there to do annoying popups at the start.
Funny how some things never change...
More exciting was things like Java applets or Flash. I did a bunch of stuff with Java applets and was quite impressed in 95-96 when java first came out. I wrote some simple 2d games (falling block puzzle games) which got semi popular. No way to do that in the js world at the time.
Eh... if this was actually true, the web would look very different. I just can't square "web programmers hate Javascript" with "web programmers are obsessed with SPAs/CSS-in-JS/NodeJS backends/etc..."
> Writing in other languages still means transpiling to JS in the end
I'm assuming you already know about WASM, but if you don't, the future is starting to look relatively optimistic for other languages on the web. Still some problems to solve, but C++/Rust already have pretty promising toolchains working today.
But for me, JavaScript is not about having your dinner made just how you like it. It’s about targeting the lowest common denominator and keeping your code simple because of that.
I think that’s where JavaScript is headed in the limit. We’re at the low point for “just put a file in the browser, it’ll work!” But I guarantee you that style will come back in the next wave. You already see people going that way today. Casting off Babel and using much simpler packaging tools with code that’s natively readable in the most common browsers.
Would you package Rust for the JVM? Maybe. But it would not be fun.
Ok I give up, why is this wrong?
And of course next to JS, you have C#, Asp.Net, Ruby, Python, and Go.
I'd say that given that:
- a lot of people only know JS (like designers)
- JS has a monopoly on the front end and is the only language that can be used on the front and back
- JS has existed for as long as Java (C#, Ruby and Go are way younger)
- there are JS materials everywhere given the web popularity
- the web is the most popular plateform in the world
The fact, as a freelancer going from company to company, I see so little JS on the server compared to other languages tells a lot.
I’m sure it gets a lot of hate just because of its dominance.
The alternative all depended on non technical users with slow connections to install the runtime.
Js code was guaranteed to work anywhere, and with no requirements, giving it practical monopoly.
There will always be some overlap, but that doesn't entirely diminish the value of focus. It may be possible for a given window or panel to select which focus-standard it uses to make mix-and-match a bit easier.
A given "starting" browser, typically the document-oriented one which will contain menus and lists (such as an intranet) could be configured to select the user's or org's desired GUI and Art engine. And each "engine" will contain a minimal common sub-set, mostly around existing HTML.
If they were done in javascript, the code was heavily cargo-culted and cut and paste.
Conversely, Apple benefits the most from native apps, because their development stack is so different from everything else, and yet they are big enough in mobile that everybody has to target them anyway.
And just because "web" more or less works doesn't mean we should stop trying. Web UI's for typical CRUD are expensive to build and maintain compared to 90's IDE's. Yes, I realize it made deployment simpler, but programming has at least doubled for the same feature set at the average shop. (There are exceptions, I know, I'm talking average.)
If somebody can justify "it must be that way", I'd like to see the logic. I'm highly skeptical. We just accepted our CRUD Rut as an industry because it's good job security, not because it's efficient. That's somebody else's bill. A good GUI-over-HTTP standard would make a boatload of dev problems float away. I really miss state, for one; it was a good thing. Oh Darling State, I surely miss thee, wherefore art thou? Jetsons tech was yanketh from my finger, and replaceth with Flintstone fiddle diddleth.
(And why are my posts getting bad scores? I don't get it. Ask first, and then neg.)
- Perl5
- Python
- VT220/VT100 terminals + ncurses
The same applies with other languages too (e.g. Perl, Ruby, etc).
What I mean by slow is for example adding a element to the screen, or updating some text. Compared to for example everything that happens on the screen in a 3d game.
I do everything using vanilla JS and I cannot understand why anyone would use a web framework, (although most web project does). I do however have a vague memory that the learning curve was fairly steep, as I have been working with vanilla JS for over 20 years. (whereas the average developer has only used JS for one year) it wasn't until I started to use JS full stack (with Node.JS) that I started to like it!
No construct or design decision of JS is better than in other languages, the lack of a basic standard library hurts a lot. Dependency management was inexistent until recently, the same for a lot of basic constructs, data types and other utilities that should be baked into any modern language.
The current landscape of JS is so convoluted and with such a varying level of quality that is intractable for me just trying to get things done without getting into the community and everything around it, it's not an easy tool to use and it's not an ergonomical one.
I have used JS for the past 15+ years for different kinds of software and I dislike it, not intensely but I'd never choose to work solely on JS. Yes, you can be productive in it but there are much better tools for most of the job it does around, its only power was to be the only language you could use to script a browser and I hope that WASM kills that.
In order to improve as a programmer over the years I have had to learn to improve my writing. This requires a clear vision before putting keys on a keyboard and a solid sense of organization. You should know what you are going to work on with a strong confidence on how to go about it before doing any of the actual work. Sure rough spots will emerge along the way, but that shouldn't stop you from solving for the original vision. Then once the original vision is achieve refactor, debug, and refactor again. In writing that is call drafts and second opinions. This applies to any programming language equally.
A confidence of data structures is also critically important. Once skills and conceptual mental modeling of data structures becomes as common as spelling your name algorithms and logic almost write themselves. JavaScript does some things right by providing simplified data structures (objects, arrays, sets, maps, and such) and is really expressive in how you use them. JavaScript also does a lot wrong in this regard with its loose typing and some of its sloppy conventions. Fortunately, TypeScript interfaces coupled with consistent use of strict type declarations close many of those gaps.
---
I have heard so much hope for WASM killing JavaScript over the last 3 years, and almost all of it based on ignorance of how the technologies work. So much of this hope hinges on the availability of the page's DOM to a WASM instance by people who have never written to the DOM and have no idea what they are really asking for. While the WASM working group says this will never happen I suspect that very simple technology reasons will get in the way first regardless of what anybody wants.
If, however, WASM does replace JavaScript because the page's DOM becomes available to a WASM instance I suspect it will be the same clusterfuck that those developers were hoping to replace. I suspect if those developers couldn't figure out the relationship-oriented tree structure of the DOM using JavaScript they fail all the same when using their favorite language.
I can understand replacing JavaScript for other reasons, but rarely (extremely rarely) are the well grounded reasons ever a primary motivation for wanting JavaScript replaced.
Microsoft also exposed all of that HTML/JS engine as COM or whatever component, so it could be used by applications other than browser.
I remember using Microsoft Money -- personal accounting software -- and it seemed to be all built on that HTML/JS engine.
By investing in cross-platform IE and making it both the best browser and the universal runtime for desktop-quality apps, they could have had “Windows Everywhere”.
Instead they did the exact opposite and folded IE into a component of desktop Windows where it received no meaningful investment and lost its once commanding lead. Microsoft’s exclusive focus on their proprietary non-portable APIs was a great blunder.
There's a reason it has zero traction beyond embedded application and niche application like Pico8.
But when it works in its true intended domain, gluing together and applying configuration to structured APIs and data, it's about as good as it gets, having had the benefit of major revision. And that makes it a stable computing platform, even more stable than the Lisp family(which are like BASIC in that it's quite easy to make an incompatible one). As a side effect, that also makes it an excellent source-to-source target.
But to put it another way: Everyone says they like minimalism until they try to live in it. Everyone who needs minimalism knows its limitations and makes exceptions.
But as far as the language itself goes, Lua is far superior, with a lot more consistency all around, and fewer traps.
I still feel like this.
GWT was essentially what typescript is today but java and it handled most of the nasty DOM related stuff and browser incompatibilities.
I suspect performance and inconsistent experience killed Java applets and Sun stopped caring about desktop Java when they realized they can't make much money off it. Flash stuck around a lot longer than Java because it was fast, fun and ran consistently. It still lingered for some time after Jobs poisoned it.
Honestly, I don't think people cared that much about running updates. For most people, if the computer tells them they need to update, they update. I also don't think average users cared about security issues back then.
Recommendations in common publications to remove them unless absolutely necessary coincided with their market share slide, as I remember it.
Yes, Java applets was imperfect, but generally got better on every release. It was improving about as fast as JavaScript + DOM + CSS + HTML was.
Re: For most people, if the computer tells them they need to update, they update.
It didn't help them in that they tried to trick you into installing extra junk apps during the update process, like tool bars (AKA spam bars) and "free" anti-virus scanners.
Java had a big issue with applications that needed older versions, but the older versions often had security holes. Oracle didn't manage backward compatibility well. Trying to be a virtual OS instead of just an app platform contributed to the too-much-complexity-to-manage problem for Oracle. KISS.
http://www.herongyang.com/VBScript/IE-Browser-DOM-API-Docume...
Also you can use XSLT to create a new DOM tree in a browser from an XML document.
http://www.informit.com/articles/article.aspx?p=24032&seqNum...
EDIT: I forgot about JScript vs JavaScript vs ECMAScript.
https://johnresig.com/blog/versions-of-javascript/
However much of this isn't relevant today.
That was a fun, well-paid project with lots of (non-exempt) overtime. Then the .com bubble popped.
That's what Java applets and plugins were for.
I'm also pretty sure they weren't the first to fetch data from the server without reloading, because people were doing all sorts of novel things in the mid-90s with plugins.
The reason it didn't really take off back then wasn't because of vision. It was because there was so little you could do with JavaScript. The browsers were still implementing the basic features and a lot of page/component manipulation was very broken. Applets and plug-ins were so much more capable.
Then along came Javascript with its transparent attempt to ride the coattails of Java by adopting a similar name. No interest in that either.
And they are still doing it. CSS Grid is not even 3 years old.
Except that they couldn’t alter the DOM, or handle events on DOM elements, the two things that developers really needed (even if they didn’t know it).
But IMO it makes it all the more surprising that Microsoft doubled down on the centralized OS+API+apps leverage combo that had brought upon them the antitrust scrutiny, instead of dispersing their influence?
I dunno, there are some pretty egregious examples of this being false though. gmail is one such example. I remember using webmail in the days where every action was a full page load -- and we had slower connections then too, which made it hurt even more. Then gmail came out and blew everybody away with its response times. A well thought out AJAX solution could give you minimal load times for data. The issue lately is when the JS code is too big, not well tuned, and gives the equivalent of several 90s-era-website-full-pageloads worth of data with every action. That is to say a lot of websites aren't as lean as they could be.
I'm not a web focused person so somebody correct me if I'm wrong, this is my outsider's perspective.
When DHTML was introduced in '97-'98, the only major browser that had a reliable DOM was IE until Firefox came around in 2002. Netscape tried, but it was buggy to the point where there were no real workarounds to the huge gaps in missing functionality.
As far as 1995 was concerned, applets and plugins looked like the future. Honestly, the web was so new and so inferior to other things in 1995 (Macromedia, WYSIWYG tools, etc.), I think most of us saw HTML being replaced in a few years by a richer clients, applets or plugins.
The use of method chaining in jQuery is cool, but it is not very similar to Haskell.
That's what the jQuery API does behind the scene of the chained calls. That's one of the key reasons of its success actually.
$(".foo").foo().bar() will execute n times, for each of the n DOM elements you matched with ".foo", including one or zero.
Yes this is a cool and useful pattern, but it is not bind. It is just a different thing.
setInterval('console.log(1 + 1)', 1000);
Stealing this for my next JS training, beginners always have a hard time with callbacks, so it's a good first step to actually explain the benefits of callbacks.
When I was learning callbacks I saw people use the "setInterval" example and while it did help to an extent, the real world implementation still left a good deal to be desired.
Also, Java applets and JavaScript were added to Netscape 2.0 at the same time and were meant to complement each other, not compete. It may seem like Java came first because JavaScript was called LiveScript for the first three months. I also don't think the JavaScript name change was intended to ride the coattails of Java, rather it was clarify and harmonize its relationship to Java.
I still look back and I'm amazed at how much stuff happened between the summer of '95 and winter '96. Windows 95 release. Netscape went public. 2.0 released 1 month later introducing Java and JavaScript, etc. etc. etc.
I think the point I'm really trying to make is that the Netscape team had a much richer vision of the web than what we use today. Before they built Netscape, Andreessen and Clark were considering building an online gaming platform. I'm sure you remember how big multimedia was back then.
If you look at the timeline, you can see where the were going. They started off with a focus on dominating the browser market, which they did in 4 months. In less than a year after their first release, they released the first version of an online platform. It added Java, JavaScript, and a plug-in architecture with standard plug-ins like Live3D so you could embed VRML into your HTML page. No one was even sure HTML wasn't going to be replaced by something better, so I have to imagine they were hedging their bets by adding three different ways to build on their platform.
If anything, I think your original comment reinforces that strategy. They knew there were a lot of C++ developers who wouldn't take to Java for whatever reason, so they offered a plug-in architecture for people who cared more about performance and experience than being cross-platform.
Had things gone differently (Microsoft not woken up), I can easily see Netscape creating a dominant internet platform that went beyond HTTP and viewing hyperlinked documents. They were already bundling email, website editors, conferencing, news clients, etc.
Plugins and applets filled a huge gap functionality wise.
I don't say that to crap on Netscape. Microsoft was a well-funded company with a lot of experts who had years of experience create applications with DOMs. Also, they had the luxury of delivering a browser for one operation system.
Netscape was a brand new company that went public 7 months after it's first release and 1.5 years after its founding. They sold investors the premise they were going to become the Microsoft of the internet. They had a fraction of the resources while they were trying to creating browsers, email clients, collaboration software, web server, and a host of other software for multiple platforms.
The apps you mentioned had nowhere near the impact that Gmail had in terms of showing what was possible
Most email providers had approximately 100Mb mailbox limit (I can't remember specifically), but Gmail had 1Gb.
The biggest drawback at the time was that it was window/IE only, and when gmail was released, google made an effort to be cross-platform.
IMO, Google's 'big win' wasn't so much showing what JS could do, but that complex JS could be done cross-browser and cross-platform.
I then realised that I could invite a second account, so I created a handful of accounts and still own them today.
Good times.
I probably could have picked firstname@gmail.com were it not for the 6 letter minimum, so ended up with firstlast@gmail.com which still yields an absurd amount of messages meant to a variety of other recipients...
Once they do, you show the problems with it and show why callbacks are better.
When it comes to pedagogy, I'll use every trick I can.
And I always win.
If your way works, then it works though I suppose.