20 ms·

Four Eras of JavaScript Frameworks

284 points by RafelMri 5y ago

codeape 4y ago
Of the modern front-end frameworks: What is the best framework to add some front-end interactivity to a existing server-side-rendered application (Flask, Ruby on Rails etc.), without going all SPA?
robertwt7 5y ago
There’s a redwoodjs as well for the fullstack which I feel like using laravel / django when using it. Battery included framework
k__ 5y ago
A bit of history revisionism, haha ExtJS, Ember, Angular, and Next are all "full-stack" frameworks and the all were released at very different times. I would say the "eras" were more like: Direct manipilation with custom architecture and models (JQuery) -> MVC/P (Ember/ExtJS/Angular) -> Components (React/Vue).
- magnio 5y ago
  That's how the article delineates it too. The term "Full-stack Frameworks" for the fourth era is a bit confusing: what the article means is the battery-included wrappers for popular component libraries like Next.js, Remix (React) or Nuxt.js (Vue) and not just any full-stack framework per se.
- deleted 5y ago
  [deleted]
- Tade0 5y ago
  +the next generation: "compiler-frameworks"(or "UI compilers"). Overall this division seems weird. SSR is neither a revolution, nor universally desirable. The real revolution is in what these next-generation frameworks like Svelte or SolidJS offer: small bundles combined with high performance achieved through eschewing virtual DOM in favour of precise changes in the DOM.
  - josephg 5y ago
    Yep. SSR has been around for ages. The very first "web frameworks" were pure SSR. And by that I'm referring to PHP and the old CGI! The big leap forward from Solidjs and Svelte is that they do complex source-to-source compilation to avoid virtual dom diffing. That approach lets them get the best of both worlds - the programmer can pretend their components are pure & reactive. (Solidjs looks almost identical to react.) Thats great because it means there's no bugs due to fiddly or forgotten DOM updating. But the javascript executed by the browser doesn't need any of react's complexity. The JS output by the compiler simply makes direct DOM manipulation calls when content changes. There's no heavy re-rendering of view trees, and no virtual dom to track. Unlike react, you don't need to apologize for mutating variables or re-render your entire page when you do. So we can do away with redux and all of that. A hello world app in solid or svelte is a few kilobytes, compared to 200kb+ for a react project. And it renders instantly. It took us a few years to get here, but I'm delighted by the direction UI code in the browser is headed. I hope these ideas make it into native applications.
    - Tade0 5y ago
      Also let's not forget about something that hasn't been the case over a decade now: the stack is readable again. I've found bugs in my Svelte code just by looking at the stack.
    - fabiospampinato 5y ago
      Actually that's just a common misconception, which I believed too. The complex compile-time transforms enable almost no performance improvements. As a proof just take a look at the js-framework-benchmark table [0], my framework (Voby [1]) is faster than both in the benchmark despite having an API very similar to Solid and no requirement for a Babel transform or other compile-time transform (though the basic React-like JSX transform is supported for convenience). Those transforms actually exist 99% just for providing some convenience features to the developer. If that weren't the case it wouldn't be possible to make something similar without a transform that's faster than both. In fact Svelte is actually quite a bit slower than both Voby and Solid. Svelte is even slower than Inferno, which is a (very optimized) V-DOM framework. [0]: https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht... [1]: https://github.com/fabiospampinato/voby/ https://github.com/fabiospampinato/voby/
- pzuraq 5y ago
  By "full-stack" here I mean frameworks which handle both the frontend and backend simultaneously, in a seamless way. The closest thing framework that I remember from the MVC/P era which attempted this was Meteor.js, but it was really horrendous to use in my experience. Otherwise, it was very common practice to serve an Ember or Angular app as static files Nginx or directly on a CDN. Wrapping them in a server-side framework was always a bespoke process which required you to effectively maintain two frameworks, and stitch them together yourself (unless you count Ember + Rails in the early days, but even that is a stretch IMO). When SSR was introduced in any framework, it was usually not used to its full potential to be able to accomplish the use cases I discuss in the post, like authentication, API endpoints, etc. It was just used to render the app on the server. It did not fundamentally change the DX of the framework. I honestly was pretty skeptical of these latest frameworks until I gave them a shot! It doesn't sound that revolutionary until you actually start using them, and things which were previously quite difficult become absolutely trivial. I highly recommend trying them out some time.
- mrits 5y ago
  I'd say JQuery and ExJS were part of the same era. JQuery was used by a lot of people that didn't embrace javascript at all and tried to not use it (e.g ASP.NET coders) I feel like backbone deserves its own era as it seemed like all the cool kids would exclusively use that for a couple years. Then Angular and a ton of others flooded the scene.
mg 5y ago
I wonder if I will ever use a JavaScript framework. My projects are usually either in the form of "User enters data, sends it to the server, server sends a new page back" Example: https://www.gnoosic.com/faves https://www.gnoosic.com/faves Or in the form of "User changes parameters on screen, Javascript updates the screen accordingly". Example: https://www.productchart.com/laptops https://www.productchart.com/laptops In both cases, I don't see the benefit I would get from a framework. If you have built a project that is public and benefits from using a framework, I would love to see it!
- hnlmorg 5y ago
  I never use frameworks either. In fact the last site I published didn't have any Javascript at all (it's just a static site so shouldn't need it yet that doesn't seem to stop most other sites from abusive amounts of JS).
- aurora72 5y ago
  gnoosic.com/faves is cool but the Allmusic.com's related artists section is the ultimate place to discover new bands.
- vmception 5y ago
  Sure, probably works, just don't complain about age discrimination when you bring up nonconsensus things that have been superseded, and the team isnt fond of that system design
- throwaway77384 5y ago
  I also started out without frameworks and still prefer to work that way. However, I have found them to come in handy when solo-ing projects that require: - transpiling JS back into the stone age for compatibility - accessibility - seamless localisation I have found I just can't keep track of all of these things as well as React does. At the same time, I think React is a huge, dependency-laden mess, very difficult to learn (because it's changed its mind on how to do things about 100x, so no responses to issues on SO apply to your version of React, Redux, React Router, etc), slow as hell and probably overkill for most projects...
- 5y ago
block_dagger 5y ago
The company I work at wastes millions of dollars on maintaining a complex React frontend for no technical reason whatsoever. It amazes me.
- bnt 5y ago
  My previous 2 companies basically lost all marketshare because they _had to_ use Node + React for their in-house CRUD tools. The amount of time and money wasted is insane. We ended up doing most things with Airtable because the dev team(s) were too slow.
