21 ms·

> JavaScript was first released in 1995. Like I mentioned > above, I started writing JS in 2012, almost two decades > later, near the beginning of the era I

> JavaScript was first released in 1995. Like I mentioned > above, I started writing JS in 2012, almost two decades > later, near the beginning of the era I’m dubbing the > First Frameworks. > [...] > This contrasted pretty significantly with mobile apps > when they started to hit the scene. From the get go, > mobile apps on iOS and Android were full applications > written in Serious Languages™ like Objective C and Java. I'm going to make a small jump to conclusions and guess the author is too young to have accurate memories of what web development was like pre-2010. Gmail was released in 2004, Google Maps in 2005, Google Docs in 2006. All of those used JavaScript technologies (GWT and Closure) that enabled web UIs to go head-to-head with native applications of the era. There was an entire generation of JS frameworks (maybe two?) that rose and fell before the release of the iPhone. The primary difference between GWT/Closure and what we've got now is that JavaScript was treated as a compilation target, not a developer platform. The tooling was all in Java or C++, there was no concept of writing a transpiler or bundler in JavaScript and no culture of standalone JS interpreters. IIRC the only option at the time for running JS on the server was Rhino (based on Netscape/Mozilla), which for whatever reason never saw the broad adoption of Node.

azeirah 5y ago
I believe part of the reason Node got popular was because of two reasons 1. V8, which is actually really fast 2. Hype around being _asynchronous_ at the time JS itself started to become more hyped up.
- Klonoar 5y ago
  Asynchronous, and Node being so HTTP-friendly - I cannot begin to explain the sheer number of regurgitated "build a webserver in Node" tutorials that got written up back in the day. For whatever reason, you could have done this stuff in Rhino - for better or for worse - it's just that nobody ever took it as seriously.
  - saurik 5y ago
    Not only could you, but some of us even did (though it definitely was never, as you say, "taken seriously"). What made it super powerful (and very node.js-like) was combining it with Jetty, which was a servlet engine that could be used as a library. My (trivial, personal blog) website is still running with this stack (though I finally put it behind an nginx SSL terminator as I have been putting off upgrading Java and Bouncy Castle just couldn't keep up), and it gives me more warm fuzzies than v8 alternatives. A "people actually used this" framework that had Rhino at its core (well, in one of many ways of using it) was Apache Cocoon (which was maybe more by-default based in XSL/T), only they did something almost ridiculously clever: as Rhino had full support for continuations, they didn't need "callback hell" (or async/await) and could even support pseudo-synchronous code that could block on the user (such as a function which sent the user a form and returned the user's selection, possibly hours later) by storing the continuation state in the user's session.
    - Klonoar 5y ago
      >A "people actually used this" framework that had Rhino at its core (well, in one of many ways of using it) was Apache Cocoon (which was maybe more by-default based in XSL/T), only they did something almost ridiculously clever: as Rhino had full support for continuations, they didn't need "callback hell" (or async/await) and could even support pseudo-synchronous code that could block on the user (such as a function which sent the user a form and returned the user's selection, possibly hours later) by storing the continuation state in the user's session. Wow! I'd only dabbled in Rhino back in the day so this is a neat little bit of history. Teleports me back to when this stuff felt fun...
  - neurostimulant 5y ago
    I think it's due to the huge hype around chrome among developers back then. Each tab as separate process was huge. It also has built-in dev tool, and v8 being actually fast excites a lot of devs and drove them away from firefox. So when nodejs was released, a lot of people already know what v8 is and have positive impression of it, probably enough to nudge them to try nodejs. On the other hand, I never heard of Rhino until now.
- bin_bash 5y ago
  And npm. I don’t think Rhino had a good story for dependency management.
  - emn13 5y ago
    I think you've hit the nail on the head; npm was the real killer app - it makes it very easy to try out node and result in a real, usable app with very little code nor (visible) complexity.
    - moffkalast 5y ago
      npm is what pip could've been if wasn't mismanaged into oblivion.
      - MereInterest 5y ago
        As someone who hasn't used npm beyond toy projects, what major features does it have that pip doesn't have?
        matsemann 5y ago
        Installs in a local folder to the project (node_modules) instead of pip which installs packages to the global python installation unless ran in a virtual env. So getting anything up and running is trivial, compared to the amount of installations and steps needed with pip, unless you wanna bork your global python installation. With npm it's also really easy (almost too easy) to take your current folder and push it to npm, making the ecosystem bloom with packages.
        goodoldneon 5y ago
        The virtual env thing is extra friction but isn’t terrible: $ python -m venv .venv $ source .venv/bin/activate $ pip install -r requirements.txt Most IDEs will automatically pick up the .venv folder
- j45 5y ago
  v8 was huge was fast but the CLI was a big deal too
- brightball 5y ago
  When Node first came out, all of the hype around it was using the same language on the client and the server OR at least managing all of your frontend bits in a language independent of your server side language. At the time, there were JS/CSS/image minifiers in just about every language IIRC. Doing it with Node was a stronger argument to at least save the frontend side of the house from having to find a way to do them with Java or ASP. During that time period, Java compile times were so slow that using PHP as a frontend that spoke to Java backends with SOAP services was really, really common just to avoid slowing everything on the frontend down with Java.
- zokier 5y ago
  For context, the thing preceding nodejs in the hype cycle was ruby on rails. While many great things could be said about RoR, performance definitely is not one of them, especially in the early days.
  - pragmatic 5y ago
    I love having to run a sentinel app that would restart your app on crashes. I forget the details but RoR was a deployment catastrophe.
genezeta 5y ago
> IIRC the only option at the time for running JS on the server was Rhino (based on Netscape/Mozilla), which for whatever reason never saw the broad adoption of Node. There was SSJS on NES/iPlanet/whatever before that. I mean, it existed. It was not really useful and few people even noticed it existed at all, but it did exist.
womansplainer 5y ago
Oddpost was before Gmail and functioned almost exactly like native outlook https://en.wikipedia.org/wiki/Oddpost https://en.wikipedia.org/wiki/Oddpost MS themselves had fairly functional Outlook web interface in 1995 (and was the reason XMLHTTPRequest was introduced
- tomhoward 5y ago
  Oddpost was such an inspiration as to the kind of UX that was possible via the browser.
deleted 5y ago
[deleted]
pzuraq 5y ago
I am, indeed, too young to have accurate memories there! Of course right after I posted this I started hearing about GWT and Closure, that's a bit of egg on my face. I mentioned Gmail as an important marker, everyone I talked to remembered it as the _moment_ which proved that JS could write full applications in the browser, but I assumed that it was written with an internal framework of some sort (none of my mentors who've been in the industry mentioned it when I brought up Gmail, and there's no mention of it on wikipedia: https://en.wikipedia.org/wiki/Gmail https://en.wikipedia.org/wiki/Gmail) That said, I think it's an important landmark and I may end up revising this post to add a bit more discussion about it. Thanks for pointing it out!
- jeremyjh 5y ago
  The buzzword circa 2006 was "Rich Internet Application" framework/platform and the concept was not even totally new then. It included GWT, but also an Adobe product built on Flash called Flex and some other vendor solutions that compiled to Javascript that I no longer recall the names of. The space was well-defined enough that there was a Gartner magic quadrant for it.
  - karmakaze 5y ago
    I had a big interest in RIA at the time. The big players were Adobe AIR, Microsoft Silverlight, Eclipse RCP, Netbeans, and I also considered JavaFX--I might be forgetting another one. Silverlight had the best performance/fit for my purposes and sadly was the first of many to go away, largely due to the popularity of iPhone and these platform/tools being excluded. Too bad Apple only promotes Apple's innovations and actively suppresses others.
- tolmasky 5y ago
  Not to toot our own horn, but I'd look into Cappuccino and 280 Slides too (we were YC no less!) and were the first iteration in the GWT era to extend JS itself and transpile in the browser.
  - no_wizard 5y ago
lucideer 5y ago
GWT wasn't really a javascript framework - granted it was more of a framework than something like emscripten, but from a "developer writing code conforming to a defined framework structure" perspective, there's not a huge amount of javascript involved. Furthermore, there really wasn't very widespread "community" use of GWT (mainly Google, and outside of that, mainly oldcorps working at similar scale to JS-ify old corp codebases), and even Closure was mainly leveraged by the community as glorified early babel / webpack type tooling, rather than a full range of things, e.g. Clojure. All that said, calling React a "framework" is a big stretch, which makes the title questionable while one is reading through the components section, so I guess one could get away with including a few not-framework-ey things. But... overall I don't think the author's age hampers them as much as you make out: when I started programming in JS circa 2002, nothing existing in that ecosystem was really comparable to today's frameworks, so comparing them here would add little.
j45 5y ago
Around 2000 it was possible to write AJAX applications with xmlhttprequest using JavaScript to achieve no refresh apps in the browser. Folks are building with a 20+ year old idea that has continued to evolve, in part because JavaScript is ancient in internet terms but uniquely positioned as one of the only languages (if you could call it that at the time) that was web first, instead of a traditional programming language having to connect to the web via a framework. Ironically, the core feature for web apps in the browser to enable this existed thanks to Microsoft. Brutally simple, efficient and likely part of what gave rise to so many JavaScript frameworks since people generally had to roll their own. I’m sure there might be some here who reverse engineered what Outlook Web Access was doing. “ The concept behind the XMLHttpRequest object was originally created by the developers of Outlook Web Access (by Microsoft) for Microsoft Exchange Server 2000.[4] An interface called IXMLHTTPRequest was developed and implemented into the second version of the MSXML library using this concept.[4][5] The second version of the MSXML library was shipped with Internet Explorer 5.0 in March 1999, allowing access, via ActiveX, to the IXMLHTTPRequest interface using the XMLHTTP wrapper of the MSXML library.[6]” Building an app in the browser was not a popular idea partially because of the instability of high speed internet and the lack of performant mobile internet, and if imaginable, the lack of users on the web at that time. The first major rush of users online was likely Facebook. Still it was possible to build a full ms office UI clone working in the browser, except it was powering your custom app. Sometimes things are gaining popularity for a long time before they suddenly get discovered. This single call was a reason why jquery became so popular. What I enjoyed about this article was how it speaks to an internet generation of tech or users emerging every 2-3 years, something I have long felt. Everyone starts somewhere, everyone is new to learning something and those experiences are worth sharing for new developers who do not quite have their compass in place yet. https://en.m.wikipedia.org/wiki/XMLHttpRequest https://en.m.wikipedia.org/wiki/XMLHttpRequest https://en.m.wikipedia.org/wiki/Ajax_(programming) https://en.m.wikipedia.org/wiki/Ajax_(programming)
- deleted 5y ago
  [deleted]
soapdog 5y ago
I was doing JS with frameworks circa 2006. I remember mooTools, Dojo Toolkit, Prototype, jQuery, and some others that were around before 2010. Unless we have very different meanings for the word framework. I consider Prototype, Dojo Toolkit and mooTools frameworks while I think of jQuery as a library.
- teknopurge 5y ago
  mootools was awesome. I always wondered why it was so fun(for me at least) to use.
- cmrdporcupine 5y ago
  Yep, mochikit was another one that I liked. I worked at a company around 2001 that was doing a full "Ajax" style frontend for a dashboard product for some industrial control systems. But it worked in IE only, as the Ajax pieces were not available on the other browsers yet.
- brightball 5y ago
  Prototype, Dojo and mooTools! Memories. I remember discovering any of these existed after doing an entire AJAX frontend site with raw JS that continued to work cross browser for the next 10 years. Made me full appreciate the value of those frameworks. IIRC JSON wasn't even really a thing yet.
- spookthesunset 5y ago
  I don't even think mooTools and friends were really frameworks as we know them today. They were really just some kind of standard library that let you plug in fancy UX widgets and stuff... I dunno if the distinction really matters though. But I do know they weren't even in the same league of frameworks like angular or react. I guess the difference is these new frameworks are all about letting javascript generate virtually the entire page. MooTools and friends were designed where the majority of the page was old-fashioned HTML being spat out by the backend.
- afavour 5y ago
  To my mind MooTools and jQuery were roughly equivalent in functionality. Am I misremembering?
thrower123 5y ago
It's not clear that writing tooling in Javascript has been a win. I do hope that we can get back to that "JS as compilation target" model eventually with WebAssembly. Even with improvements like TypeScript slathered on top, it's not fun writing Javascript, the tooling sucks, and it's vastly less productive than better developer ecosystems.
teh_klev 5y ago
> IIRC the only option at the time for running JS on the server was Rhino Not really true[0]. You could run server side JavaScript with JScript[1] on IIS as far back as the days of IIS 3.0, circa 1997. JScript is ostensibly JavaScript and tracked the original Netscape releases and then the ECMA standards. [0]: depending on your love/hate with Microsoft at that time :) [1]: https://en.wikipedia.org/wiki/JScript https://en.wikipedia.org/wiki/JScript
caseyf 5y ago
> Gmail was released in 2004, Google Maps in 2005, Google Docs in 2006 Lots of dynamic (and complex) web-based CRMs were competing with each other in 2000. At my job, we were doing what is called "HTML over the wire" today by posting forms and using a frame as the target.
- _fat_santa 5y ago
  With frameworks like Remix now I feel like were going full circle back to "HTML over the wire"
  - deleted 5y ago
    [deleted]
