Hacker News Reader

Comment by jmillikin | Hacker News Reader

  > 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.

View on HN

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.

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.

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

afaik Vaadin was based on GWT and had/has quite some customers.

I think they're all in on Web Components[0] now, though they still offer their GWT "flow" components, I imagine due to their customer base.

[0]: https://vaadin.com/docs/latest/ds/overview

I wrote an app in GWT in 2011-12, and there was an existing sibling app also in GWT.

It worked. It let me use my existing desktop app experience (Java, C#, C++) to write code that had a familiar style ( `myButton.setText("Click Me")` ), and build very desktop-style apps that ran in a browser.

But after having learned JS and Backbone, and then React + Redux, it was clear this was a much better way to build apps in general. (Obviously I became biased towards React and Redux personally as shown by my involvement with those tools, but it truly was a big mental shift in how I approached writing code in the first place.)

React and Preact really are nice. I’ve been building native and web apps and services since y2k. Preact, combined with Typescript is probably my favorite tech yet.

Though, I’ll note that I do really miss VB6 and C# Winforms for RAD.

People forget too easily.

It took MONTHS to become proficient at early-ish frameworks like GWT, Dojo, Marionette, Angular, Knockout, Ember, Enyo, etc.

Getting up and running on React in a couple hours and almost completely understanding the entire API inside a couple days was incredible. The fact that the code was faster and had fewer bugs too was almost too much to believe.

> It took MONTHS to become proficient at early-ish frameworks like ... Knockout

Nah.. I don't know about the others but Knockout was super simple to learn and get going with. React was way harder IMHO.

Knockout was definitely easier to get started with vs other frameworks of the time, but still not easy by any stretch. It took time to master the template DSL, debugging templates would take you all across the guts of Knockout, and complex 2-way bindings could have you spending hours debugging them. Getting good performance was also very tricky.

ReactJS of the time was pretty simple.

https://web.archive.org/web/20131105184444/http://facebook.g...

You could read every scrap of documentation in around an hour or so. There were only around a dozen-ish APIs to learn along with only a couple "unique" concepts like controlled inputs, refs, and JSX.

Meanwhile, there was never a need to step into React code unless you believed React itself was buggy (I only came across this one time and the bug had already been reported and was being worked on). Even better, React code was usually faster than Knockout before optimizing stuff and the ways to improve performance were generally pretty obvious.

Different strokes I guess, but 2 way binding is what made Knockout really simple for my team to get their head around compared to React (back then).

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.

You forgot Dojo, which was the first big javascript framework.

We have a different recollection of the order of events. I was doing web dev professionally as of 2004, and how I recall it is this:

Originally people had utilities files with a bunch of javascript convenience functions copied from random blogs that they would use to enrich server-side generated pages. This is how I wrote web apps in 2004-2006: php-generated html with hand-rolled js to enrich it.

Out of those grew the first generation of libraries (not frameworks) like prototype, mootools and finally jquery (which was so good at being a web swiss army knife that it replaced every other library).

The libraries were ok to add a bit of interaction but not at building entire UI. The “write your whole UI in JS” approach I remember being popularized by dojo and yui / yui-ext / extjs. GWT was a big hype but indeed not used by many. Lots of people used dojo and extjs though. I switched to ExtJS as soon as it arrived on the scene in 2007.

Those early frameworks only solved the UI problem, they were not great at page lifecycle and backend interaction, so they relatively quickly got replaced by application frameworks that did, like backbone and angularjs. Their mistakes became the inspiration for the second generation of SPA frameworks that we are still using today.

My recollection was that Prototype.js got a big boost in popularity early on on the back of its inspiration from Ruby on Rails (in the sense that abusing prototype pollution to make DOM elements have useful methods was novel and cool). Dojo and friends were comparatively obscure/niche until much later. I recall only reading about Dojo years later, during the whole Comet hype.

My impression of the era was that visual pizzazz was all the rage, and Scriptaculous really delivered on that front (Flash was also huge back then). Whereas full blown web apps were relatively rare and a lot of library consumers just didn't see the point of things like modularization (despite the interest in "proper" engineering from library authors like Dean Edwards et al)

And even then, once interest in thick clients grew, Ext.js had a lot more fanfare among the heavier frameworks than the Dojos and MooTools, due to its focus on enterprise.

GWT was used pretty widely by "the enterprise" outside of Google. For a long time, it was a large community with heavy traffic on mailing lists and stackoverflow. GWT was featured prominently at Google I/O for several years.

I wandered into the comments to find or write the correct "before times" bit, and I think this covers everything I would've mentioned.

I'll add that looking back, EXT seemed to be a bit ahead of its time. Its data/table view rivals AG Grid [0] of today. If we could've just standardized on a table view by now, but alas.

AG Grid - [Ag Grid, agnostic JS table framework](https://www.ag-grid.com/)

It was pretty heavily used in enterprise on applications from around 2006-2012. I still have nightmares of it, as since it's enterprises the code bases got massive and GWT in my experience had a trend of getting a ton of code smells.

A nitpick, but MooTools is closer to the Prototype.js era than jQuery - we used both extensively at freewebs.com (a large WYSIWYG online website builder) before ultimately moving towards jQuery down the line after it took off.

We used it at freewebs.com?? As a kid, I used freewebs all the time and it likely got me into web development as a career. Thank you very much.

Ha, glad to hear it!

As to frameworks, I know nothing. As to Javascript libraries and their order of appearance it was: YUI in Feb-2006; then JQuery in Aug-2006; and finally Mootools in Mar-2007. Not a developer but my recollection is the same as yours with regard to JQuery -- it roared to dominance seemingly overnight.

Nobody talking about the DHTML days when we were all writing our own “JavaScript” components?

Glad you mentioned ext.js. It was one of the early frameworks that tried to create a complete, all js, gui component model.

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)

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!

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.

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.

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.

Honestly it’s a shame Cappuccino didn’t take off it’s actually a super interesting framework and was (is?) extremely powerful even by today's standards

Personally I feel that Cappuccino is one of the last frameworks that still cared about a kind of interaction design that’s no longer discussed on the web, replaced mostly by more devops/abstraction-oriented discussions.

I manage a web UI programming language in my free time, and the juxtaposition of folks claiming FP ergonomics benefits, then upon my request, showing a static, interaction-less end result whose improved version would obviate their pristine architecture, is pretty staggering. The typical defense is "hey we're not designers" but if you zoom out a bit you realize the whole environment doesn't foster engineers to care about design concerns anymore (barring a niche but valuable vertical of optimizing for payload size). This in turn puts pressure back onto designers who come to expect less and less of what they care about on the web.

Just the other day a newcomer shipped an animated row transition after fighting her framework for 3 weeks. The designer was delighted, but the manager didn't even get the point because he matured in whichever era of JS framework that de-emphasized acquiring taste in interactions.

I myself come from a Flash background, so rather than seeing an upward trend, I see a decline in UX concerns, followed by an incline of devops-related concerns in UI frameworks (accompanied by HN comments saying that in both cases the web should have stayed as a document format, only to end up with an awkward mix of document + app architecture their desktop apps through Electron anyway).

If I were to categorize these "eras", I'd rather take the perspective of wondering at which point, and why, framework process ended up more important than the product. Heck, a similar thing is happening on native too, unfortunately. Where did all the interaction designers go?

Maybe AR would nudge more folks to learn and focus on rendering, gestures, transitions, framerate, intent and the rest.

You might want to look into Outlook Web Access. It predated gmail by many years and is the reason today we have XMLHttpRequest.

No worries, as you weren't working then, but to give some context, what you have in the "first frameworks" I would probably call the third generation of frameworks. So the breakdown you have is nice, but probably only covers the second half or maybe third of the story.

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.

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.

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.

mootools was awesome. I always wondered why it was so fun(for me at least) to use.

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.

To my mind MooTools and jQuery were roughly equivalent in functionality. Am I misremembering?

There's really three distinctions, in my mind:

1) Libraries (jQuery/Prototype/MooTools/etc) (Beginning - ~2010ish)