- klabb3 5y ago
  What you talking? I don't particularly endorse react but what are you comparing to? If we're talking plain js or jquery style dom manipulation react, or any of its competitor, is a vastly superior for any non-trivial app. If you're having a mostly static site I can believe you though.
  - dsego 5y ago
    Probably to simple server-side frameworks. Most web apps are based on navigation and forms, which can be done simpler with classic server-side MVC and some JS plugins for the more interactive parts. No need for client-side routing, solidifying HTTP API endpoints or duplicating data models & logic on the front-end.
  - likortera 5y ago
    Something like Laravel + alpinejs running on heroku or Google app Engine or a similar platform is what 90% of the typical crud saas webapps most of us build need. But we definitely have more fun with React SPAs and Go microservices on Kubernetes :) (Notice I'm listing the shinny toys of the usual 3 layers at every company)
maelmori 5y ago
I still remember the day I discovered Dan Steinman's Dynamic Duo Javascript library. It allowed me to do effects that I thought were reserved only for flash or java embedded applets. That was in late 1999, probably while I was struggeling to make a crappy script copied from dynamicdrive.com work in Netscape 4. Tell me about eras!!
- rob74 5y ago
  The "Before Era" mentioned in the article can probably be subdivided further - it casually mentions that back then, "the most common thing you would do was include jQuery, throw together some scripts for a few UI widgets, and call it a day". However that was only possible after jQuery was released in 2006. Before that were the real "dark ages" of JS development, with primitive libraries, even more primitive dev tools in the browser (Firebug was also only released in 2006, and Chrome was the first browser to have integrated dev tools in 2008) and stuff like "be careful with console.log in IE, because it will crash your script unless the console is actually visible".
  - deaddodo 5y ago
    jQuery didn't even incept that, prototype.js did. Prototype is probably the first real jS library that moved the language (along with Dojo, Mochi, etc) from scriplets ("DHTML") to actual UI interactivity. That + XMLHttpRequest ("Ajax") were the direct progenitors to jQuery, which was used to bootstrap or complement all of the early "frameworks".
    - dpcx 5y ago
      I came here looking for this comment; it seems prototype is always forgotten about as part of the "before frameworks" discussion. I remember bringing up using prototype to my coworkers in 2006/2007 (the director was a stickler for having clickable buttons that had a specific width on the left and right of the text, so I proposed using prototype to set that automatically). I recall my coworkers being mostly confounded by it and how to use it.
  - andrewl-hn 5y ago
skybrian 5y ago
Probably should mention GWT in the "before times" somewhere, back when crazy things had to be done to work around IE bugs.
deleted 5y ago
[deleted]
Gunmeister 5y ago
Nice article. My JavaScript framework of choice is Meteor written in React.
- anonyfox 5y ago
  I second this
Kiro 5y ago
Can someone explain what Next.js actually is and why it's so popular? "hybrid static & server rendering" is their main USP but that seems... very minor. In all my single-page applications I always fetch the data from a separate backend so SSR has never clicked for me. This page is the first time I've heard it explained as a full-stack framework, which sounds more intriguing than just helping me with SSR.
- BigJono 5y ago
  It implements some patterns for rendering in both environments using the same code. The main problem with rendering in both the client and server environments using the same code is that you need to fetch data in two different places. On the server your code needs to fetch data during the render itself, whereas on the client you need to fetch data asynchronously then re-render with the data once it arrives (which in React means triggering the API call as a side effect, then setting the returned data as state, triggering a re-render). Unless you really need server side rendering and can't do it statically, Next.js is the wrong choice. IME like 98% of projects are just using it because the tech lead is resume padding or an idiot. The others are something similar to Reddit or Quora with a complex UI and dynamic data that needs to perform well on SEO. For those ones Next is probably a pretty good choice. Stuff like Next should be the 3rd tool in your arsenal after client and static rendering. It's a bunch of extra complexity for very little gain in most cases.
  - leerob 5y ago
    > The main problem with rendering in both the client and server environments using the same code is that you need to fetch data in two different places. `getStaticProps` and `getServerSideProps` _only_ run on the server – it's possible we're conflating "rendering" with "data fetching" here. You fetch the data on the server, and send pre-rendered HTML to the browser. You can, of course, also do client-side data fetching (e.g. `useEffect`) as you mentioned. > Stuff like Next should be the 3rd tool in your arsenal after client and static rendering. The philosophy of Next.js is that client, static rendering, _and_ server rendering have a place. For certain application holotypes, you might want all static. For others, all server-rendered. Next.js doesn't care - it allows you to choose which strategy you want on a per-page (e.g. route) basis. This allows you to not have to eject from the framework because your /contact pages wants to be static, while the /dashboard part of your site is server or client rendered. It also helps for incremental adoption.
jmillikin 5y ago
> 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.
kolme 5y ago
There's a framework that always seems to get forgotten, but was there before Backbone, Angular and others: the Dojo Toolkit [1], released in 2005, it had some goodies like built-in tooling (that was hell to work with) and modules (in 2005 they were godsend!) with RequireJS. We chose it in my company in 2008 before the framework boom and it had served us well for a very long time. It's batteries included, has for example it has a very comprehensive i10n module, which was not usual at the time. Also worth mentioning it was started among others by Alex Russell [2], a famous developer advocate at Google. [1] https://en.wikipedia.org/wiki/Dojo_Toolkit https://en.wikipedia.org/wiki/Dojo_Toolkit [2] https://infrequently.org/ https://infrequently.org/
lewisjoe 5y ago
Where we will go from here, is pretty obvious. Now that we've realized SSRs cannot be an optional afterthought, we'll soon realize SSRs with running JS on the server is a nightmare to scale - https://engineeringblog.yelp.com/2022/02/server-side-rendering-at-scale.html https://engineeringblog.yelp.com/2022/02/server-side-renderi... Just search HN for "scaling server side rendering" and you'll land on a bunch of practical complications. That doesn't mean SSR is bad. It just means we know the solution but stuck with the wrong tools. My hypothesis is that we'll capitalize WebAssembly to run our UI rendering logic and a tiny platform-specific rendering layer to translate rendering commands from WASM to platform. Interesting side-benefit: Language choices other than Javascript. I've already started working on a proof-of-concept React-ish library that runs on a WASM VM. IT lets you specify your UI component declaration and behaviour in Kotlin - https://github.com/joelewis/kwasm https://github.com/joelewis/kwasm
genezeta 5y ago
In Spanish there's a saying that goes "Cada uno habla de la feria según le va en ella". It means that everyone tells their story, that they say the fair went well or not depending on how it went for them. Another comment talks about revisionism and, while I think it is a valid critique, I think it goes beyond that. The author's career starts in 2012 and that's all the reference they seem to use. Sure, they admit they will "probably going to gloss over a lot" and that they "can’t write about what [they] didn’t experience". But then... is this fair? Or, a better question -since anyone can write whatever they want, of course-, will this be, then, just some person's story or will it actually be representative or a larger reality? Sadly, it feels like lately a lot of people seem intent in blurring that distinction. They seem to say "I may only have a limited view, but I'm going to present this as if this was the complete reality". And this is what this article does, I'm afraid. The fact that there's is absolutely no mention at all of Dojo is telling. It's also quite telling that dismissing claim of "throw together some scripts for a few UI widgets, and call it a day", the quite absurd "everything was global", and the error of suggesting XHR came later -"As time went on and XHR was introduced and popularized"-.
- pzuraq 5y ago
  I actually have a friend who wrote in Dojo, so was aware of its existence, but had no idea it was so influential/early in the First Frameworks era. Same with GWT/Closure, as has been mentioned by others. I did run this article by some mentors who have been in the industry since the 90s before posting, as I wanted to make sure I didn't gloss over it entirely, but unfortunately it seems they didn't experience those either. And I think that's the core of the issue, even people who were around at that time do not remember all of these things. Ultimately, even those of us who are trying our best are going to miss details, and this is only going to get worse as we get further and further away from the beginning. Honestly it seems like this is a job for historians, and unfortunately I am not one, just a dev trying to share my thoughts and experience > and the error of suggesting XHR came later According to Wikipedia, XHR was introduced in 1999, 4 years after JS was introduced: https://en.wikipedia.org/wiki/XMLHttpRequest https://en.wikipedia.org/wiki/XMLHttpRequest
  - 5y ago
kh_hk 5y ago
For me 2012 was the year I stopped any frontend work at all. As I remember, things felt very easy and natural when all I had to do was output html using templates, write CSS and add some touches of javascript here and there, either using jquery or mootools. Maybe a websocket to display something coming from a process. Then there was backbone, history push state, more frameworks, client side rendering, meteor, and a lot of impressive stuff. Very impressive stuff that felt needlessly complicated and made me procrastinate every time I tried to learn it. Nowadays, every time I look at a react codebase I feel certain emotions I can only describe as disgust. Maybe I have only seen bad codebases.
- wildrhythms 5y ago
  Not sure what you find 'disgusting' about a function that returns HTML; if anything it is more 'natural' than the templating and jQuery amalgamations of the past.
- brailsafe 5y ago
  I don't think you're alone. I felt the same way about overcomplexity until I had a few runs at working on already established complex frontend codebases. What seemed to happen around 2008 onward is that the basic principles of the web were sort of simple, but then to do anything at a larger scale it got pretty crazy quite quickly, and so new architecture ideas came along to address that by people who were in the business of solving engineering type architecture problems. For any site of inherently simple interactivity, it's always been as easy if not easier than it ever has, but now it's also more manageable if you know you're going to need to scale a certain way. It doesn't necessarily take all that much before you can start to see the reasoning. For example, take a humble grid of products, each with their own add to wishlist button, and a profile preview button in the corner of the page that indicates how many things are on your wishlist. Pretty simple to handle, render the thumbnails with unique ids and make an XHR request that stores the data with your account. Update the wishlist total count however you would. Now suppose though that each thumbnail in the grid can open a bigger preview dialog that has more images, a bigger description, and it's own add to wishlist button. You can click that button, and it does the same thing. You close the dialog, but now your grid item needs to reflect that it's already been added to the wishlist. These things get really tiresome to keep building, something that I'm sure isn't new to you if as you say, you've been in software a while. Sorry for the book, I mostly wrote that to challenge myself to think it through, not to imply you couldn't think of how it would be necessary to componentize things. I'm not particularly fond of React more than Vue or anything, except for the fact that they both allow you to define UI as collections of functional state machines when it's necessary to do so.
marcus_cemes 5y ago
I'm in love with the design of that website. It's clean, there are subtle graphic changes such as the pixel art that changes when you toggle the light switch, a really fantastic job there (one small remark, hovering over the pixel art on Chrome makes a scroll bar appear due to the transform). I want one. It's also proof that you can make a simple and pleasant experience with a JS framework, if you focus on the essentials, there's no need to boycott JS entirely in favour of the old web, these frameworks get rid of a lot of the boilerplate when starting from scratch. I'm an avid supporter of SvelteKit (the framework used on that website) and how they want to make the web less SPA/JS again. In this example, navigation is fast and client side, but can fall back to SSR if JavaScript is disabled, fails to load or hasn't loaded yet. There is no heavy runtime with virtual DOM diffing. Resources are cached and a page reload only sends ~17 kB over the wire on a large blog post, showing an excellent use of Tailwind CSS. It renders on Cloudflare Workers close to the user wherever you are in the world, with zero vendor lock-in if you want to stick it on a VPS.
- fruit2020 5y ago
  Why do people mention so often about js being disabled? It’s such an insignificant use case imho. Ssr(in js world) is mostly for public pages who get scanned by search bots, right?
  - rossvor 5y ago
    Probably because people who browse with js (mostly) disabled are over-represented on HN. So for us it is a significant use case.
  - likortera 5y ago
    Can't agree more with you. In my more than 20 years in this industry I'm still to find one single person at work, or a single customer with JavaScript disabled. At this point if you have JavaScript disabled is your problem. It's like having a car and not wanting to put gas on it and pushing it around and complaining why you have to push your car. Not saying we don't abuse its usage, but having it disables is just extremist
  - 5y ago
mattlondon 5y ago
I would be very keen to know if there are any of these "full-stack" frameworks that don't depend on NPM, or more specifically built with Deno or vanilla JS in mind? It feels like (to me at least) that at this stage it is quite clear that using NPM is an anti-pattern that is best avoided if possible (security, requiring a "dev machine" with the right version of NPM installed etc, general bloat) I know that there is nanojsx (https://deno.land/x/nano_jsx https://deno.land/x/nano_jsx) but would be keen to know of any other examples that anyone knows of?
- _fat_santa 5y ago
  > It feels like (to me at least) that at this stage it is quite clear that using NPM is an anti-pattern that is best avoided if possible (security, requiring a "dev machine" with the right version of NPM installed etc, general bloat) For all it's problems, it's still is the killer feature that makes it easy to develop JS apps. The things you mentioned can be mitigated with proper practices. 1. Security: Supply chain attacks can be mitigated through being deliberate about versions and making sure your CI systems always install a "frozen lockfile" 2. Requiring the "right" version of NPM: Can be easily solved through "engines" in package.json. You can basically tell your project to not run unless the dev has the right version of NPM. This is not that big of a deal since a dev can just install the correct version with npm. You can take this a step further with yarn and pin a specific binary in your project so it doesn't matter what version your devs are running, they will automatically use the binary you specified inside the project. 3. Performance and Bloat: Besides NPM, there's also Yarn and PNPM (Performance NPM) that both work much faster than NPM and are fully interoperable with existing package.json's. The ecosystem is still not perfect and security is still the biggest issue. The other issues you mentioned though can be easily mitigated through good practices.
numlock86 5y ago
Personally I think we already exceeded the sweet spot. Things like jQuery were merely abstractions and shortcuts, but didn't bring much to the table. In the end you had to do all the work. On the other end things like Next.js do so many things up to a point at which you start working against them to achieve certain things whilst ending up not using 80% of the framework because they are aimed at basically every possible case without being really specialized. It's mostly about accessibility these days, like getting started fast. While I don't quite agree with the clustering and categorization (as already mentioned by other comments), for me it feels like the ideal point was somewhere between era two (Knockout) and three (Vue, React), with a tendency to the second era.
- BigJono 5y ago
  The sweet spot is still there, in theory. React itself is just a few functions forming a very simple (but not necessarily intuitive) abstraction. The issue is the community is batshit and it's almost impossible to find or build a team that's going to democratically decide to use a sensible approach. If you want to keep a simple codebase on a React project your three options are build the entire thing yourself, be the best interviewer of all time and find a one in a million team, or be willing to be an absolute nazi and piss off a bunch of confident amateurs that want to overengineer everything. If you can somehow avoid ending up with 20 other shit dependencies then React is a big upgrade over the frameworks that came before.
- leerob 5y ago
  Lee from Vercel (Next.js) – could you share some of things you feel you're working against the framework for? Open to any feedback. It's indeed a tricky balance between having lots of options vs. having the one "paved road" for everyone to take. Also, I like to think of Svelte as the successor to jQuery, as it's the closest to "just vanilla JavaScript" I've seen (yes, I know there's some non-standard JS syntax in there).
  - dmuso 5y ago
    Hey Lee, is there anything comprehensive you can point me to to diagnose performance problems in a next.js app? We have one and it’s brutally slow and I can’t seem to figure out the issue.
robocat 5y ago
Four eras of practice: 1. DHTML scripts: individual scripts that provided functionality e.g. a date picker. You grabbed the scripts, and wired them together on your pages to enhance your page. Includes the first generation of Ajax scripts (in page communication with the server, often using raw HTML, text, or XML). Hidden iframes and other techniques also used for server communications. 2. jQuery: the popular library that everyone used because it provided a fabulous API to access and modify the DOM, plus helper methods to abstract out browser differences and bug workarounds. Bringing Ajax to all web developers, allowing them to enhance the pages delivered by their backend web server of choice (PHP, RoR, etcetera). 3. component framework (Cambrian explosion): mostly enhance pages delivered by the server, each framework with a unique approach to its API. Pages use components designed for each framework. YUI, Dojo, jQuery UI, Mootools, ExtJS. Starting to see more Single Page Apps, but no widespread usage of any framework on large numbers of sites. 4. React (and other 2nd gen frameworks, mostly virtual DOM): fully component based, can easily deliver an SPA (Single Page Application) and often the server only really delivers JSON (no HTML pages except a blank container). Widespread usage of React in industry. There were plenty of early adopters for each technology, but as far as I recall, widespread usage follows the progression above. And the above ignores plenty of important first innovators and minor steps (for example, I used script.aculo.us). The first stunning example was back in 2000 which was Outlook Web Access on Internet Explorer 5: the first usage of XMLHttp and it was many years before anything else approached its sophistication as a (mostly?) single page app with complex updates. I presume it had a proprietary component system, and IE5 was enhanced to make it work smoothly.
- ngc248 5y ago
  This sums up the evolution properly, but one correction is that the component frameworks were there before jquery so 2 and 3 need to switch places. edit: ok looks like they were contemporaries
- jimmont 5y ago
  4 is from a decade ago. Perhaps consider what has happened since.
  - 5y ago
jimmont 5y ago
Entertaining, inaccurate article. Weak thesis. If this is the industry status quo, it's remarkable how little depth it has.
somishere 5y ago
My ecmascript/js journey switched tracks into framework land with backbone + requirejs circa 2010/11 .. Appreciate there was prior (and parallel) art, but for me that combo really presented a seismic shift in terms of seamless and integrated js application dev, ready for a post-flash/jquery/ie6-8/browser-hackfest world. I wouldn't dare comment on how far we've come since the early days of web scripting, or frameworks for that matter, but for all the talk of added complexity I'd sure say it feels a lot easier (and infinitely less hacky) these days.
734129837261 5y ago
I started out web-development in 2001 (recently worked for Apple as a senior front-end engineer), and to me the 4 eras of JavaScript are: 1. Form alerts and confirms 2. Ajax, jQuery, and plugins 3. Frameworks, from Handlebars to JSX 4. Revolution: TypeScript I remember a time when JavaScript simply wasn't used. Everything was server-side rendered (classic ASP using VB6.0, ancient PHP, Perl, etc.) Eventually it gradually became bigger but its development was stifled by Adobe Flash taking charge of highly interactive UIs. Then, slowly, JavaScript started to do things. Some companies started working with Ajax and suddenly you could talk to the server while you were on the client. But, for the longest of times, JavaScript was not used like it is today; we did not use it for templating or making components, because we had client-side XML and XSLT doing that with `<xsl:template>` and other such nifty tricks. XML + XSLT + Ajax + jQuery was the status-quo for many years before we started getting UI libraries. Backbone, Ember, MooTools, and many others started to make life as a front-end developer far more interesting. We went from HTML (and later also CSS) drones to actually needing to embrace programming concepts, architecture, design, and design principles. We had one big advantage over classically schooled university software engineering graduates: We knew JavaScript, it wasn't type-safe, it was full of little quirks, but it was ours and we had worked with it for many years. We knew it. They didn't. And then TypeScript was born. At first, it was a monstrosity full of bugs, oversights, missing features, lack of intuitive design, and largely undocumented and confusing. Front-end engineers like myself didn't like it, because WE did not need it. We just saw that those classically schooled professionals suddenly thought they could do front-end, too, except they didn't know about HTML semantics, HTML accessibility, CSS (from floats to flexbox to grid to paint/composite/layout), browser APIs, browser differences, and so much more. So these... people... came into our domain because TypeScript made them feel safe. They were far slower than us, they made more bugs, the code was unreadable (TypeScript generics are a hell, or in generally accepted TS-syntax: `T<G><A, H>(X<G>)<P><A><<A, B>, C>`) and worst of all, they made everything a `<div>`, including buttons and links and tables and lists and inputs and images. Then, as the years flew by, TypeScript became more mature (except for their error messages) and it actually became somewhat intuitive to use. The back-end developers who were confronted with the fact that they knew nothing about the front-end have now either adapted and learned, or left, and the world is nice again. The next big thing for web development and JavaScript is probably going to be the next big framework or library that we don't see coming yet. I love React, I enjoy Vue, I admire Svelte, but I don't think that React will stay around forever (libraries die because developers get bored of them, and new developers think these are getting too old), and Vue & Svelte simply haven't taken off the way I had hoped. We'll see where it takes us. In any case, I'll keep learning, I'll keep adapting, and I'm trying to be ahead of the hype train just so that I can keep increasing my $500,000 annual salary (excluding stock options).
lvl102 5y ago
I hate JavaScript and everything about it in 2022. The whole ecosystem stinks and the fact that it’s so pervasive makes me lose hope. I blame the whole thing on Microsoft and the IE team.
- dgb23 5y ago
  I think it fundamentally started out here: https://extensiblewebmanifesto.org/ https://extensiblewebmanifesto.org/ Very good ideas. If it was executed that way we would be in a different position. Some of the standards and browser implementations improved, many have been half baked or clunky, the JS ecosystem (which is the means to explore and extend) is chaotic and still moving incredibly fast without fundamental progress. I think two things happened since: We still don't agree on how to do interactive UI on the web and we've lost focus of this being a explorative journey that ultimately should result in agreed upon standards that everyone can build and rely on in the long term.
- francisofascii 5y ago
  Why is Microsoft and IE to blame?
avidphantasm 5y ago
This is a nice brief write-up, thank you. i It helps this non-full time web programmer contextualize recent changes, and lends credence to my decision to learn SvelteKit (skipping over the third gen view frameworks). I would have liked to see some discussion of what is next. For example, where does WebAssembly fit in? Lastly, a minor critique re.: > That said, I can’t write about what I didn’t experience Yes you can, it’s called historiography using primary and secondary sources. It’s a lot of work, but certainly doable, especially when so many of the participants of the history in question are still alive; you could interview them if need be. Thanks again for a nice high-level write-up.
natly 5y ago
Imagine how many decades of human lives were part of developing all this.
franciscop 5y ago
I've been longer (but not much), and in my time programming I believe the biggest difference was pre-jquery vs post-jquery. I use React nowadays, and the jump from jQuery to React was IMHO smaller than the massive improvement to life that was jumping from non-jquery to jquery. Specially when accounting for all the community libraries, you could just plug and play massive projects that would take you months otherwise.
mhitza 5y ago
My own frontend JavaScript progression path was: - "simple" JavaScript to implement fancy menus in the Macromedia Dreamweaver days (css :hover wasn't supported across browsers at the time, as I recall) - DHTML scripts copy pasted from these Hotscripts back in the day - backend frameworks that spit out HTML + JavaScript (Rails I think did this, as did symfony 1.x which was heavily inspired by Rails), at the time the library used underneath was PrototypeJS. Which then I used on many other projects (was never a fan on jQuery) - knockout.js, as my first "heavy" library I've used to SPAify complex pages - angular.js starting in 2013, then Angular (2+) on followup projects - Vue.js starting in 2020 - today, going back as much as possible to vanilla JavaScript The projects I've worked on avoided the mainstream libraries most of the time, and I definitely wish I would have gotten my time back for the time invested in angular.js/Angular, even if I learned those on the job. That's basically 5 different eras for me, and I'm circling back to the top.
- throw_m239339 5y ago
  > - today, going back as much as possible to vanilla JavaScript Javascript =/= the DOM. All your frameworks are DOM abstractions, not Javascript abstraction, unless you are using Typescript or Reason (or Turbo links on the server). You're still writing Javascript code with knockout and angular and co, you're just not using the DOM directly. Talking about "vanilla javascript" in the context of these frameworks never made sense to me. tangential: Javascript is not the DOM and people use frameworks because they hate DOM manipulation. We "didn't need jquery", or so someone said, but now it seems like we sure need all these frameworks somehow and people don't learn the DOM anymore. How is it any better than jQuery? it isn't...
  - TrickardRixx 5y ago
    I'm not sure I understand your point here. I would say I "hate writing javascript", but I think the point you're making is I "hate DOM manipulation". These days I use htmx[0] wherever possible. Notably htmx is still javascript; I just don't have to write it. htmx should still count as DOM manipulation and I love it. I just hate all the other methods of DOM manipulation that required me to write javascript. So what is the difference in the distinction you're making? [0] https://htmx.org/ https://htmx.org/
flappyeagle 5y ago
The one lesson of the past 2 decades that I’ve taken: do not adopt a JS framework for your production env. until it reaches industry-wide acceptance. It may end up fine but it has a good chance to be an expensive horror show. In my experience, only jQuery and React have obviously passed this bar.
- j45 5y ago
  I remember rolling the dice between Jquery and Sencha I believe. JQuery was very early but had a theme roller I was after to build in white labeling and branding. It also taught me if you pick something too new you might spend more time maintaining what has been built to date vs building new features and scaling them, which wasn’t always the experience.
  - flappyeagle 5y ago
    I used Sencha for a bit in a big corporate setting. Ahead of its time in many ways!
jmkni 5y ago
Interesting article, but weird that it basically ignores Angular2+, it's only mentioned once: > and rewriting them entirely, like Angular did with Angular 2, killed a ton of their community’s momentum. I don't think this is accurate, Angular may not be as popular amongst SV startups, but is still alive and well in more established businesses/enterprise. I don't think it's fair to write about the history of Javascript frameworks and completely gloss over one of the most widely used.
- outsidetheparty 5y ago
  It’s absolutely accurate; I made a pretty good living for a while there helping companies transition away from Angular after the framework got rewritten out from under them. Original Angular had some performance flaws that probably really did require a rewrite, but the decision to change so much syntax while they were at it caused an enormous number of people to abandon the platform. Current Angular still exists, sure, just like Ruby on Rails still exists, and they’re both solid and useful platforms; but industry wide it’s still accurate to think of them mostly in historical terms.
  - jmkni 5y ago
    Maybe this is different based on where you are, I'm in the UK and get emailed about different Angular contracts every few days, it's in use everywhere here.
- DrFell 5y ago
  Shh! Us Angular devs are working in obscurity on purpose. Have you seen the misinformation and library bloat that comes with popularity? Nothing to see here, go back to your React, kids.
Scarblac 5y ago
For me, one of the biggest revolutions was Babel. It made it possible for Javascript to change. Instead of being forced to write code that would run on all the supported browsers, with Babel we could actually use new features, and let it deal with translating them to stone age equivalents. That was huge.
jFriedensreich 5y ago
It seems the author just tried to force what he already knows from a few years of js development into a positivistic mental construct that tries to tell some skewed story that just feels off and wrong.
irrational 5y ago
> That said, I can’t write about what I didn’t experience. By the time I started writing frontend apps, there was a new generation of frameworks that had just started to reach maturity: Angular.js, Ember.js, Backbone, and more. Prior to these, the state of the art had been libraries like jQuery and MooTools. Well, crap. Now I feel super old. I’ve been using JS since the mid-90s and I did not expect this to start with “the era of jQuery is in the distant past”. I recently started using Cypress (automation testing framework) and was somewhat surprised to learn that it was using jQuery under the hood. And a few weeks ago I was reading the documentation for a very popular data table grid component and was surprised that it was still using jQuery under the hood too (and had all kinds of rationales as to why they didn’t think it necessary to rewrite the component without jQuery). I assumed jQuery would have faded into complete disuse by now.
mmcnl 5y ago
I really like the evolution of JS over the past two decades. I strongly believe the evolution of JS revolutionized the web in a positive way and significantly boosted innovation by lowering the costs for application development. For example, every corporate app these days is a web app, which is much easier to manager from an IT perspective than OS applications. Shipping working code at scale has never been easier. In my relatively short career I've seen consumers and organizations adopt innovative new applications at an accelerating rate because of this. Is it perfect? Definitely not. JS is so easy that it also makes it easy to write bad code. Higher-level languages also consume a lot more resources. Browsers become the defacto OS (good / bad?), etc. But in general I think JS has been revolutionary and the benefits far outweigh the costs from a functional perspective. As for the article: jQuery receives to little praise imo. At the time it was truly revolutionary. Suddenly you could make your websites interactive with just a few lines of code, and it worked in every browser! This inspired an entire generation of web developers.
- ozim 5y ago
  Not arguing that you are wrong but... I believe causality went other way around. Everyone started migrating to web applications so there was money in improving tooling. So push to web applications revolutionized JS tooling.
  - mmcnl 5y ago
    I don't think so. Angular and React are made by Google and Facebook. The Bootstrap CSS framework originated at Twitter. Chrome/WebKit were developed by Google and Apple. The V8 engine inspired NodeJS. Also there was this weird time period where every app suddenly had to be isomorphic, i.e. sharing the same codebase as the webapp with the native apps. I think a lot of the initial work to deliver code at scale had to be done by Big Tech to accommodate their hypergrowth in the early 2010s.
- justsomeuser 5y ago
  I still have the jQuery APIs memorised, it’s often easier and more concise than the standard web APIs.
hugs 5y ago
... searches article for "Express"... 0 results ... searches comments here for "Express"... 0 results ... goes back to writing Express apps...
- _fat_santa 5y ago
  I don't think express is mentioned often because it's mostly used as a straight backend language. Sure you could do SSR via Express but I've personally never seen it implemented like that.
progmetaldev 5y ago
I got my start in 2008 with Prototype and the effects library Scriptaculous (built on Prototype). Prototype would actually alter built-in JavaScript objects, which could cause problems if you introduced scripts not built with Prototype. It was still a breathe of fresh air compared to using vanilla JS back then, with all of the incompatibilities between browsers. Once jQuery was introduced, and decided to wrap objects rather than alter them, it really changed the way development was done. I still build all my web apps using progressive enhancement, and try to use static HTML as much as possible so apps still work without JS. It really doesn't take any extra time to build this way, and I separate my backend logic so I could easily move to a SPA if a client desired it (NOTE: most clients really don't care as long as it works, and they don't have to wait too long for page loads).
FpUser 5y ago
I've written real time (stock exchange like) web applications in the 90s using Java Applets (also ActiveX for IE browser). Before that I wrote even simpler one (no Applets or ActiveX) as it has relied on server push which was supported by Netscape browser only and it had a bit less functionality. On back end I just wrote custom webserver.
troysk 5y ago
So well written... Brought back memories. Thanks for the nostalgia!
yesimahuman 5y ago
This is missing the web component based frameworks like Stencil and Lit. Without those we’re missing a big part of the moment to framework-agnostic components and design systems and assembling these to build apps.
dehrmann 5y ago
It's weird that they frame the growth of web frameworks as a reaction to feature-rich mobile apps. > From the get go, mobile apps on iOS and Android were full applications written in Serious Languages™ like Objective C and Java...This [deeper integration] resulted a much better UX... > Doing all of that with JavaScript was seen as ludicrous at first. But as time went on, applications started to get more ambitious. Social networks added chat and DMs and other real-time features, Gmail and Google Docs... Desktop-similar Google Docs and Gmail predate smart phones. Meebo was running a desktop-like chat app in 2005. At the time, it felt ludicrous. Rich client-side web frameworks were already pretty far along by the time the App Store came out in 2008.
- deaddodo 5y ago
  On top of that, most of the techniques that mobile apps leverage today were developed for web apps of old. REST + JSON was built as a lightweight data transmission option for Ajax/XmlHttpRequest versus transmitting HTML over the line. Component-based/Reactive UX came about because of the unknowability and variability over browser windows. Asynchronous development paradigms came to prominence due to the high latency of frontend<->backend apps combined with fault-intolerance assumptions. Etc.
matthoiland 5y ago
Era 1: Nobody knows what they're doing Era 2: Everyone uses jQuery Era 3: Everyone copies Gmail and Grooveshark using Backbone and Angular Era 4: React is all the hipster bootcamps teach Era 5: NextJS and React Native is how you build apps
cosmotic 5y ago
I still use jQuery. Code is maintainable and theres no frustrating, inconsistent, security-fraught, frequent-breaking-changes NPM situation. I have maybe two dependencies instead of literally thousands. Pages load fast and the foundation I'm building on isn't moving faster than I can build.
jpcapdevila 5y ago
Very nice trip down memory lane! My experience was very similar. For me the next step, the fifth era if you will, is javascript that manages the persisted distributed state for you without any backend or db specific API. You push something into an array and it is magically there for another user in the other side of the world. I'm working on something like that: https://javascriptdb.com https://javascriptdb.com
oaiey 5y ago
> I don’t think React invented components, but to be honest I’m not quite sure where they first came from. I know there’s prior art going back to at least XAML in .NET, and web components were also beginning to develop as a spec around then. He started programming in 2012. He does not know the 90s. Good for him. Honestly, I have no idea how long back components go ... my educated guess: Smalltalk? Minimum.
eBombzor 5y ago
It's funny to see this person loving SSR and then have another who says it's the devil https://gist.github.com/Widdershin/98fd4f0e416e8eb2906d11fd1da62984 https://gist.github.com/Widdershin/98fd4f0e416e8eb2906d11fd1...
racl101 5y ago
jQuery should be its own era. The impact of that framework cannot be understated.

284 points by RafelMri 5y ago

Of the modern front-end frameworks: What is the best framework to add some front-end interactivity to a existing server-side-rendered application (Flask, Ruby on Rails etc.), without going all SPA?

robertwt7 5y ago

There’s a redwoodjs as well for the fullstack which I feel like using laravel / django when using it. Battery included framework

k__ 5y ago

A bit of history revisionism, haha ExtJS, Ember, Angular, and Next are all "full-stack" frameworks and the all were released at very different times. I would say the "eras" were more like: Direct manipilation with custom architecture and models (JQuery) -> MVC/P (Ember/ExtJS/Angular) -> Components (React/Vue).

magnio 5y ago
That's how the article delineates it too. The term "Full-stack Frameworks" for the fourth era is a bit confusing: what the article means is the battery-included wrappers for popular component libraries like Next.js, Remix (React) or Nuxt.js (Vue) and not just any full-stack framework per se.
deleted 5y ago
[deleted]
Tade0 5y ago
+the next generation: "compiler-frameworks"(or "UI compilers"). Overall this division seems weird. SSR is neither a revolution, nor universally desirable. The real revolution is in what these next-generation frameworks like Svelte or SolidJS offer: small bundles combined with high performance achieved through eschewing virtual DOM in favour of precise changes in the DOM.
- josephg 5y ago
  Yep. SSR has been around for ages. The very first "web frameworks" were pure SSR. And by that I'm referring to PHP and the old CGI! The big leap forward from Solidjs and Svelte is that they do complex source-to-source compilation to avoid virtual dom diffing. That approach lets them get the best of both worlds - the programmer can pretend their components are pure & reactive. (Solidjs looks almost identical to react.) Thats great because it means there's no bugs due to fiddly or forgotten DOM updating. But the javascript executed by the browser doesn't need any of react's complexity. The JS output by the compiler simply makes direct DOM manipulation calls when content changes. There's no heavy re-rendering of view trees, and no virtual dom to track. Unlike react, you don't need to apologize for mutating variables or re-render your entire page when you do. So we can do away with redux and all of that. A hello world app in solid or svelte is a few kilobytes, compared to 200kb+ for a react project. And it renders instantly. It took us a few years to get here, but I'm delighted by the direction UI code in the browser is headed. I hope these ideas make it into native applications.
  - Tade0 5y ago
    Also let's not forget about something that hasn't been the case over a decade now: the stack is readable again. I've found bugs in my Svelte code just by looking at the stack.
  - fabiospampinato 5y ago
    Actually that's just a common misconception, which I believed too. The complex compile-time transforms enable almost no performance improvements. As a proof just take a look at the js-framework-benchmark table [0], my framework (Voby [1]) is faster than both in the benchmark despite having an API very similar to Solid and no requirement for a Babel transform or other compile-time transform (though the basic React-like JSX transform is supported for convenience). Those transforms actually exist 99% just for providing some convenience features to the developer. If that weren't the case it wouldn't be possible to make something similar without a transform that's faster than both. In fact Svelte is actually quite a bit slower than both Voby and Solid. Svelte is even slower than Inferno, which is a (very optimized) V-DOM framework. [0]: https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht... [1]: https://github.com/fabiospampinato/voby/ https://github.com/fabiospampinato/voby/
pzuraq 5y ago
By "full-stack" here I mean frameworks which handle both the frontend and backend simultaneously, in a seamless way. The closest thing framework that I remember from the MVC/P era which attempted this was Meteor.js, but it was really horrendous to use in my experience. Otherwise, it was very common practice to serve an Ember or Angular app as static files Nginx or directly on a CDN. Wrapping them in a server-side framework was always a bespoke process which required you to effectively maintain two frameworks, and stitch them together yourself (unless you count Ember + Rails in the early days, but even that is a stretch IMO). When SSR was introduced in any framework, it was usually not used to its full potential to be able to accomplish the use cases I discuss in the post, like authentication, API endpoints, etc. It was just used to render the app on the server. It did not fundamentally change the DX of the framework. I honestly was pretty skeptical of these latest frameworks until I gave them a shot! It doesn't sound that revolutionary until you actually start using them, and things which were previously quite difficult become absolutely trivial. I highly recommend trying them out some time.
mrits 5y ago
I'd say JQuery and ExJS were part of the same era. JQuery was used by a lot of people that didn't embrace javascript at all and tried to not use it (e.g ASP.NET coders) I feel like backbone deserves its own era as it seemed like all the cool kids would exclusively use that for a couple years. Then Angular and a ton of others flooded the scene.

mg 5y ago

I wonder if I will ever use a JavaScript framework. My projects are usually either in the form of "User enters data, sends it to the server, server sends a new page back" Example: https://www.gnoosic.com/faves https://www.gnoosic.com/faves Or in the form of "User changes parameters on screen, Javascript updates the screen accordingly". Example: https://www.productchart.com/laptops https://www.productchart.com/laptops In both cases, I don't see the benefit I would get from a framework. If you have built a project that is public and benefits from using a framework, I would love to see it!

hnlmorg 5y ago
I never use frameworks either. In fact the last site I published didn't have any Javascript at all (it's just a static site so shouldn't need it yet that doesn't seem to stop most other sites from abusive amounts of JS).
aurora72 5y ago
gnoosic.com/faves is cool but the Allmusic.com's related artists section is the ultimate place to discover new bands.
vmception 5y ago
Sure, probably works, just don't complain about age discrimination when you bring up nonconsensus things that have been superseded, and the team isnt fond of that system design
throwaway77384 5y ago
I also started out without frameworks and still prefer to work that way. However, I have found them to come in handy when solo-ing projects that require: - transpiling JS back into the stone age for compatibility - accessibility - seamless localisation I have found I just can't keep track of all of these things as well as React does. At the same time, I think React is a huge, dependency-laden mess, very difficult to learn (because it's changed its mind on how to do things about 100x, so no responses to issues on SO apply to your version of React, Redux, React Router, etc), slow as hell and probably overkill for most projects...
5y ago

block_dagger 5y ago

The company I work at wastes millions of dollars on maintaining a complex React frontend for no technical reason whatsoever. It amazes me.

bnt 5y ago
My previous 2 companies basically lost all marketshare because they _had to_ use Node + React for their in-house CRUD tools. The amount of time and money wasted is insane. We ended up doing most things with Airtable because the dev team(s) were too slow.
klabb3 5y ago
What you talking? I don't particularly endorse react but what are you comparing to? If we're talking plain js or jquery style dom manipulation react, or any of its competitor, is a vastly superior for any non-trivial app. If you're having a mostly static site I can believe you though.
- dsego 5y ago
  Probably to simple server-side frameworks. Most web apps are based on navigation and forms, which can be done simpler with classic server-side MVC and some JS plugins for the more interactive parts. No need for client-side routing, solidifying HTTP API endpoints or duplicating data models & logic on the front-end.
- likortera 5y ago
  Something like Laravel + alpinejs running on heroku or Google app Engine or a similar platform is what 90% of the typical crud saas webapps most of us build need. But we definitely have more fun with React SPAs and Go microservices on Kubernetes :) (Notice I'm listing the shinny toys of the usual 3 layers at every company)

maelmori 5y ago

I still remember the day I discovered Dan Steinman's Dynamic Duo Javascript library. It allowed me to do effects that I thought were reserved only for flash or java embedded applets. That was in late 1999, probably while I was struggeling to make a crappy script copied from dynamicdrive.com work in Netscape 4. Tell me about eras!!

rob74 5y ago
The "Before Era" mentioned in the article can probably be subdivided further - it casually mentions that back then, "the most common thing you would do was include jQuery, throw together some scripts for a few UI widgets, and call it a day". However that was only possible after jQuery was released in 2006. Before that were the real "dark ages" of JS development, with primitive libraries, even more primitive dev tools in the browser (Firebug was also only released in 2006, and Chrome was the first browser to have integrated dev tools in 2008) and stuff like "be careful with console.log in IE, because it will crash your script unless the console is actually visible".
- deaddodo 5y ago
  jQuery didn't even incept that, prototype.js did. Prototype is probably the first real jS library that moved the language (along with Dojo, Mochi, etc) from scriplets ("DHTML") to actual UI interactivity. That + XMLHttpRequest ("Ajax") were the direct progenitors to jQuery, which was used to bootstrap or complement all of the early "frameworks".
  - dpcx 5y ago
    I came here looking for this comment; it seems prototype is always forgotten about as part of the "before frameworks" discussion. I remember bringing up using prototype to my coworkers in 2006/2007 (the director was a stickler for having clickable buttons that had a specific width on the left and right of the text, so I proposed using prototype to set that automatically). I recall my coworkers being mostly confounded by it and how to use it.
- andrewl-hn 5y ago

skybrian 5y ago

Probably should mention GWT in the "before times" somewhere, back when crazy things had to be done to work around IE bugs.

deleted 5y ago

[deleted]

Gunmeister 5y ago

Nice article. My JavaScript framework of choice is Meteor written in React.

anonyfox 5y ago
I second this

Kiro 5y ago

Can someone explain what Next.js actually is and why it's so popular? "hybrid static & server rendering" is their main USP but that seems... very minor. In all my single-page applications I always fetch the data from a separate backend so SSR has never clicked for me. This page is the first time I've heard it explained as a full-stack framework, which sounds more intriguing than just helping me with SSR.

BigJono 5y ago
It implements some patterns for rendering in both environments using the same code. The main problem with rendering in both the client and server environments using the same code is that you need to fetch data in two different places. On the server your code needs to fetch data during the render itself, whereas on the client you need to fetch data asynchronously then re-render with the data once it arrives (which in React means triggering the API call as a side effect, then setting the returned data as state, triggering a re-render). Unless you really need server side rendering and can't do it statically, Next.js is the wrong choice. IME like 98% of projects are just using it because the tech lead is resume padding or an idiot. The others are something similar to Reddit or Quora with a complex UI and dynamic data that needs to perform well on SEO. For those ones Next is probably a pretty good choice. Stuff like Next should be the 3rd tool in your arsenal after client and static rendering. It's a bunch of extra complexity for very little gain in most cases.
- leerob 5y ago
  > The main problem with rendering in both the client and server environments using the same code is that you need to fetch data in two different places. `getStaticProps` and `getServerSideProps` _only_ run on the server – it's possible we're conflating "rendering" with "data fetching" here. You fetch the data on the server, and send pre-rendered HTML to the browser. You can, of course, also do client-side data fetching (e.g. `useEffect`) as you mentioned. > Stuff like Next should be the 3rd tool in your arsenal after client and static rendering. The philosophy of Next.js is that client, static rendering, _and_ server rendering have a place. For certain application holotypes, you might want all static. For others, all server-rendered. Next.js doesn't care - it allows you to choose which strategy you want on a per-page (e.g. route) basis. This allows you to not have to eject from the framework because your /contact pages wants to be static, while the /dashboard part of your site is server or client rendered. It also helps for incremental adoption.

jmillikin 5y ago

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

kolme 5y ago

There's a framework that always seems to get forgotten, but was there before Backbone, Angular and others: the Dojo Toolkit [1], released in 2005, it had some goodies like built-in tooling (that was hell to work with) and modules (in 2005 they were godsend!) with RequireJS. We chose it in my company in 2008 before the framework boom and it had served us well for a very long time. It's batteries included, has for example it has a very comprehensive i10n module, which was not usual at the time. Also worth mentioning it was started among others by Alex Russell [2], a famous developer advocate at Google. [1] https://en.wikipedia.org/wiki/Dojo_Toolkit https://en.wikipedia.org/wiki/Dojo_Toolkit [2] https://infrequently.org/ https://infrequently.org/

lewisjoe 5y ago

Where we will go from here, is pretty obvious. Now that we've realized SSRs cannot be an optional afterthought, we'll soon realize SSRs with running JS on the server is a nightmare to scale - https://engineeringblog.yelp.com/2022/02/server-side-rendering-at-scale.html https://engineeringblog.yelp.com/2022/02/server-side-renderi... Just search HN for "scaling server side rendering" and you'll land on a bunch of practical complications. That doesn't mean SSR is bad. It just means we know the solution but stuck with the wrong tools. My hypothesis is that we'll capitalize WebAssembly to run our UI rendering logic and a tiny platform-specific rendering layer to translate rendering commands from WASM to platform. Interesting side-benefit: Language choices other than Javascript. I've already started working on a proof-of-concept React-ish library that runs on a WASM VM. IT lets you specify your UI component declaration and behaviour in Kotlin - https://github.com/joelewis/kwasm https://github.com/joelewis/kwasm

genezeta 5y ago

In Spanish there's a saying that goes "Cada uno habla de la feria según le va en ella". It means that everyone tells their story, that they say the fair went well or not depending on how it went for them. Another comment talks about revisionism and, while I think it is a valid critique, I think it goes beyond that. The author's career starts in 2012 and that's all the reference they seem to use. Sure, they admit they will "probably going to gloss over a lot" and that they "can’t write about what [they] didn’t experience". But then... is this fair? Or, a better question -since anyone can write whatever they want, of course-, will this be, then, just some person's story or will it actually be representative or a larger reality? Sadly, it feels like lately a lot of people seem intent in blurring that distinction. They seem to say "I may only have a limited view, but I'm going to present this as if this was the complete reality". And this is what this article does, I'm afraid. The fact that there's is absolutely no mention at all of Dojo is telling. It's also quite telling that dismissing claim of "throw together some scripts for a few UI widgets, and call it a day", the quite absurd "everything was global", and the error of suggesting XHR came later -"As time went on and XHR was introduced and popularized"-.

pzuraq 5y ago
I actually have a friend who wrote in Dojo, so was aware of its existence, but had no idea it was so influential/early in the First Frameworks era. Same with GWT/Closure, as has been mentioned by others. I did run this article by some mentors who have been in the industry since the 90s before posting, as I wanted to make sure I didn't gloss over it entirely, but unfortunately it seems they didn't experience those either. And I think that's the core of the issue, even people who were around at that time do not remember all of these things. Ultimately, even those of us who are trying our best are going to miss details, and this is only going to get worse as we get further and further away from the beginning. Honestly it seems like this is a job for historians, and unfortunately I am not one, just a dev trying to share my thoughts and experience > and the error of suggesting XHR came later According to Wikipedia, XHR was introduced in 1999, 4 years after JS was introduced: https://en.wikipedia.org/wiki/XMLHttpRequest https://en.wikipedia.org/wiki/XMLHttpRequest
- 5y ago

kh_hk 5y ago

For me 2012 was the year I stopped any frontend work at all. As I remember, things felt very easy and natural when all I had to do was output html using templates, write CSS and add some touches of javascript here and there, either using jquery or mootools. Maybe a websocket to display something coming from a process. Then there was backbone, history push state, more frameworks, client side rendering, meteor, and a lot of impressive stuff. Very impressive stuff that felt needlessly complicated and made me procrastinate every time I tried to learn it. Nowadays, every time I look at a react codebase I feel certain emotions I can only describe as disgust. Maybe I have only seen bad codebases.

wildrhythms 5y ago
Not sure what you find 'disgusting' about a function that returns HTML; if anything it is more 'natural' than the templating and jQuery amalgamations of the past.
brailsafe 5y ago
I don't think you're alone. I felt the same way about overcomplexity until I had a few runs at working on already established complex frontend codebases. What seemed to happen around 2008 onward is that the basic principles of the web were sort of simple, but then to do anything at a larger scale it got pretty crazy quite quickly, and so new architecture ideas came along to address that by people who were in the business of solving engineering type architecture problems. For any site of inherently simple interactivity, it's always been as easy if not easier than it ever has, but now it's also more manageable if you know you're going to need to scale a certain way. It doesn't necessarily take all that much before you can start to see the reasoning. For example, take a humble grid of products, each with their own add to wishlist button, and a profile preview button in the corner of the page that indicates how many things are on your wishlist. Pretty simple to handle, render the thumbnails with unique ids and make an XHR request that stores the data with your account. Update the wishlist total count however you would. Now suppose though that each thumbnail in the grid can open a bigger preview dialog that has more images, a bigger description, and it's own add to wishlist button. You can click that button, and it does the same thing. You close the dialog, but now your grid item needs to reflect that it's already been added to the wishlist. These things get really tiresome to keep building, something that I'm sure isn't new to you if as you say, you've been in software a while. Sorry for the book, I mostly wrote that to challenge myself to think it through, not to imply you couldn't think of how it would be necessary to componentize things. I'm not particularly fond of React more than Vue or anything, except for the fact that they both allow you to define UI as collections of functional state machines when it's necessary to do so.

marcus_cemes 5y ago

I'm in love with the design of that website. It's clean, there are subtle graphic changes such as the pixel art that changes when you toggle the light switch, a really fantastic job there (one small remark, hovering over the pixel art on Chrome makes a scroll bar appear due to the transform). I want one. It's also proof that you can make a simple and pleasant experience with a JS framework, if you focus on the essentials, there's no need to boycott JS entirely in favour of the old web, these frameworks get rid of a lot of the boilerplate when starting from scratch. I'm an avid supporter of SvelteKit (the framework used on that website) and how they want to make the web less SPA/JS again. In this example, navigation is fast and client side, but can fall back to SSR if JavaScript is disabled, fails to load or hasn't loaded yet. There is no heavy runtime with virtual DOM diffing. Resources are cached and a page reload only sends ~17 kB over the wire on a large blog post, showing an excellent use of Tailwind CSS. It renders on Cloudflare Workers close to the user wherever you are in the world, with zero vendor lock-in if you want to stick it on a VPS.

fruit2020 5y ago
Why do people mention so often about js being disabled? It’s such an insignificant use case imho. Ssr(in js world) is mostly for public pages who get scanned by search bots, right?
- rossvor 5y ago
  Probably because people who browse with js (mostly) disabled are over-represented on HN. So for us it is a significant use case.
- likortera 5y ago
  Can't agree more with you. In my more than 20 years in this industry I'm still to find one single person at work, or a single customer with JavaScript disabled. At this point if you have JavaScript disabled is your problem. It's like having a car and not wanting to put gas on it and pushing it around and complaining why you have to push your car. Not saying we don't abuse its usage, but having it disables is just extremist
- 5y ago

mattlondon 5y ago

I would be very keen to know if there are any of these "full-stack" frameworks that don't depend on NPM, or more specifically built with Deno or vanilla JS in mind? It feels like (to me at least) that at this stage it is quite clear that using NPM is an anti-pattern that is best avoided if possible (security, requiring a "dev machine" with the right version of NPM installed etc, general bloat) I know that there is nanojsx (https://deno.land/x/nano_jsx https://deno.land/x/nano_jsx) but would be keen to know of any other examples that anyone knows of?

_fat_santa 5y ago
> It feels like (to me at least) that at this stage it is quite clear that using NPM is an anti-pattern that is best avoided if possible (security, requiring a "dev machine" with the right version of NPM installed etc, general bloat) For all it's problems, it's still is the killer feature that makes it easy to develop JS apps. The things you mentioned can be mitigated with proper practices. 1. Security: Supply chain attacks can be mitigated through being deliberate about versions and making sure your CI systems always install a "frozen lockfile" 2. Requiring the "right" version of NPM: Can be easily solved through "engines" in package.json. You can basically tell your project to not run unless the dev has the right version of NPM. This is not that big of a deal since a dev can just install the correct version with npm. You can take this a step further with yarn and pin a specific binary in your project so it doesn't matter what version your devs are running, they will automatically use the binary you specified inside the project. 3. Performance and Bloat: Besides NPM, there's also Yarn and PNPM (Performance NPM) that both work much faster than NPM and are fully interoperable with existing package.json's. The ecosystem is still not perfect and security is still the biggest issue. The other issues you mentioned though can be easily mitigated through good practices.

numlock86 5y ago

Personally I think we already exceeded the sweet spot. Things like jQuery were merely abstractions and shortcuts, but didn't bring much to the table. In the end you had to do all the work. On the other end things like Next.js do so many things up to a point at which you start working against them to achieve certain things whilst ending up not using 80% of the framework because they are aimed at basically every possible case without being really specialized. It's mostly about accessibility these days, like getting started fast. While I don't quite agree with the clustering and categorization (as already mentioned by other comments), for me it feels like the ideal point was somewhere between era two (Knockout) and three (Vue, React), with a tendency to the second era.

BigJono 5y ago
The sweet spot is still there, in theory. React itself is just a few functions forming a very simple (but not necessarily intuitive) abstraction. The issue is the community is batshit and it's almost impossible to find or build a team that's going to democratically decide to use a sensible approach. If you want to keep a simple codebase on a React project your three options are build the entire thing yourself, be the best interviewer of all time and find a one in a million team, or be willing to be an absolute nazi and piss off a bunch of confident amateurs that want to overengineer everything. If you can somehow avoid ending up with 20 other shit dependencies then React is a big upgrade over the frameworks that came before.
leerob 5y ago
Lee from Vercel (Next.js) – could you share some of things you feel you're working against the framework for? Open to any feedback. It's indeed a tricky balance between having lots of options vs. having the one "paved road" for everyone to take. Also, I like to think of Svelte as the successor to jQuery, as it's the closest to "just vanilla JavaScript" I've seen (yes, I know there's some non-standard JS syntax in there).
- dmuso 5y ago
  Hey Lee, is there anything comprehensive you can point me to to diagnose performance problems in a next.js app? We have one and it’s brutally slow and I can’t seem to figure out the issue.

robocat 5y ago

Four eras of practice: 1. DHTML scripts: individual scripts that provided functionality e.g. a date picker. You grabbed the scripts, and wired them together on your pages to enhance your page. Includes the first generation of Ajax scripts (in page communication with the server, often using raw HTML, text, or XML). Hidden iframes and other techniques also used for server communications. 2. jQuery: the popular library that everyone used because it provided a fabulous API to access and modify the DOM, plus helper methods to abstract out browser differences and bug workarounds. Bringing Ajax to all web developers, allowing them to enhance the pages delivered by their backend web server of choice (PHP, RoR, etcetera). 3. component framework (Cambrian explosion): mostly enhance pages delivered by the server, each framework with a unique approach to its API. Pages use components designed for each framework. YUI, Dojo, jQuery UI, Mootools, ExtJS. Starting to see more Single Page Apps, but no widespread usage of any framework on large numbers of sites. 4. React (and other 2nd gen frameworks, mostly virtual DOM): fully component based, can easily deliver an SPA (Single Page Application) and often the server only really delivers JSON (no HTML pages except a blank container). Widespread usage of React in industry. There were plenty of early adopters for each technology, but as far as I recall, widespread usage follows the progression above. And the above ignores plenty of important first innovators and minor steps (for example, I used script.aculo.us). The first stunning example was back in 2000 which was Outlook Web Access on Internet Explorer 5: the first usage of XMLHttp and it was many years before anything else approached its sophistication as a (mostly?) single page app with complex updates. I presume it had a proprietary component system, and IE5 was enhanced to make it work smoothly.

ngc248 5y ago
This sums up the evolution properly, but one correction is that the component frameworks were there before jquery so 2 and 3 need to switch places. edit: ok looks like they were contemporaries
jimmont 5y ago
4 is from a decade ago. Perhaps consider what has happened since.
- 5y ago

jimmont 5y ago

Entertaining, inaccurate article. Weak thesis. If this is the industry status quo, it's remarkable how little depth it has.

somishere 5y ago

My ecmascript/js journey switched tracks into framework land with backbone + requirejs circa 2010/11 .. Appreciate there was prior (and parallel) art, but for me that combo really presented a seismic shift in terms of seamless and integrated js application dev, ready for a post-flash/jquery/ie6-8/browser-hackfest world. I wouldn't dare comment on how far we've come since the early days of web scripting, or frameworks for that matter, but for all the talk of added complexity I'd sure say it feels a lot easier (and infinitely less hacky) these days.

734129837261 5y ago

I started out web-development in 2001 (recently worked for Apple as a senior front-end engineer), and to me the 4 eras of JavaScript are: 1. Form alerts and confirms 2. Ajax, jQuery, and plugins 3. Frameworks, from Handlebars to JSX 4. Revolution: TypeScript I remember a time when JavaScript simply wasn't used. Everything was server-side rendered (classic ASP using VB6.0, ancient PHP, Perl, etc.) Eventually it gradually became bigger but its development was stifled by Adobe Flash taking charge of highly interactive UIs. Then, slowly, JavaScript started to do things. Some companies started working with Ajax and suddenly you could talk to the server while you were on the client. But, for the longest of times, JavaScript was not used like it is today; we did not use it for templating or making components, because we had client-side XML and XSLT doing that with `<xsl:template>` and other such nifty tricks. XML + XSLT + Ajax + jQuery was the status-quo for many years before we started getting UI libraries. Backbone, Ember, MooTools, and many others started to make life as a front-end developer far more interesting. We went from HTML (and later also CSS) drones to actually needing to embrace programming concepts, architecture, design, and design principles. We had one big advantage over classically schooled university software engineering graduates: We knew JavaScript, it wasn't type-safe, it was full of little quirks, but it was ours and we had worked with it for many years. We knew it. They didn't. And then TypeScript was born. At first, it was a monstrosity full of bugs, oversights, missing features, lack of intuitive design, and largely undocumented and confusing. Front-end engineers like myself didn't like it, because WE did not need it. We just saw that those classically schooled professionals suddenly thought they could do front-end, too, except they didn't know about HTML semantics, HTML accessibility, CSS (from floats to flexbox to grid to paint/composite/layout), browser APIs, browser differences, and so much more. So these... people... came into our domain because TypeScript made them feel safe. They were far slower than us, they made more bugs, the code was unreadable (TypeScript generics are a hell, or in generally accepted TS-syntax: `T<G><A, H>(X<G>)<P><A><<A, B>, C>`) and worst of all, they made everything a `<div>`, including buttons and links and tables and lists and inputs and images. Then, as the years flew by, TypeScript became more mature (except for their error messages) and it actually became somewhat intuitive to use. The back-end developers who were confronted with the fact that they knew nothing about the front-end have now either adapted and learned, or left, and the world is nice again. The next big thing for web development and JavaScript is probably going to be the next big framework or library that we don't see coming yet. I love React, I enjoy Vue, I admire Svelte, but I don't think that React will stay around forever (libraries die because developers get bored of them, and new developers think these are getting too old), and Vue & Svelte simply haven't taken off the way I had hoped. We'll see where it takes us. In any case, I'll keep learning, I'll keep adapting, and I'm trying to be ahead of the hype train just so that I can keep increasing my $500,000 annual salary (excluding stock options).

lvl102 5y ago

I hate JavaScript and everything about it in 2022. The whole ecosystem stinks and the fact that it’s so pervasive makes me lose hope. I blame the whole thing on Microsoft and the IE team.

dgb23 5y ago
I think it fundamentally started out here: https://extensiblewebmanifesto.org/ https://extensiblewebmanifesto.org/ Very good ideas. If it was executed that way we would be in a different position. Some of the standards and browser implementations improved, many have been half baked or clunky, the JS ecosystem (which is the means to explore and extend) is chaotic and still moving incredibly fast without fundamental progress. I think two things happened since: We still don't agree on how to do interactive UI on the web and we've lost focus of this being a explorative journey that ultimately should result in agreed upon standards that everyone can build and rely on in the long term.
francisofascii 5y ago
Why is Microsoft and IE to blame?

avidphantasm 5y ago

This is a nice brief write-up, thank you. i It helps this non-full time web programmer contextualize recent changes, and lends credence to my decision to learn SvelteKit (skipping over the third gen view frameworks). I would have liked to see some discussion of what is next. For example, where does WebAssembly fit in? Lastly, a minor critique re.: > That said, I can’t write about what I didn’t experience Yes you can, it’s called historiography using primary and secondary sources. It’s a lot of work, but certainly doable, especially when so many of the participants of the history in question are still alive; you could interview them if need be. Thanks again for a nice high-level write-up.

natly 5y ago

Imagine how many decades of human lives were part of developing all this.

franciscop 5y ago

I've been longer (but not much), and in my time programming I believe the biggest difference was pre-jquery vs post-jquery. I use React nowadays, and the jump from jQuery to React was IMHO smaller than the massive improvement to life that was jumping from non-jquery to jquery. Specially when accounting for all the community libraries, you could just plug and play massive projects that would take you months otherwise.

mhitza 5y ago

My own frontend JavaScript progression path was: - "simple" JavaScript to implement fancy menus in the Macromedia Dreamweaver days (css :hover wasn't supported across browsers at the time, as I recall) - DHTML scripts copy pasted from these Hotscripts back in the day - backend frameworks that spit out HTML + JavaScript (Rails I think did this, as did symfony 1.x which was heavily inspired by Rails), at the time the library used underneath was PrototypeJS. Which then I used on many other projects (was never a fan on jQuery) - knockout.js, as my first "heavy" library I've used to SPAify complex pages - angular.js starting in 2013, then Angular (2+) on followup projects - Vue.js starting in 2020 - today, going back as much as possible to vanilla JavaScript The projects I've worked on avoided the mainstream libraries most of the time, and I definitely wish I would have gotten my time back for the time invested in angular.js/Angular, even if I learned those on the job. That's basically 5 different eras for me, and I'm circling back to the top.

throw_m239339 5y ago
> - today, going back as much as possible to vanilla JavaScript Javascript =/= the DOM. All your frameworks are DOM abstractions, not Javascript abstraction, unless you are using Typescript or Reason (or Turbo links on the server). You're still writing Javascript code with knockout and angular and co, you're just not using the DOM directly. Talking about "vanilla javascript" in the context of these frameworks never made sense to me. tangential: Javascript is not the DOM and people use frameworks because they hate DOM manipulation. We "didn't need jquery", or so someone said, but now it seems like we sure need all these frameworks somehow and people don't learn the DOM anymore. How is it any better than jQuery? it isn't...
- TrickardRixx 5y ago
  I'm not sure I understand your point here. I would say I "hate writing javascript", but I think the point you're making is I "hate DOM manipulation". These days I use htmx[0] wherever possible. Notably htmx is still javascript; I just don't have to write it. htmx should still count as DOM manipulation and I love it. I just hate all the other methods of DOM manipulation that required me to write javascript. So what is the difference in the distinction you're making? [0] https://htmx.org/ https://htmx.org/

flappyeagle 5y ago

The one lesson of the past 2 decades that I’ve taken: do not adopt a JS framework for your production env. until it reaches industry-wide acceptance. It may end up fine but it has a good chance to be an expensive horror show. In my experience, only jQuery and React have obviously passed this bar.

j45 5y ago
I remember rolling the dice between Jquery and Sencha I believe. JQuery was very early but had a theme roller I was after to build in white labeling and branding. It also taught me if you pick something too new you might spend more time maintaining what has been built to date vs building new features and scaling them, which wasn’t always the experience.
- flappyeagle 5y ago
  I used Sencha for a bit in a big corporate setting. Ahead of its time in many ways!

jmkni 5y ago

Interesting article, but weird that it basically ignores Angular2+, it's only mentioned once: > and rewriting them entirely, like Angular did with Angular 2, killed a ton of their community’s momentum. I don't think this is accurate, Angular may not be as popular amongst SV startups, but is still alive and well in more established businesses/enterprise. I don't think it's fair to write about the history of Javascript frameworks and completely gloss over one of the most widely used.

outsidetheparty 5y ago
It’s absolutely accurate; I made a pretty good living for a while there helping companies transition away from Angular after the framework got rewritten out from under them. Original Angular had some performance flaws that probably really did require a rewrite, but the decision to change so much syntax while they were at it caused an enormous number of people to abandon the platform. Current Angular still exists, sure, just like Ruby on Rails still exists, and they’re both solid and useful platforms; but industry wide it’s still accurate to think of them mostly in historical terms.
- jmkni 5y ago
  Maybe this is different based on where you are, I'm in the UK and get emailed about different Angular contracts every few days, it's in use everywhere here.
DrFell 5y ago
Shh! Us Angular devs are working in obscurity on purpose. Have you seen the misinformation and library bloat that comes with popularity? Nothing to see here, go back to your React, kids.

Scarblac 5y ago

For me, one of the biggest revolutions was Babel. It made it possible for Javascript to change. Instead of being forced to write code that would run on all the supported browsers, with Babel we could actually use new features, and let it deal with translating them to stone age equivalents. That was huge.

jFriedensreich 5y ago

It seems the author just tried to force what he already knows from a few years of js development into a positivistic mental construct that tries to tell some skewed story that just feels off and wrong.

irrational 5y ago

> That said, I can’t write about what I didn’t experience. By the time I started writing frontend apps, there was a new generation of frameworks that had just started to reach maturity: Angular.js, Ember.js, Backbone, and more. Prior to these, the state of the art had been libraries like jQuery and MooTools. Well, crap. Now I feel super old. I’ve been using JS since the mid-90s and I did not expect this to start with “the era of jQuery is in the distant past”. I recently started using Cypress (automation testing framework) and was somewhat surprised to learn that it was using jQuery under the hood. And a few weeks ago I was reading the documentation for a very popular data table grid component and was surprised that it was still using jQuery under the hood too (and had all kinds of rationales as to why they didn’t think it necessary to rewrite the component without jQuery). I assumed jQuery would have faded into complete disuse by now.

mmcnl 5y ago

I really like the evolution of JS over the past two decades. I strongly believe the evolution of JS revolutionized the web in a positive way and significantly boosted innovation by lowering the costs for application development. For example, every corporate app these days is a web app, which is much easier to manager from an IT perspective than OS applications. Shipping working code at scale has never been easier. In my relatively short career I've seen consumers and organizations adopt innovative new applications at an accelerating rate because of this. Is it perfect? Definitely not. JS is so easy that it also makes it easy to write bad code. Higher-level languages also consume a lot more resources. Browsers become the defacto OS (good / bad?), etc. But in general I think JS has been revolutionary and the benefits far outweigh the costs from a functional perspective. As for the article: jQuery receives to little praise imo. At the time it was truly revolutionary. Suddenly you could make your websites interactive with just a few lines of code, and it worked in every browser! This inspired an entire generation of web developers.

ozim 5y ago
Not arguing that you are wrong but... I believe causality went other way around. Everyone started migrating to web applications so there was money in improving tooling. So push to web applications revolutionized JS tooling.
- mmcnl 5y ago
  I don't think so. Angular and React are made by Google and Facebook. The Bootstrap CSS framework originated at Twitter. Chrome/WebKit were developed by Google and Apple. The V8 engine inspired NodeJS. Also there was this weird time period where every app suddenly had to be isomorphic, i.e. sharing the same codebase as the webapp with the native apps. I think a lot of the initial work to deliver code at scale had to be done by Big Tech to accommodate their hypergrowth in the early 2010s.
justsomeuser 5y ago
I still have the jQuery APIs memorised, it’s often easier and more concise than the standard web APIs.

hugs 5y ago

... searches article for "Express"... 0 results ... searches comments here for "Express"... 0 results ... goes back to writing Express apps...

_fat_santa 5y ago
I don't think express is mentioned often because it's mostly used as a straight backend language. Sure you could do SSR via Express but I've personally never seen it implemented like that.

progmetaldev 5y ago

I got my start in 2008 with Prototype and the effects library Scriptaculous (built on Prototype). Prototype would actually alter built-in JavaScript objects, which could cause problems if you introduced scripts not built with Prototype. It was still a breathe of fresh air compared to using vanilla JS back then, with all of the incompatibilities between browsers. Once jQuery was introduced, and decided to wrap objects rather than alter them, it really changed the way development was done. I still build all my web apps using progressive enhancement, and try to use static HTML as much as possible so apps still work without JS. It really doesn't take any extra time to build this way, and I separate my backend logic so I could easily move to a SPA if a client desired it (NOTE: most clients really don't care as long as it works, and they don't have to wait too long for page loads).

FpUser 5y ago

I've written real time (stock exchange like) web applications in the 90s using Java Applets (also ActiveX for IE browser). Before that I wrote even simpler one (no Applets or ActiveX) as it has relied on server push which was supported by Netscape browser only and it had a bit less functionality. On back end I just wrote custom webserver.

troysk 5y ago

So well written... Brought back memories. Thanks for the nostalgia!

yesimahuman 5y ago

This is missing the web component based frameworks like Stencil and Lit. Without those we’re missing a big part of the moment to framework-agnostic components and design systems and assembling these to build apps.

dehrmann 5y ago

It's weird that they frame the growth of web frameworks as a reaction to feature-rich mobile apps. > From the get go, mobile apps on iOS and Android were full applications written in Serious Languages™ like Objective C and Java...This [deeper integration] resulted a much better UX... > Doing all of that with JavaScript was seen as ludicrous at first. But as time went on, applications started to get more ambitious. Social networks added chat and DMs and other real-time features, Gmail and Google Docs... Desktop-similar Google Docs and Gmail predate smart phones. Meebo was running a desktop-like chat app in 2005. At the time, it felt ludicrous. Rich client-side web frameworks were already pretty far along by the time the App Store came out in 2008.

deaddodo 5y ago
On top of that, most of the techniques that mobile apps leverage today were developed for web apps of old. REST + JSON was built as a lightweight data transmission option for Ajax/XmlHttpRequest versus transmitting HTML over the line. Component-based/Reactive UX came about because of the unknowability and variability over browser windows. Asynchronous development paradigms came to prominence due to the high latency of frontend<->backend apps combined with fault-intolerance assumptions. Etc.

matthoiland 5y ago

Era 1: Nobody knows what they're doing Era 2: Everyone uses jQuery Era 3: Everyone copies Gmail and Grooveshark using Backbone and Angular Era 4: React is all the hipster bootcamps teach Era 5: NextJS and React Native is how you build apps

cosmotic 5y ago

I still use jQuery. Code is maintainable and theres no frustrating, inconsistent, security-fraught, frequent-breaking-changes NPM situation. I have maybe two dependencies instead of literally thousands. Pages load fast and the foundation I'm building on isn't moving faster than I can build.

jpcapdevila 5y ago

Very nice trip down memory lane! My experience was very similar. For me the next step, the fifth era if you will, is javascript that manages the persisted distributed state for you without any backend or db specific API. You push something into an array and it is magically there for another user in the other side of the world. I'm working on something like that: https://javascriptdb.com https://javascriptdb.com

oaiey 5y ago

> I don’t think React invented components, but to be honest I’m not quite sure where they first came from. I know there’s prior art going back to at least XAML in .NET, and web components were also beginning to develop as a spec around then. He started programming in 2012. He does not know the 90s. Good for him. Honestly, I have no idea how long back components go ... my educated guess: Smalltalk? Minimum.

eBombzor 5y ago

It's funny to see this person loving SSR and then have another who says it's the devil https://gist.github.com/Widdershin/98fd4f0e416e8eb2906d11fd1da62984 https://gist.github.com/Widdershin/98fd4f0e416e8eb2906d11fd1...

racl101 5y ago

jQuery should be its own era. The impact of that framework cannot be understated.