bitwize 5y ago
Netscape Web Server supported server-side JavaScript since the mid 90s. Rhino was a development intended to provide JavaScript support to Netscape's all-Java browser ("Javagator"), because at the time Java was clearly The Future and we would all be running it on our desktops.
- tyingq 5y ago
  One of the funnier things about Netscape's server-side JS "LiveWire"... LiveWire's unpopularity and subsequent death was often attributed to its need for compiling and bundling steps, which seemed cumbersome to the JS devs at the time.
- pram 5y ago
  This just reminded me of Sun HotJava, which was genuinely one of the worst pieces of software I have ever experienced.
cmrdporcupine 5y ago
AFAIK none of the Google products you mentioned used GWT. In fact when I got to Google in late 2011, I believe the only thing I could confirm using GWT seriously was some display ads admin tools. GWT was awful. And not really used inside Google much.
- sa46 5y ago
  GWT was replaced by the similar J2CL and is used for GMail, Inbox, Docs, Slides and Calendar.
  - cmrdporcupine 5y ago
    I wasn't on the gmail team but my understanding from friends that were is that the Java transpilation in Gmail is for the backend, to share model and business logic, not the frontend. GMail, AFAIK, never used GWT for its UI
dham 5y ago
We also had Java Server Faces and .net Webforms
lhorie 5y ago
I wasn't aware of anyone using GWT outside of Google. Prototype.js + Scriptaculous was what really started the JS craze IMHO, followed by jQuery. Then came the increasingly more complex MooTools and YUI and Ext.js and friends, though nothing really took off nearly as hard as jQuery did. Backbone is probably also noteworthy as the bridge between jQuery spaghetti and the structured frameworks we see today (on the library consumption side). Knockout.js also deserves a shout out on the front of library authors looking for better abstractions. A bunch of people messed with Rhino (IIRC Jaxer was one of the bigger ones), but Rhino had a bunch of quirks. For example, strings were Java strings, meaning that length is obtained via `"foo".length()` instead of `"foo".length`. Perhaps the biggest showstopper was the JVM variable limit per class file. Compiling large enough Rhino JS code would yield class files that crashed due to that limitation. And since JS didn't have modules back then, big balls of code were the norm. Back then, the divide between frontend and backend was also wider. "Full stack" and the uplevelling of frontend folks towards backend skillsets wasn't really as popular as it is today. Node was also seen as revolutionary due to its async I/O first philosophy, whereas Rhino was more or less just a worse Java.
- karmakaze 5y ago
  I used GWT at one company for a bit. It was a mixed bag sort of like maybe React-Native today, not so much in how the tech works but in the way lots of things work and things feel different or have unexpected seams. I remember at the time thinking it was quite impressive for how much it could actually do.
  - ibly31 5y ago
    I work at a ~1200 person company, been using GWT since I think 2012, before I joined. It's a mixed bag - it's clunky as hell sometimes, and we have been iteratively replacing it with React in places. Buuuut at the same time I'm often marveling at how amazing it is what they accomplished getting Java->JS compilation working like that. It's a very productive framework if you know how to actually use it. And that's tough to do
