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.

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

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

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.

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

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.

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

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/)

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

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!

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.

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.

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)

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.

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.

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.

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.

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

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

1. V8, which is actually really fast

2. Hype around being _asynchronous_ at the time JS itself started to become more hyped up.

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

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.

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.

  $ python -m venv .venv
  $ source .venv/bin/activate
  $ pip install -r requirements.txt

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

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

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

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.

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.

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

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

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

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.

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

On the other hand, I never heard of Rhino until now.

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.

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

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)

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.

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

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.

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.

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.

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.

GMail, AFAIK, never used GWT for its UI