{ "archive_path": "archive/1748842320.039788", "base_url": "idiallo.com/blog/what-we-lost-with-php-and-jquery", "basename": "what-we-lost-with-php-and-jquery", "bookmarked_date": "2025-06-02 05:32", "canonical": { "archive_org_path": "https://web.archive.org/web/idiallo.com/blog/what-we-lost-with-php-and-jquery", "dom_path": "output.html", "favicon_path": "favicon.ico", "git_path": "git/", "google_favicon_path": "https://www.google.com/s2/favicons?domain=idiallo.com", "headers_path": "headers.json", "htmltotext_path": "htmltotext.txt", "index_path": "index.html", "media_path": "media/", "mercury_path": "mercury/content.html", "pdf_path": "output.pdf", "readability_path": "readability/content.html", "screenshot_path": "screenshot.png", "singlefile_path": "singlefile.html", "warc_path": "warc/", "wget_path": null }, "domain": "idiallo.com", "downloaded_at": "2025-06-02T05:32:01.603024+00:00", "downloaded_datestr": "2025-06-02 05:32", "extension": "", "hash": "1DJBF1VKPTMSVD96YWEW", "history": { "archive_org": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--head", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://web.archive.org/save/https://idiallo.com/blog/what-we-lost-with-php-and-jquery" ], "cmd_version": "8.10.1", "end_ts": "2025-06-02T05:33:36.846728+00:00", "index_texts": null, "output": "TimeoutExpired: Command '['/usr/bin/curl', '--silent', '--location', '--compressed', '--proxy', 'socks5://tor-socks-proxy:9150', '--head', '--max-time', '60', '--user-agent', 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)', 'https://web.archive.org/save/https://idiallo.com/blog/what-we-lost-with-php-and-jquery']' timed out after 60 seconds", "pwd": "/data/archive/1748842320.039788", "schema": "ArchiveResult", "start_ts": "2025-06-02T05:32:36.777376+00:00", "status": "failed" } ], "dom": [ { "cmd": [ "/usr/bin/chromium-browser", "--proxy-server=socks5://tor-socks-proxy:9150", "--disable-features=DarkMode", "--run-all-compositor-stages-before-draw", "--hide-scrollbars", "--autoplay-policy=no-user-gesture-required", "--no-first-run", "--use-fake-ui-for-media-stream", "--use-fake-device-for-media-stream", "--simulate-outdated-no-au='Tue, 31 Dec 2099 23:59:59 GMT'", "--headless=new", "--no-sandbox", "--no-zygote", "--disable-dev-shm-usage", "--disable-software-rasterizer", "--disable-sync", "--window-size=1440,2000", "--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "--user-data-dir=/data/personas/Default/chrome_profile", "--profile-directory=Default", "--dump-dom", "https://idiallo.com/blog/what-we-lost-with-php-and-jquery" ], "cmd_version": "131.0.6778", "end_ts": "2025-06-02T05:32:16.730023+00:00", "index_texts": null, "output": "output.html", "pwd": "/data/archive/1748842320.039788", "schema": "ArchiveResult", "start_ts": "2025-06-02T05:32:05.650831+00:00", "status": "succeeded" } ], "favicon": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--max-time", "60", "--output", "favicon.ico", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://www.google.com/s2/favicons?domain=idiallo.com" ], "cmd_version": "8.10.1", "end_ts": "2025-06-02T05:32:05.180291+00:00", "index_texts": null, "output": "favicon.ico", "pwd": "/data/archive/1748842320.039788", "schema": "ArchiveResult", "start_ts": "2025-06-02T05:32:01.629517+00:00", "status": "succeeded" } ], "git": [], "headers": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--head", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://idiallo.com/blog/what-we-lost-with-php-and-jquery" ], "cmd_version": "8.10.1", "end_ts": "2025-06-02T05:32:05.558673+00:00", "index_texts": null, "output": "headers.json", "pwd": "/data/archive/1748842320.039788", "schema": "ArchiveResult", "start_ts": "2025-06-02T05:32:05.211052+00:00", "status": "succeeded" } ], "htmltotext": [ { "cmd": [ "(internal) archivebox.extractors.htmltotext", "./{singlefile,dom}.html" ], "cmd_version": "0.8.5rc51", "end_ts": "2025-06-02T05:32:31.590225+00:00", "index_texts": [ "What We Lost with PHP and jQuery (https://cdn.idiallo.com) (https://cdn.idiallo.com/favicon.ico) (https://cdn.idiallo.com/apple-icon.png) (https://idiallo.com/humans.txt) (iDiallo) (/opensearch.xml) (https://idiallo.com/blog/what-we-lost-with-php-and-jquery) (Ibrahim Diallo Blog) (https://idiallo.com/feed.rss) (Javascript Blog) (https://idiallo.com/javascript.rss) (/) (Ibrahim Diallo) (Ibrahim Diallo) Main Menu \u26b2 (/) Home (/blog/) Blog (/books) Book (/byte-size/) Byte-Size (/javascript/) JavaScript (/video/) Video (/photography/) Photography (/aboutme.html) About What We Lost with PHP and jQuery When \"Just Ship It\" Became Complicated #BringBackTheDuctTape By Ibrahim Diallo Published (2025-05-31 08:00:01Z) a day ago ~ 5 minutes read There was a time when building a website felt straightforward. You'd write some HTML, add PHP for dynamic content, sprinkle in jQuery for interactions, upload it to your server, and you were done. No package managers, no build processes, no debates about hydration strategies. Today, creating even a simple webpage often involves configuring multiple tools, managing dependencies, and navigating complex development workflows. How we got here? What did we lose along the way? I recently tried to revive a simple React project from 2015. What should have been a quick update became a multi-day archaeology expedition: Running npm install revealed dozens of security warnings Half the dependencies were no longer maintained The React version was so old it predated the current documentation Updating React required rewriting significant portions of the codebase The solution? I converted it to static HTML and CSS. The entire process took about an hour, the site loads instantly, and it will run unchanged for years. The Era of Simplicity: PHP, jQuery, and Getting Things Done I don't want to romanticize the past, but building small projects required less effort. Sure we have AI to build boilerplate code, but PHP and jQuery were the pragmatic workhorses of the early web. They prioritized solving problems over perfect architecture. When PHP 7 was released, Rasmus Lerdorf joke that even your bad code is fast now. That's because the goal wasn't to make a perfect tool for programmers, instead it was to make tools for people to build websites. PHP was refreshingly straightforward. Need to display database content? Write a query, loop through results, and output HTML. Want to handle form submissions? Process $_POST data directly. You can build a quick, reliable, and secure website without including a single dependency. jQuery solved the browser compatibility nightmare that plagued early JavaScript development. Instead of writing different code for Internet Explorer, Firefox, and Chrome, you could write $('#element').fadeIn() and trust it would work everywhere. It made JavaScript accessible to developers who just wanted to add some interactivity without becoming browser compatibility experts. In fact, it was very popular in our marketing department. Modern Development: Powerful but Complex Today's web development tools are undeniably more powerful, but they've also introduced significant complexity: The Modern Stack Requirements: HTML becomes JSX with component hierarchies and prop validation CSS evolves into CSS-in-JS, utility frameworks, or sophisticated design systems JavaScript requires transpilation, bundling, tree-shaking, and often a full build pipeline Development involves package managers, linters, test runners, and deployment workflows Modern projects often include dozens or hundreds of dependencies. Each brings its own maintenance burden: security updates, version conflicts, and the inevitable deprecation cycle. A simple button component might pull in multiple libraries, each with their own dependencies. The Reinvention Cycle Interestingly, many modern solutions solve problems we've solved before, just with additional layers: Server-side includes ( ) become component imports with build-time processing jQuery's $.ajax() becomes fetch() wrapped in state management libraries Simple CSS becomes processed through multiple build steps to achieve similar results We're not necessarily solving new problems. We're solving old problems with new constraints and capabilities. Along the way, we started paying the cost: Higher barrier to entry for new developers Increased project setup time and complexity More moving parts that can break Dependency management overhead The paradox of choice among competing tools After a few years, you can't deploy your code unchanged The web development community has gained incredible capabilities, but we've also made simple things more complicated than they need to be. There's value in remembering that sometimes the straightforward solution. PHP processing a form, jQuery handling a click event, or even plain HTML and CSS. This might be all you need. The best tool is the one that solves your problem efficiently without creating new problems. Whether that's a modern React application or a PHP script from 2010 depends entirely on what you're trying to accomplish. The web became amazing because it was accessible to anyone willing to learn HTML and try things out. As we build increasingly sophisticated tools, we should remember to keep that accessibility and experimental spirit alive. Did you like this article? (https://ko-fi.com/idiallo) You can buy me a coffee .Share your insightful comments here . Sign up for the Newsletter. Name: (Enter your name) Email: (Enter your email) Subscribe Follow me on (https://twitter.com/dialloibu) Twitter , (/feed.rss) RSS Feed Previous: (/blog/when-solutions-get-fixed) When Solutions Get Fixed On a related note, here are some interesting articles. (/blog/no-need-for-new-laptop?ref=rel) (You also don't need a new laptop) You also don't need a new laptop Going through an inventory of my electronic devices last year, I noticed that I did not own a PC. At least not one in the traditional sense: A tower humming under my desk. I do have a few Raspberry PIs scattered throughout the house. I also realized that (https://idiallo.com/blog/oneplus3-6-years-later) my smartphone was 6 years old . What I failed to notice at the time was that my main laptop, an Asus Zenbook UX501V, the one I use to write these blog posts, is from 2016. And it still kicks ass! (/blog/ai-will-take-your-job?ref=rel) (Maybe AI Will Take Your Job After All) Maybe AI Will Take Your Job After All When companies develop AI products with the potential to replace workers, they like to sprinkle in a little reassurance: \u201cAI won\u2019t take your job. It\u2019ll handle the repetitive, tedious tasks so you can focus on the more complex, meaningful work.\u201d \n\nSounds fair, doesn\u2019t it? Almost comforting. But it\u2019s not entirely true. (/blog/problem-with-ai-hype?ref=rel) (The Problem with Hype) The Problem with Hype The main problem with hype is that it keeps us from appreciating what we already have. It\u2019s always about the next big thing. Something revolutionary just over the horizon. But while we\u2019re busy chasing the future, we overlook the real progress happening right under our noses. (/blog/) View all articles Comments(5) (https://blog.strangerthanusual.de) Guido (2025-06-01 11:11:29Z) 18 hours ago : I agree with your general idea, that complex javascript code (and complex javascript frameworks and setups) make web development too complex for most use cases. Sloppy one-page-apps in general make sites to large (in traffic volume), too slow and they circumvent several browser features (such as the back-button). Sure, they can be re-implemented in javascript, but that is re-inventing the wheel and most programmers don't do it. Same for JS size. You can try to keep it small, but few developers care about it (a former colleague in my project did, and I was happy that he always had an eye on it). In my opinion, a static site is great for many use cases, server-side rendering handles a lot of other use cases and some sprinkles of javscript can make a site more convenient to use (as long as it is still usable without it). There are also cases where you can't get around heavy use of javascript (maybe even with the aid of webassembly), for example when you are trying to build something interactive such as a web app for video conferences. I do, however, strongly disagree with the nostalgia about PHP and jQuery. PHP is a deeply flawed language, and the perceived ease of use made sure that a typical PHP website was riddled with security holes (such as XSS vulnerabilities, SQL injections and even code execution). There are exceptions, of course, but that requires skill because it was (is?) easy to shoot yourself in the foot with pure PHP. Some frameworks helped to mitigate that, but then again, that meant you had another layer of complexity again. jQuery may have been really useful in the past, when the browser's JS APIs were not as sophisticated as they are now. Nowadays, you do not lose much comfort when you just use vanilla javascript, compared to jQuery. So for that reason alone I'm not sad about its drop in usage. jQuery was also a pain to update. I had to maintain a software that used jQuery here and there. It had an old version of jQuery, which had some known security issues. The site was large, it was hard to find out whether the security issues were relevant to us, and since jQuery expressions where sprinkled over a dozen JS files and hundreds of template files, it was even harder to update it and check if everything still worked. We eventually managed to get rid of it, but it was a pain and I have seen this pattern on other websites as well. jQuery may have been useful once, but its downsides are bigger than the advantages it has over modern vanilla javascript. Ibrahim author (2025-06-01 15:35:18Z) 14 hours ago : Guido I don't disagree, which is why I added the disclaimer \"I don't want to romanticize php and jquery.\" However my point is that these tools emphasized solving problems, and tried to take complexity out of user's hands. As opposed to current tools that by default are complexe. (https://blog.strangerthanusual.de) Guido (2025-06-01 16:46:11Z) 13 hours ago : As I said, I mostly agree with you. Specifically with jQuery though, we have not really lost much. If anything, by using vanilla JS instead of jQuery, we reduce complexity. This is, if we use vanilla JS (or no JS at all). The complexity of current JS frameworks such as React, in combination with all the tools you need to get it running (npm, webpack, babel, you name it), broken/outdated dependencies, etc is where the problems lie. I very much agree on that part. Unrelated to your article, the dependency hell is not a problem limited to javascript. For example: I used to use ruby on rails for my private blog. I started with it in 2012. By 2020, there were several major version updates for Rails, each of them with breaking changes. The HTML sanitizer I used had a known security issue and needed to be updated. The updated version required a newer version of Ruby, the old version of Rails did not work with the new Ruby\u2026 long story short, I replaced the rails software with a static site generator with a lot fewer dependencies in 2020. Almost five years later, the site generator is still fine, still maintainable and a lot more fun to work with. I've also come across dependency hells at my job. I had to update an old Java web-application that did not use a dependency manager. Ancient versions of spring, ancient versions of some libraries and each library I updated brought another transitive dependency to light. It was very much not fun. In another project, we used React (here it comes full circle with your experience). We using React in 2016 and maintained it until 2020, then we handed over the software to our client's team. I was lucky here, because we had a JS enthusiast in the team (the guy I mentioned who also made sure the JS files stayed somewhat small). This guy took care of the dependency updates and everything. Keeping everything up to date was a pain for him, but we knew if we stayed with a version, every update further in the future would become harder and harder. And eventually, there would be a reason why we had to update . I assume you have made similar experiences (not only with the React app from 2015 you mentioned in the beginning). I like your solution: Make it as simple as possible. Throw away the unnecessary parts, keep what you need. But I also assume that you too have worked with clients who just wanted more and more features in a piece of software. \u201cThe competition added a new feature? We need that as well!\u201d or \u201cWe need to get ahead the competition, so we need to add more features before they do!\u201d. Sorry, I was going off topic a bit (a lot). What I want to say is: Yes, I want to have simpler software, too. And I'm happy that you managed to turn that fossil of a React app into something much more simple. Ibrahim author (2025-06-01 17:11:43Z) 12 hours ago : Funny enough, something very similar to your experience with ruby just happened to me this week. Heroku dropped support for the version of Ruby that one of my clients is using. Which means we can't do deployments anymore without updating ruby and the rails version. They are 2 versions behind, so this requires major rewrite. And of course, they have an older version of React for the client side \ud83d\ude05. Thank you for contributing your insight. (https://www.thatsoftwaredude.com) Walt (2025-06-02 03:09:48Z) 2 hours ago : That's exactly how I feel about .NET. You used to be able to render a data table and style it with CSS in like 15 minutes. Then EF came out, and LINQ replaced queries. And doing a few subqueries with an aggregate function and a grouping took weeks to figure out \ud83d\ude05 I still haven't figured it out. Let's hear your thoughts (Enter your insightful comments here ...) Your Name (Required) Your Email (Required) For my eyes only Your Website Would you like to sign up to the news letter? (1) \u2190 Click here (Post Comment) (498) (1) About Me First of all, Wow! You\n\t\t\tscrolled all the way down. That means you want to know more about me. Well,\n\t\t\there is a summary of (/aboutme.html) who I am and what I\n\t\t\tdo . I started this blog because ... wait I have a (/blog/do-you-really-need-a-college-degree-to-get-a-job) link for that\n\t\t\ttoo . Hey! Have you heard about (/humans.txt) humans.txt? Well I kinda liked the idea and did my own version. You can find me on: (https://twitter.com/dialloibu) Twitter (https://www.youtube.com/user/ibudiallo) YouTube (https://soundcloud.com/ibrahim-diallo-24) Soundcloud Don't hesitate to say hi, it's what keeps me going : ) Designed by Yours truly. Copyright \u00a9 2013 - 2025 " ], "output": "htmltotext.txt", "pwd": "/data/archive/1748842320.039788", "schema": "ArchiveResult", "start_ts": "2025-06-02T05:32:31.559039+00:00", "status": "succeeded" } ], "media": [ { "cmd": [ "/usr/local/bin/yt-dlp", "--restrict-filenames", "--trim-filenames", "128", "--write-description", "--write-info-json", "--write-annotations", "--write-thumbnail", "--no-call-home", "--write-sub", "--write-auto-subs", "--convert-subs=srt", "--yes-playlist", "--continue", "--no-abort-on-error", "--ignore-errors", "--geo-bypass", "--add-metadata", "--format=(bv*+ba/b)[filesize<=750m][filesize_approx<=?750m]/(bv*+ba/b)", "--skip-download", "--cache-dir=/data/yt-dlp-cache/", "--cookies=/data/yt-dlp-cache/cookies.txt", "--proxy=socks5://tor-socks-proxy:9150", "--no-playlist", "https://idiallo.com/blog/what-we-lost-with-php-and-jquery" ], "cmd_version": "2024.10.7", "end_ts": "2025-06-02T05:32:36.742793+00:00", "index_texts": [], "output": "media/", "pwd": "/data/archive/1748842320.039788", "schema": "ArchiveResult", "start_ts": "2025-06-02T05:32:31.962315+00:00", "status": "succeeded" } ], "mercury": [ { "cmd": [ "/home/archivebox/.npm/bin/postlight-parser", "https://idiallo.com/blog/what-we-lost-with-php-and-jquery" ], "cmd_version": "2.2.3", "end_ts": "2025-06-02T05:32:31.528279+00:00", "index_texts": null, "output": "mercury/", "pwd": "/data/archive/1748842320.039788", "schema": "ArchiveResult", "start_ts": "2025-06-02T05:32:23.452046+00:00", "status": "succeeded" } ], "pdf": [], "readability": [ { "cmd": [ "/home/archivebox/.npm/bin/readability-extractor", "/tmp/tmprnph38gm", "https://idiallo.com/blog/what-we-lost-with-php-and-jquery" ], "cmd_version": "0.0.11", "end_ts": "2025-06-02T05:32:23.091371+00:00", "index_texts": [ "There was a time when building a website felt straightforward. You'd write some HTML, add PHP for dynamic content, sprinkle in jQuery for interactions, upload it to your server, and you were done. No package managers, no build processes, no debates about hydration strategies. Today, creating even a simple webpage often involves configuring multiple tools, managing dependencies, and navigating complex development workflows. How we got here? What did we lose along the way?\n\nI recently tried to revive a simple React project from 2015. What should have been a quick update became a multi-day archaeology expedition:\n\n\nRunning npm install revealed dozens of security warnings\nHalf the dependencies were no longer maintained\nThe React version was so old it predated the current documentation\nUpdating React required rewriting significant portions of the codebase\n\n\nThe solution? I converted it to static HTML and CSS. The entire process took about an hour, the site loads instantly, and it will run unchanged for years.\n\nThe Era of Simplicity: PHP, jQuery, and Getting Things Done\n\nI don't want to romanticize the past, but building small projects required less effort. Sure we have AI to build boilerplate code, but PHP and jQuery were the pragmatic workhorses of the early web. They prioritized solving problems over perfect architecture.\n\nWhen PHP 7 was released, Rasmus Lerdorf joke that even your bad code is fast now. That's because the goal wasn't to make a perfect tool for programmers, instead it was to make tools for people to build websites.\n\nPHP was refreshingly straightforward. Need to display database content? Write a query, loop through results, and output HTML. Want to handle form submissions? Process $_POST data directly. You can build a quick, reliable, and secure website without including a single dependency. \n\njQuery solved the browser compatibility nightmare that plagued early JavaScript development. Instead of writing different code for Internet Explorer, Firefox, and Chrome, you could write $('#element').fadeIn() and trust it would work everywhere. It made JavaScript accessible to developers who just wanted to add some interactivity without becoming browser compatibility experts. In fact, it was very popular in our marketing department.\n\nModern Development: Powerful but Complex\n\nToday's web development tools are undeniably more powerful, but they've also introduced significant complexity:\n\nThe Modern Stack Requirements:\n\n\nHTML becomes JSX with component hierarchies and prop validation\nCSS evolves into CSS-in-JS, utility frameworks, or sophisticated design systems\nJavaScript requires transpilation, bundling, tree-shaking, and often a full build pipeline\nDevelopment involves package managers, linters, test runners, and deployment workflows\n\n\nModern projects often include dozens or hundreds of dependencies. Each brings its own maintenance burden: security updates, version conflicts, and the inevitable deprecation cycle. A simple button component might pull in multiple libraries, each with their own dependencies.\n\nThe Reinvention Cycle\n\nInterestingly, many modern solutions solve problems we've solved before, just with additional layers:\n\n\nServer-side includes () become component imports with build-time processing\njQuery's $.ajax() becomes fetch() wrapped in state management libraries\nSimple CSS becomes processed through multiple build steps to achieve similar results\n\n\nWe're not necessarily solving new problems. We're solving old problems with new constraints and capabilities.\n\nAlong the way, we started paying the cost:\n\n\nHigher barrier to entry for new developers\nIncreased project setup time and complexity\nMore moving parts that can break\nDependency management overhead\nThe paradox of choice among competing tools\nAfter a few years, you can't deploy your code unchanged\n\n\n\n\nThe web development community has gained incredible capabilities, but we've also made simple things more complicated than they need to be. There's value in remembering that sometimes the straightforward solution. PHP processing a form, jQuery handling a click event, or even plain HTML and CSS. This might be all you need.\n\nThe best tool is the one that solves your problem efficiently without creating new problems. Whether that's a modern React application or a PHP script from 2010 depends entirely on what you're trying to accomplish.\n\nThe web became amazing because it was accessible to anyone willing to learn HTML and try things out. As we build increasingly sophisticated tools, we should remember to keep that accessibility and experimental spirit alive." ], "output": "readability/", "pwd": "/data/archive/1748842320.039788", "schema": "ArchiveResult", "start_ts": "2025-06-02T05:32:17.804873+00:00", "status": "succeeded" } ], "screenshot": [], "singlefile": [], "title": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://idiallo.com/blog/what-we-lost-with-php-and-jquery" ], "cmd_version": "8.10.1", "end_ts": "2025-06-02T05:32:17.480504+00:00", "index_texts": null, "output": "What We Lost with PHP and jQuery", "pwd": "/data/archive/1748842320.039788", "schema": "ArchiveResult", "start_ts": "2025-06-02T05:32:17.361739+00:00", "status": "succeeded" } ], "wget": [] }, "icons": null, "is_archived": true, "is_static": false, "latest": { "archive_org": "TimeoutExpired: Command '['/usr/bin/curl', '--silent', '--location', '--compressed', '--proxy', 'socks5://tor-socks-proxy:9150', '--head', '--max-time', '60', '--user-agent', 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)', 'https://web.archive.org/save/https://idiallo.com/blog/what-we-lost-with-php-and-jquery']' timed out after 60 seconds", "dom": "output.html", "favicon": "favicon.ico", "git": null, "media": "media/", "pdf": null, "screenshot": null, "singlefile": null, "title": "What We Lost with PHP and jQuery", "warc": null, "wget": null }, "link_dir": "/data/archive/1748842320.039788", "newest_archive_date": "2025-06-02T05:32:36.777376+00:00", "num_failures": 1, "num_outputs": 8, "oldest_archive_date": "2025-06-02T05:32:01.629517+00:00", "path": "/blog/what-we-lost-with-php-and-jquery", "schema": "Link", "scheme": "https", "snapshot_abid": "snp_01JWQJ045MDD42A43401N6J4MQ", "snapshot_id": "d3d123f8-70b7-4924-b986-aa72ea691297", "sources": [ "/data/sources/1748842319-import.txt" ], "tags": null, "tags_str": "", "timestamp": "1748842320.039788", "title": "What We Lost with PHP and jQuery", "url": "https://idiallo.com/blog/what-we-lost-with-php-and-jquery" }