- ysleepy 5y ago
  afaik Vaadin was based on GWT and had/has quite some customers.
eyko 5y ago
I don't remember the original Gmail having a rich editor in the compose view (I've been trying to source some screenshots but can't seem to find any with the compose view), but I do remember it being pretty impressive for the time. There definitely were a few libraries pushing the envelope back then. SproutCore for instance was around in 2006 and Apple built it's first version of MobileMe on it[1]. Prototype.js[2] first came out in 2005. I believe it was Prototype.js that first popularised the dollar sign $() for CSS selectors, or was it cssQuery[3]? Prototype also had Dojo[4] as healthy competition right from the start. I also remember YUI[5] and its offshot Ext.js[6]. Most will also remember YUI[4] and its offshoot Ext.js[5] 1. https://techcrunch.com/2008/06/09/want-to-try-out-mobileme-check-out-sproutcore/ https://techcrunch.com/2008/06/09/want-to-try-out-mobileme-c... 2. https://en.wikipedia.org/wiki/Prototype_JavaScript_Framework https://en.wikipedia.org/wiki/Prototype_JavaScript_Framework 3. http://dean.edwards.name/my/cssQuery/ http://dean.edwards.name/my/cssQuery/ 4. https://en.wikipedia.org/wiki/Dojo_Toolkit https://en.wikipedia.org/wiki/Dojo_Toolkit 5. https://en.wikipedia.org/wiki/YUI_Library https://en.wikipedia.org/wiki/YUI_Library 6. https://en.wikipedia.org/wiki/Ext_JS https://en.wikipedia.org/wiki/Ext_JS

