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.
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.
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.
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).
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.
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.
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
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.
Anybody remember gmail invites?
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 [email protected] were it not for the 6 letter minimum, so ended up with [email protected] which still yields an absurd amount of messages meant to a variety of other recipients...
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.
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.
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 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.
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.
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.
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.
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).
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
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.
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.