2) Widget-frameworks (YUI, Dojo, jQueryUI, etc) (mid-2000s - ~2013ish)

3) Data-orientied Frameworks (Backbone-onwards) (~early 2010s - current)

Edit: (Four, maybe, if you divide 1 into a 1/0 era, with 0 being the "rando DHTML scripts that many didn't really understand" era)

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.

Oddpost was before Gmail and functioned almost exactly like native outlook

https://en.wikipedia.org/wiki/Oddpost

MS themselves had fairly functional Outlook web interface in 1995 (and was the reason XMLHTTPRequest was introduced

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

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.

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.

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.

>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...

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.

And npm. I don’t think Rhino had a good story for dependency management.

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.

npm is what pip could've been if wasn't mismanaged into oblivion.

As someone who hasn't used npm beyond toy projects, what major features does it have that pip doesn't have?

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.

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

I don't know what you're talking about—every time I have to do this I have no idea what I'm doing and I'm a senior engineer at FAANG.

I admit that I'm not a Python engineer, but I have been in the past—twice!

It's just a little switcheroo so that your shell environmental variables point to a project-local Python install rather than a global one.

Virtualenv used to be a third party package, which was a very high friction because you'll need to install it system-wide first (e.g. from distro's package manager) before you can use it to create virtual environments.

Not terrible, but still not as good and easy as npm. For example, you can't make a distinction between runtime and development dependencies, and it doesn't solve circular dependencies. Luckily there is Poetry which exactly does this.

It’s more of Python’s fault that pip’s, but (AFAICT) there isn’t a way to install multiple versions of the same dependency. You might have direct dependency A which needs version <2 of X, but also direct dependency B which needs version >=2 of X.