azeirah 5y ago

I believe part of the reason Node got popular was because of two reasons 1. V8, which is actually really fast 2. Hype around being _asynchronous_ at the time JS itself started to become more hyped up.

Klonoar 5y ago
Asynchronous, and Node being so HTTP-friendly - I cannot begin to explain the sheer number of regurgitated "build a webserver in Node" tutorials that got written up back in the day. For whatever reason, you could have done this stuff in Rhino - for better or for worse - it's just that nobody ever took it as seriously.
- saurik 5y ago
  Not only could you, but some of us even did (though it definitely was never, as you say, "taken seriously"). What made it super powerful (and very node.js-like) was combining it with Jetty, which was a servlet engine that could be used as a library. My (trivial, personal blog) website is still running with this stack (though I finally put it behind an nginx SSL terminator as I have been putting off upgrading Java and Bouncy Castle just couldn't keep up), and it gives me more warm fuzzies than v8 alternatives. A "people actually used this" framework that had Rhino at its core (well, in one of many ways of using it) was Apache Cocoon (which was maybe more by-default based in XSL/T), only they did something almost ridiculously clever: as Rhino had full support for continuations, they didn't need "callback hell" (or async/await) and could even support pseudo-synchronous code that could block on the user (such as a function which sent the user a form and returned the user's selection, possibly hours later) by storing the continuation state in the user's session.
  - Klonoar 5y ago
    >A "people actually used this" framework that had Rhino at its core (well, in one of many ways of using it) was Apache Cocoon (which was maybe more by-default based in XSL/T), only they did something almost ridiculously clever: as Rhino had full support for continuations, they didn't need "callback hell" (or async/await) and could even support pseudo-synchronous code that could block on the user (such as a function which sent the user a form and returned the user's selection, possibly hours later) by storing the continuation state in the user's session. Wow! I'd only dabbled in Rhino back in the day so this is a neat little bit of history. Teleports me back to when this stuff felt fun...
- neurostimulant 5y ago
  I think it's due to the huge hype around chrome among developers back then. Each tab as separate process was huge. It also has built-in dev tool, and v8 being actually fast excites a lot of devs and drove them away from firefox. So when nodejs was released, a lot of people already know what v8 is and have positive impression of it, probably enough to nudge them to try nodejs. On the other hand, I never heard of Rhino until now.
bin_bash 5y ago
And npm. I don’t think Rhino had a good story for dependency management.
- emn13 5y ago
  I think you've hit the nail on the head; npm was the real killer app - it makes it very easy to try out node and result in a real, usable app with very little code nor (visible) complexity.
  - moffkalast 5y ago
    npm is what pip could've been if wasn't mismanaged into oblivion.
    - MereInterest 5y ago
      As someone who hasn't used npm beyond toy projects, what major features does it have that pip doesn't have?
      - matsemann 5y ago
        Installs in a local folder to the project (node_modules) instead of pip which installs packages to the global python installation unless ran in a virtual env. So getting anything up and running is trivial, compared to the amount of installations and steps needed with pip, unless you wanna bork your global python installation. With npm it's also really easy (almost too easy) to take your current folder and push it to npm, making the ecosystem bloom with packages.
        goodoldneon 5y ago
        The virtual env thing is extra friction but isn’t terrible: $ python -m venv .venv $ source .venv/bin/activate $ pip install -r requirements.txt Most IDEs will automatically pick up the .venv folder
j45 5y ago
v8 was huge was fast but the CLI was a big deal too
brightball 5y ago
When Node first came out, all of the hype around it was using the same language on the client and the server OR at least managing all of your frontend bits in a language independent of your server side language. At the time, there were JS/CSS/image minifiers in just about every language IIRC. Doing it with Node was a stronger argument to at least save the frontend side of the house from having to find a way to do them with Java or ASP. During that time period, Java compile times were so slow that using PHP as a frontend that spoke to Java backends with SOAP services was really, really common just to avoid slowing everything on the frontend down with Java.
zokier 5y ago
For context, the thing preceding nodejs in the hype cycle was ruby on rails. While many great things could be said about RoR, performance definitely is not one of them, especially in the early days.
- pragmatic 5y ago
  I love having to run a sentinel app that would restart your app on crashes. I forget the details but RoR was a deployment catastrophe.

genezeta 5y ago

> IIRC the only option at the time for running JS on the server was Rhino (based on Netscape/Mozilla), which for whatever reason never saw the broad adoption of Node. There was SSJS on NES/iPlanet/whatever before that. I mean, it existed. It was not really useful and few people even noticed it existed at all, but it did exist.

womansplainer 5y ago

Oddpost was before Gmail and functioned almost exactly like native outlook https://en.wikipedia.org/wiki/Oddpost https://en.wikipedia.org/wiki/Oddpost MS themselves had fairly functional Outlook web interface in 1995 (and was the reason XMLHTTPRequest was introduced

tomhoward 5y ago
Oddpost was such an inspiration as to the kind of UX that was possible via the browser.

deleted 5y ago

[deleted]

pzuraq 5y ago

I am, indeed, too young to have accurate memories there! Of course right after I posted this I started hearing about GWT and Closure, that's a bit of egg on my face. I mentioned Gmail as an important marker, everyone I talked to remembered it as the _moment_ which proved that JS could write full applications in the browser, but I assumed that it was written with an internal framework of some sort (none of my mentors who've been in the industry mentioned it when I brought up Gmail, and there's no mention of it on wikipedia: https://en.wikipedia.org/wiki/Gmail https://en.wikipedia.org/wiki/Gmail) That said, I think it's an important landmark and I may end up revising this post to add a bit more discussion about it. Thanks for pointing it out!

jeremyjh 5y ago
The buzzword circa 2006 was "Rich Internet Application" framework/platform and the concept was not even totally new then. It included GWT, but also an Adobe product built on Flash called Flex and some other vendor solutions that compiled to Javascript that I no longer recall the names of. The space was well-defined enough that there was a Gartner magic quadrant for it.
- karmakaze 5y ago
  I had a big interest in RIA at the time. The big players were Adobe AIR, Microsoft Silverlight, Eclipse RCP, Netbeans, and I also considered JavaFX--I might be forgetting another one. Silverlight had the best performance/fit for my purposes and sadly was the first of many to go away, largely due to the popularity of iPhone and these platform/tools being excluded. Too bad Apple only promotes Apple's innovations and actively suppresses others.
tolmasky 5y ago
Not to toot our own horn, but I'd look into Cappuccino and 280 Slides too (we were YC no less!) and were the first iteration in the GWT era to extend JS itself and transpile in the browser.
- no_wizard 5y ago

lucideer 5y ago

GWT wasn't really a javascript framework - granted it was more of a framework than something like emscripten, but from a "developer writing code conforming to a defined framework structure" perspective, there's not a huge amount of javascript involved. Furthermore, there really wasn't very widespread "community" use of GWT (mainly Google, and outside of that, mainly oldcorps working at similar scale to JS-ify old corp codebases), and even Closure was mainly leveraged by the community as glorified early babel / webpack type tooling, rather than a full range of things, e.g. Clojure. All that said, calling React a "framework" is a big stretch, which makes the title questionable while one is reading through the components section, so I guess one could get away with including a few not-framework-ey things. But... overall I don't think the author's age hampers them as much as you make out: when I started programming in JS circa 2002, nothing existing in that ecosystem was really comparable to today's frameworks, so comparing them here would add little.

j45 5y ago

Around 2000 it was possible to write AJAX applications with xmlhttprequest using JavaScript to achieve no refresh apps in the browser. Folks are building with a 20+ year old idea that has continued to evolve, in part because JavaScript is ancient in internet terms but uniquely positioned as one of the only languages (if you could call it that at the time) that was web first, instead of a traditional programming language having to connect to the web via a framework. Ironically, the core feature for web apps in the browser to enable this existed thanks to Microsoft. Brutally simple, efficient and likely part of what gave rise to so many JavaScript frameworks since people generally had to roll their own. I’m sure there might be some here who reverse engineered what Outlook Web Access was doing. “ The concept behind the XMLHttpRequest object was originally created by the developers of Outlook Web Access (by Microsoft) for Microsoft Exchange Server 2000.[4] An interface called IXMLHTTPRequest was developed and implemented into the second version of the MSXML library using this concept.[4][5] The second version of the MSXML library was shipped with Internet Explorer 5.0 in March 1999, allowing access, via ActiveX, to the IXMLHTTPRequest interface using the XMLHTTP wrapper of the MSXML library.[6]” Building an app in the browser was not a popular idea partially because of the instability of high speed internet and the lack of performant mobile internet, and if imaginable, the lack of users on the web at that time. The first major rush of users online was likely Facebook. Still it was possible to build a full ms office UI clone working in the browser, except it was powering your custom app. Sometimes things are gaining popularity for a long time before they suddenly get discovered. This single call was a reason why jquery became so popular. What I enjoyed about this article was how it speaks to an internet generation of tech or users emerging every 2-3 years, something I have long felt. Everyone starts somewhere, everyone is new to learning something and those experiences are worth sharing for new developers who do not quite have their compass in place yet. https://en.m.wikipedia.org/wiki/XMLHttpRequest https://en.m.wikipedia.org/wiki/XMLHttpRequest https://en.m.wikipedia.org/wiki/Ajax_(programming) https://en.m.wikipedia.org/wiki/Ajax_(programming)

deleted 5y ago
[deleted]

soapdog 5y ago

I was doing JS with frameworks circa 2006. I remember mooTools, Dojo Toolkit, Prototype, jQuery, and some others that were around before 2010. Unless we have very different meanings for the word framework. I consider Prototype, Dojo Toolkit and mooTools frameworks while I think of jQuery as a library.

teknopurge 5y ago
mootools was awesome. I always wondered why it was so fun(for me at least) to use.
cmrdporcupine 5y ago
Yep, mochikit was another one that I liked. I worked at a company around 2001 that was doing a full "Ajax" style frontend for a dashboard product for some industrial control systems. But it worked in IE only, as the Ajax pieces were not available on the other browsers yet.
brightball 5y ago
Prototype, Dojo and mooTools! Memories. I remember discovering any of these existed after doing an entire AJAX frontend site with raw JS that continued to work cross browser for the next 10 years. Made me full appreciate the value of those frameworks. IIRC JSON wasn't even really a thing yet.
spookthesunset 5y ago
I don't even think mooTools and friends were really frameworks as we know them today. They were really just some kind of standard library that let you plug in fancy UX widgets and stuff... I dunno if the distinction really matters though. But I do know they weren't even in the same league of frameworks like angular or react. I guess the difference is these new frameworks are all about letting javascript generate virtually the entire page. MooTools and friends were designed where the majority of the page was old-fashioned HTML being spat out by the backend.
afavour 5y ago
To my mind MooTools and jQuery were roughly equivalent in functionality. Am I misremembering?

thrower123 5y ago

It's not clear that writing tooling in Javascript has been a win. I do hope that we can get back to that "JS as compilation target" model eventually with WebAssembly. Even with improvements like TypeScript slathered on top, it's not fun writing Javascript, the tooling sucks, and it's vastly less productive than better developer ecosystems.

teh_klev 5y ago

> IIRC the only option at the time for running JS on the server was Rhino Not really true[0]. You could run server side JavaScript with JScript[1] on IIS as far back as the days of IIS 3.0, circa 1997. JScript is ostensibly JavaScript and tracked the original Netscape releases and then the ECMA standards. [0]: depending on your love/hate with Microsoft at that time :) [1]: https://en.wikipedia.org/wiki/JScript https://en.wikipedia.org/wiki/JScript

