10 ms·

The release of JavaScript was deeply confusing to me as a developer back then. Java applets and Macromedia Flash were already touted by their vendors as the one

• shados 7y ago
  I remember dealing with JS early on the same way I deal with bash today. With all the weird apis no one understood at the time, limited internet resources (and even books at first), it was just a crazy quest to hunt someone who knew what to do, copy it, and try to tweak it (usually unsuccessfully) until something kind of sortoff does what you want.
• reflectiv 7y ago
  Complex javascript apps just weren't a thing...hell, it took google writing Gmail (2004) to really show everyone that a large SPA using javascript was even possible. After Gmail...things really started to move in the javascript world...people started to put effort into both the runtimes and the libraries.
  • monocasa 7y ago
    And even then, gmail wasn't really written in javascript. They compiled Java down to JavaScript because JS itself was such a pain to deal with natively.
    • nogridbag 7y ago
      Do you have a source for this? Google did create a Java to JavaScript compiler/web framework: GWT but as far as I understood this was never used by the Gmail team. In fact, I heard there was pushback against using this on Gmail.
    • andykellr 7y ago
      Inbox was definitely written using GWT, as were other major google products, but not gmail as far as I know.
      • cletus 7y ago
        That’s not true. Inbox was written in Angular originally. Not sure what it evolved to but it was always JavaScript.
        • dragonshed 7y ago
          Angular definitely did not catch on for google properties until much much later. Back when I did nothing but backbone/angular consulting, none of the major google properties used angular.
    • svachalek 7y ago
      I think most of it was written for the Closure compiler (JS-to-JS), with some bits like chat windows in GWT (Java-to-JS).
      • monocasa 7y ago
        I was under the impression that the closure compiler didn't exist in 2004, only GWT, and that it was rewritten to be almost all JS later.
    • cletus 7y ago
      This is factually inaccurate. Gmail is and was always JavaScript. GWT had some successes (eg AdWords). Gmail wasn’t one of them.
  • steego 7y ago
    They really weren't a thing, but they also weren't unheard of. Personally speaking, I started working on a complex JavaScript application (web-based ERP/CRM system) in 2000. While it wasn't an SPA, we designed our pages so you didn't have to leave them to do what you needed to do. For example, a user might stay on one page for a few hours because they're speccing out a project. Updates were often committed live using remote scripting (A precursor to AJAX) and we did a lot of DOM manipulation to update content in-place. At that time, we targeted IE because Netscape's support for DOM manipulation was abysmal. While I have to give Gmail credit where it's due, I have to give Firefox the real credit for doing the hard work and finally releasing an alternative to IE that kicked JavaScript into high gear. If Gmail had never happened, it would have only been a matter of time before SPAs were going to become a thing. There were more of us doing it before Gmail than most people realize.
    • skinnymuch 7y ago
      Should Microsoft get credit for inventing Ajax and having the first real world functioning example of it?
      • steego 7y ago
        They do deserve some credit for intentionally introducing that feature to the browser as a standard feature, but the notion of fetching data without reloading the page wasn't novel at all. That's what Java applets and plugins were for. I'm also pretty sure they weren't the first to fetch data from the server without reloading, because people were doing all sorts of novel things in the mid-90s with plugins. The reason it didn't really take off back then wasn't because of vision. It was because there was so little you could do with JavaScript. The browsers were still implementing the basic features and a lot of page/component manipulation was very broken. Applets and plug-ins were so much more capable.
        • stan_rogers 7y ago
          Loading into a hidden or pixel-sized iframe (or ilayer in NS) was a thing before XMLHttpRequest as well. In what would now seem a scary technique, you would use JS to load more JS (plus data, of course) that would put the new data into the iframe's host page.
  • dylan604 7y ago
    It was my impression that Gmail's big hit was its use of AJAX more than just its use of Javascript in general. Until then, it was just this obscure thing MS created, but it wasn't really used in the wild until Gmail.
    • steego 7y ago
      It was used, but mostly for internal applications or websites that were willing to dictate a minimum browser. Firefox was only released in 2002. By 2004, it had hit a critical enough mass that it was reasonable to tell a user they needed as good as IE or Firefox at the time (for a beta project).
  • scarface74 7y ago
    Let’s give credit where it’s due. The first large scale use of AJAX was Microsoft using it in Outlook Mail for the web in 2000.
    • bdcravens 7y ago
      That wasn't just the first large scale use of it, that's when AJAX was invented.
    • carterehsmith 7y ago
      Indeed. Microsoft also exposed all of that HTML/JS engine as COM or whatever component, so it could be used by applications other than browser. I remember using Microsoft Money -- personal accounting software -- and it seemed to be all built on that HTML/JS engine.
      • pavlov 7y ago
        It’s crazy how Microsoft had all the pieces in place in 2001 to own both the Chrome and Electron spaces. Even Apple was shipping IE as their default browser. By investing in cross-platform IE and making it both the best browser and the universal runtime for desktop-quality apps, they could have had “Windows Everywhere”. Instead they did the exact opposite and folded IE into a component of desktop Windows where it received no meaningful investment and lost its once commanding lead. Microsoft’s exclusive focus on their proprietary non-portable APIs was a great blunder.
        • numtel 7y ago
          They had been recently sued for having a monopoly from bundling IE with Windows. The chain of events you describe was in many ways not a choice of Microsoft.
          • pavlov 7y ago
            This is a good point, it’s easy to forget about how closely watched Microsoft was by regulators. But IMO it makes it all the more surprising that Microsoft doubled down on the centralized OS+API+apps leverage combo that had brought upon them the antitrust scrutiny, instead of dispersing their influence?
  • lowercased 7y ago
    I seem to remember oddpost.com doing 'Ajax email' pretty significantly in 2002/2003, well before gmail.
  • unreal37 7y ago
    "Complex javascript apps just weren't a thing" I don't know what you were doing in 1995 and 1996, but I was building Javascript apps. They were "a thing" for me at least.
  • asiachick 7y ago
    Please don't repeat this non-fact. There were plenty of large SPAs before GMail. Oddpost existed 2 years before Gmail https://en.wikipedia.org/wiki/Oddpost https://en.wikipedia.org/wiki/Oddpost It also felt more like an app than gmail ever has given it had the "standard" 3 panel look of most desktop email apps (same as most of them do today like Thunderbird/Outlook/Apple's Mail) And before that Outlook had a browser version that acted like a SPA since 1997. https://en.wikipedia.org/wiki/Outlook_on_the_web https://en.wikipedia.org/wiki/Outlook_on_the_web In fact I'm pretty sure that's why Microsoft introduced XMLHttpRequest https://en.wikipedia.org/wiki/XMLHttpRequest#History https://en.wikipedia.org/wiki/XMLHttpRequest#History
    • chc 7y ago
      I don't think many people knew about Oddpost, whatever it was, so it seems a bit suspect to say it influenced a lot of developers' perceptions of JavaScript.
      • lowercased 7y ago
        As someone who was doing web development at that time (since '96 actually), oddpost did have an impact on perception of JS and what was possible among developers. Yahoo buying them was kind of a big deal at the time, and every developer I knew who was involved in web stuff had seen it or at least heard about it. The biggest drawback at the time was that it was window/IE only, and when gmail was released, google made an effort to be cross-platform. IMO, Google's 'big win' wasn't so much showing what JS could do, but that complex JS could be done cross-browser and cross-platform.
        • trustfundbaby 7y ago
          Never heard of oddpost, and pretty sure most devs at the time had never either. I do remember Gmail really being a wow moment with respect to Javascript and specifically AJAX though.
          • hamburglar 7y ago
  • swiley 7y ago
    Gmail is a great example of everything that sucks about web applications. Poor information density, crap sliding around underneath your mouse everytime you go to click, GUI changing every month, ambiguous pictograms everywhere. Maybe users like native applications because native app programming sucks and it weeds out people who carelessly build things like that.
  • bfung 7y ago
    It wasn't gmail -- it was google maps that really made everyone look again at javascript. Although MS added XMLHTTPRequest, it took something like google maps that pushed it further than anyone thought at the time to make JS a real thing.
    • thedance 7y ago
      Yeah, gmail was different than other webmail products but its innovation was really on the backend, giving everyone 1000x more quota than Yahoo was giving them. On the other hand the google maps frontend was what really sold it. Up to then you were getting a full page load every time you panned or zoomed mapquest or yahoo maps. Gmail did not eradicate yahoo mail or hotmail. Google maps promptly eradicated mapquest.
    • liveoneggs 7y ago
      agreed- maps was the real game changer. gmail was just okay
  • blahyawnblah 7y ago
    Outlook was the first true web 2.0 (or SPA) website. It's what XHR was built for.
  • NicoJuicy 7y ago
    Gmail was user friendly, but that's it. I think the v8-runtime changed a lot for Javascript, although it was already normal to use then
• nickthemagicman 7y ago
  Jquery was invented and became massive for decades because it made js basically suck less.
  • tabtab 7y ago
    To an extent, yes, but didn't entirely solve the problem. When something goes wrong with Jquery or something that uses it, Jquery is yet another layer to debug or break. There's a point where throwing more layers at a problem has diminishing returns. The solution (for CRUD makers) is to make common desktop GUI idioms part of a standard instead of emulate them all. This includes but is not limited to: MDI windowing (as an option), modal panels, drop-down menus, tabs, combo boxes, editable column-expandable data grids, expandable trees, tool bars, and a decent multi-select widget instead of using (just) the Ctrl key. HTML frames were helpful, but have since been deprecated. Somebody found them too useful? Mobile land is too different from desktop land. Forcing a lowest common denominator is bad for business IT productivity.
  • JimDabell 7y ago
    jQuery was invented for basically two reasons, neither of them about making JavaScript suck less. 1. Introduce a "chaining" API. 2. Paper over the differences between how browsers implemented the DOM, with events being the big issue. Note that the DOM is not JavaScript and JavaScript is not the DOM. The DOM is a language-agnostic API for manipulating markup-based documents.
    • tasogare 7y ago
      That's nitpicking. Javascript was the only language that could be used to manipulate DOM so it's normal to conflate the two.
      • uk_programmer 7y ago
        Well to nitpick your nitpick. Internet Explorer did allow you to use vbscript to manipulate the DOM. http://www.herongyang.com/VBScript/IE-Browser-DOM-API-Document-Object.html http://www.herongyang.com/VBScript/IE-Browser-DOM-API-Docume... Also you can use XSLT to create a new DOM tree in a browser from an XML document. http://www.informit.com/articles/article.aspx?p=24032&seqNum=9 http://www.informit.com/articles/article.aspx?p=24032&seqNum... EDIT: I forgot about JScript vs JavaScript vs ECMAScript. https://johnresig.com/blog/versions-of-javascript/ https://johnresig.com/blog/versions-of-javascript/ However much of this isn't relevant today.
• commandlinefan 7y ago
  > didn't work well. And nearly impossible to debug on top of that. Firebug didn't come around until 2005, and AFAIK that was the first interactive debugger for Javascript. In fact, I remember spending a lot of time debugging without even console.log() support - window.alert() was the only weapon you had for the longest time. Not to mention every Javascript implementation's frustrating habit of just throwing up a blank page instead of an error message if anything was wrong...
  • johannes1234321 7y ago
    Before firebug there was Venkman debugger (mind the Ghostbusters theme) as Firefox (or Firebird and Netscape Navigator 9) as well as Thunderbird and their other components where built using JavaScript+XUL (pronounced Zool, as in Ghostbusters)
  • strbean 7y ago
    And god forbid you got yourself in an alert() loop!
• NeoBasilisk 7y ago
  >It's easy to forget, but for years after its introduction JavaScript didn't work well. I haven't forgotten, and I will never forget.
• tabtab 7y ago
  Re: It's easy to forget, but for years after its introduction JavaScript didn't work well. And STILL doesn't, at least for anything non-trivial. New browser brands or version often "break" a lot of libraries and code. It's not really JS's fault: HTML wasn't meant to be emulate real desktops, and shoehorning it to do so has made a giant tangled multi-layer mess. Browser standards should be split into three focus areas: 1. DOC: Document-oriented for text display and editing. It would be similar to existing browser but with more word-processing-like features. [I removed "read only"] 2. GUI: Mouse-centric stateful GUI markup for data-oriented "productivity" CRUD applications. 3. ART: charts, games, music, and movies. The one-size-fits-all "standard" mostly failed (job security aside), time to split and focus. Let's admit we f!!! up as an industry.
  • Polylactic_acid 7y ago
    The problem is most pages need to fall in to 1 and 2. Wikipedia is a document website but it also has editing features and it also has interactive mouse things like the hover previews.
    • tabtab 7y ago
      Good point. Perhaps I shouldn't have said "read only" in #1. Just plain "document centric", including editing of documents and text. There will always be some overlap, but that doesn't entirely diminish the value of focus. It may be possible for a given window or panel to select which focus-standard it uses to make mix-and-match a bit easier. A given "starting" browser, typically the document-oriented one which will contain menus and lists (such as an intranet) could be configured to select the user's or org's desired GUI and Art engine. And each "engine" will contain a minimal common sub-set, mostly around existing HTML.
  • underwater 7y ago
    Websites don't exist in neat silos. Web technologies like JS aren't perfect, but they haven't failed be any stretch of the imagination. What other platforms are still alive and evolving decades after their creation?
• technion 7y ago
  Back when I first played with Javascript I don't think anyone even used the name. Tutorials were all about "DHTML", where you were building "Dynamic HTML" by writing Javascript to move items around.
  • geerlingguy 7y ago
    It seemed like 99% of the Javascript I found was little hacks to have some string of text move around with your cursor, or to make the status bar scroll some text.
  • wyclif 7y ago
    I remember those times. Things like DHTML clocks.
• Endy 7y ago
  Well, if by 'for years', you mean 25 years, you're right. ECMAScript is still hot garbage that clogs up computers and the internet, ballooning requirements on browsers and nearly forcing the monoculture we have in terms of browsers and rendering. If you want a website, you should write a website. If you want a program, you should write a program. Don't write programs to run in the same space as websites.
  • emtel 7y ago
    > Don't write programs to run in the same space as websites. Who do you imagine is going to find this advice compelling?
    • james_s_tayler 7y ago
      I know right. Why would you ignore the single best distribution channel that has ever existed for software?
  • draw_down 7y ago
    I love when HN lets it fly about JavaScript. It would never be acceptable to post something like this about PHP. Lovely!
• thrower123 7y ago
  Java Applets over current connections, on current hardware, and written with Kotlin would be pretty nice. Especially if we still had plain old HTML and CSS too for non-applications.
• outworlder 7y ago
  > These things started to change in the early 2000. So deeply ingrained with the disgust for JavaScript, that it took a very long time for the consensus to emerge that you could actually build very complex software on a post-V8 runtime. I wonder how history would have looked like if Scheme had been used instead, as was the original intention. Or perhaps, Lua.
  • BoiledCabbage 7y ago
    Much better if it had gone with Scheme
    • TheCycoONE 7y ago
      With scheme perhaps, but the Lua of 1995 was a much more primitive language which didn't even support closures. It had the opportunity to break backwards compatibility and refine itself numerous times - as the defacto language of the web I think lua would have turned out much poorer rather than the web much better.
      • anthk 7y ago
        Something like TCL would be far better. Or Inferno.
      • hombre_fatal 7y ago
        Lua is pretty terrible in how barebones it is. I don't think anyone on HN who raves about Lua yet complains about JS has done much work with either. There's a reason it has zero traction beyond embedded application and niche application like Pico8.
        • mntmoss 7y ago
          That which Lua is missing is primarily in terms of its ability to define clear, succinct algorithms. And in this respect the more Algol-derived languages enjoy a substantial advantage by having readily available tools for the task. Tables are a semantic compromise compared to list, array and map primitives, and the standard library assumes little, making it hard to write "native" Lua without encountering a need for R&D on some dependency. But when it works in its true intended domain, gluing together and applying configuration to structured APIs and data, it's about as good as it gets, having had the benefit of major revision. And that makes it a stable computing platform, even more stable than the Lisp family(which are like BASIC in that it's quite easy to make an incompatible one). As a side effect, that also makes it an excellent source-to-source target. But to put it another way: Everyone says they like minimalism until they try to live in it. Everyone who needs minimalism knows its limitations and makes exceptions.
• dillonmckay 7y ago
  I always thought the big paradigm shift was the introduction of xmlhttprequest. Prior to that, it was really just form validation and cool DHTML interactions. I also wonder why AJAX is not called AJAJ?
  • JimDabell 7y ago
    The "X" in the acronym comes from XMLHttpRequest, an API that was originally provided by Internet Explorer to enable fetching XML in Outlook Web Access. It wasn't until later that fetching JSON with it became popular – XMLHttpRequest predates JSON by a few years.
• thdrdt 7y ago
  This is why you could charge a lot of money for rollover effects (most of the time image swapping). JavaScript was hard. I remember writing complex graphic applications in Director. But I think it took at least 10 years before the same was possible in JavaScript.
• dvfjsdhgfv 7y ago
  > It didn't run outside of the browser, so how dare you call yourself a developer if you were using it? That's not exactly accurate, you could actually do some server-side things with it and I knew people who did it (late 90s, early 00s) - although I never understood why and the company went bankrupt in the end.