Since those version ranges of X don’t overlap, it isn’t possible to satisfy both A and B’s requirements. Node can handle this

I stand by the opinion that allowing multiple dependency versions was a major mistake that lead to both ballooning node_modules and abandoned packages getting caught up in your dependency tree just waiting for a malicious actor to hijack them.

In pip or composer, those dependencies have to be forked or removed or they will create conflicts.

Yarn lets you reject multiple versions.

Multiple dependency versions causes problems but the alternative is pretty bad, too. You can get stuck on older versions of a dependency because newer versions have a transitive dependency that causes a conflict with a different direct dependency

I feel like that's at least a solvable problem that makes itself obvious when the dependency is added. Multiple coexisting dependency versions sounds like a ticking time bomb to me.

Suppose I use a LibraryX that provides DataTypeX, and most of the functions in my project operate on DataTypeX. I later add another LibraryY, because it provides a utility function returning DataTypeX. I should be able to take the result and use it anywhere in my existing code. However, if my direct dependency on LibraryX is a different version than transitive dependency on LibraryX through LibraryY, then it may not have the same functionality. In trying to avoid a problem at compile-time, the package manager has introduced a huge potential problem at run-time.

Declarative dependency management. Every Node project has a package.json file, which is the first thing that I look at. It gives you so much information at a glance, and it allows for reproducible builds with just one command.

With pip you have to resort to hacky solutions like like pip freeze. It also doesn't solve circular dependencies. Luckily these days the Python world has Poetry, which exactly solves this issue, and might be even better than npm. Unfortunately it's third party and adoption is a bit slow, but I use it for all my projects.

Don't know nowadays, but a few years back when I was still using python something that drove me nuts from pip was how bad it was at managing transitive dependencies.

If package A depends on package B 1.0 and package C also depends on package B but 2.0, the order in which you run pip install for A or C will lead to a different version of B. And of course either A or V would break as soon as they hit an incompatibility. Obviously you would notice that only by running the application or tests.

So you have to use pip freeze to kind of generate a semi lock file,and every project uses it in a different way, because you also need different dependencies files for dev and production....and these are just plain TXT files which I don't think it is the best "format" for this.

Then you have these text files but also a "setup.py" which is for the package you produce, but hey you need to read the txt because otherwise you need to maintain them in two places. So you add a Makefile to tie all of this together, and that's another rabbit hole.

Add to this the mess of virtualenvs already explained in sibling comments and you have the perfect storm.

I know that nowadays are things such as Poetry, which work a lot better, but there are a good bunch of tools competing with each other.

To make an analogy, npm feels like using the latest, top of the line Macbook while pip feels like using a Casio calculator from 1985 with an external keyboard. That's the gap I feel between these two tools.

So if you ever use python, try first poetry or any of the other tools, pip is a terrible mess.

> wasn't mismanaged into oblivion.

What's so "mismanaged" about pip? Honest question, I work with NPM every day but I've never really touched pip so all.

Excuse me my snark comment, but npm doesn’t have a good story for dependency management either.

It’s the most successful one but okay.

Success has nothing to do with quality.

It's a good story though.

In 2010 it made it very easy to share libraries which helped Node grow in popularity. I don’t believe it was possible to do anything like this in Rhino without Java packages but I could be wrong. Certainly it wasn’t as easy as with npm.

Maybe it didn’t have package signing, lock files, or deduping, but clearly it was popular in spite of those faults.

There was Narwhal, which was on Rhino and had a package manager (CommonJS as well.) But it got overtaken by Node pretty quickly.

These days it’s cool to mock npm, but it was package management done right™ back then.

I hate all of them, use only when it’s almost inevitable, so I can’t really have an objective opinion.

Oh it was mocked back then too—mostly for the pre-npm@3 releases that didn't dedupe. If you thought node_modules was big today, imagine what it was like then.

Though it clearly worked well enough to be fantastically successful despite valid complaints about it.

Early npm would regularly create directory trees so deep Windows couldn't delete them, and I was just using it to pull down LESS and friends.

Why not?

v8 was huge was fast but the CLI was a big deal too

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.

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.

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.

> 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

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/Ajax_(programming)

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.

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-c... 2. https://en.wikipedia.org/wiki/Prototype_JavaScript_Framework 3. http://dean.edwards.name/my/cssQuery/ 4. https://en.wikipedia.org/wiki/Dojo_Toolkit 5. https://en.wikipedia.org/wiki/YUI_Library 6. https://en.wikipedia.org/wiki/Ext_JS

> 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.

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.

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.

This just reminded me of Sun HotJava, which was genuinely one of the worst pieces of software I have ever experienced.

> 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.

With frameworks like Remix now I feel like were going full circle back to "HTML over the wire"

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.

GWT was replaced by the similar J2CL and is used for GMail, Inbox, Docs, Slides and Calendar.

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

We also had Java Server Faces and .net Webforms

Reply on news.ycombinator.com