caseyf 5y ago

> Gmail was released in 2004, Google Maps in 2005, Google Docs in 2006 Lots of dynamic (and complex) web-based CRMs were competing with each other in 2000. At my job, we were doing what is called "HTML over the wire" today by posting forms and using a frame as the target.

_fat_santa 5y ago
With frameworks like Remix now I feel like were going full circle back to "HTML over the wire"
- deleted 5y ago
  [deleted]

bitwize 5y ago

Netscape Web Server supported server-side JavaScript since the mid 90s. Rhino was a development intended to provide JavaScript support to Netscape's all-Java browser ("Javagator"), because at the time Java was clearly The Future and we would all be running it on our desktops.

tyingq 5y ago
One of the funnier things about Netscape's server-side JS "LiveWire"... LiveWire's unpopularity and subsequent death was often attributed to its need for compiling and bundling steps, which seemed cumbersome to the JS devs at the time.
pram 5y ago
This just reminded me of Sun HotJava, which was genuinely one of the worst pieces of software I have ever experienced.

cmrdporcupine 5y ago

AFAIK none of the Google products you mentioned used GWT. In fact when I got to Google in late 2011, I believe the only thing I could confirm using GWT seriously was some display ads admin tools. GWT was awful. And not really used inside Google much.

sa46 5y ago
GWT was replaced by the similar J2CL and is used for GMail, Inbox, Docs, Slides and Calendar.
- cmrdporcupine 5y ago
  I wasn't on the gmail team but my understanding from friends that were is that the Java transpilation in Gmail is for the backend, to share model and business logic, not the frontend. GMail, AFAIK, never used GWT for its UI

dham 5y ago

We also had Java Server Faces and .net Webforms

lhorie 5y ago

I wasn't aware of anyone using GWT outside of Google. Prototype.js + Scriptaculous was what really started the JS craze IMHO, followed by jQuery. Then came the increasingly more complex MooTools and YUI and Ext.js and friends, though nothing really took off nearly as hard as jQuery did. Backbone is probably also noteworthy as the bridge between jQuery spaghetti and the structured frameworks we see today (on the library consumption side). Knockout.js also deserves a shout out on the front of library authors looking for better abstractions. A bunch of people messed with Rhino (IIRC Jaxer was one of the bigger ones), but Rhino had a bunch of quirks. For example, strings were Java strings, meaning that length is obtained via `"foo".length()` instead of `"foo".length`. Perhaps the biggest showstopper was the JVM variable limit per class file. Compiling large enough Rhino JS code would yield class files that crashed due to that limitation. And since JS didn't have modules back then, big balls of code were the norm. Back then, the divide between frontend and backend was also wider. "Full stack" and the uplevelling of frontend folks towards backend skillsets wasn't really as popular as it is today. Node was also seen as revolutionary due to its async I/O first philosophy, whereas Rhino was more or less just a worse Java.

karmakaze 5y ago
I used GWT at one company for a bit. It was a mixed bag sort of like maybe React-Native today, not so much in how the tech works but in the way lots of things work and things feel different or have unexpected seams. I remember at the time thinking it was quite impressive for how much it could actually do.
- ibly31 5y ago
  I work at a ~1200 person company, been using GWT since I think 2012, before I joined. It's a mixed bag - it's clunky as hell sometimes, and we have been iteratively replacing it with React in places. Buuuut at the same time I'm often marveling at how amazing it is what they accomplished getting Java->JS compilation working like that. It's a very productive framework if you know how to actually use it. And that's tough to do
ysleepy 5y ago
afaik Vaadin was based on GWT and had/has quite some customers.

eyko 5y ago

I don't remember the original Gmail having a rich editor in the compose view (I've been trying to source some screenshots but can't seem to find any with the compose view), but I do remember it being pretty impressive for the time. There definitely were a few libraries pushing the envelope back then. SproutCore for instance was around in 2006 and Apple built it's first version of MobileMe on it[1]. Prototype.js[2] first came out in 2005. I believe it was Prototype.js that first popularised the dollar sign $() for CSS selectors, or was it cssQuery[3]? Prototype also had Dojo[4] as healthy competition right from the start. I also remember YUI[5] and its offshot Ext.js[6]. Most will also remember YUI[4] and its offshoot Ext.js[5] 1. https://techcrunch.com/2008/06/09/want-to-try-out-mobileme-check-out-sproutcore/ https://techcrunch.com/2008/06/09/want-to-try-out-mobileme-c... 2. https://en.wikipedia.org/wiki/Prototype_JavaScript_Framework https://en.wikipedia.org/wiki/Prototype_JavaScript_Framework 3. http://dean.edwards.name/my/cssQuery/ http://dean.edwards.name/my/cssQuery/ 4. https://en.wikipedia.org/wiki/Dojo_Toolkit https://en.wikipedia.org/wiki/Dojo_Toolkit 5. https://en.wikipedia.org/wiki/YUI_Library https://en.wikipedia.org/wiki/YUI_Library 6. https://en.wikipedia.org/wiki/Ext_JS https://en.wikipedia.org/wiki/Ext_JS