Hacker News Reader

Comment by aazaa | Hacker News Reader

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 true way forward for interactivity. The scripting language released at about the same time seemed like an oddball.

It's easy to forget, but for years after its introduction JavaScript didn't work well. It was extremely slow, limiting the complexity of what could be built with it. There were problems galore with cross-browser compatibility of what was written. There was no reliable vector graphics or canvas system, so you really couldn't do much graphically. The DOM interface was hard to understand to be charitable. It didn't run outside of the browser, so how dare you call yourself a developer if you were using it?

To the extent that developers knew JavaScript existed at all, it was not considered a programming language.

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.

View on HN

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.

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.

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.

Inbox was definitely written using GWT, as were other major google products, but not gmail as far as I know.

That’s not true. Inbox was written in Angular originally. Not sure what it evolved to but it was always JavaScript.

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.

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

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.

This is factually inaccurate. Gmail is and was always JavaScript. GWT had some successes (eg AdWords). Gmail wasn’t one of them.

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.

Should Microsoft get credit for inventing Ajax and having the first real world functioning example of it?

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.

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.

I used Remote Scripting as well. It was a reliable enough hack that we built a lot of stuff on it. But I don’t think it was intended to be used that way when Netscape released JavaScript in ‘95.

> Applets and plug-ins were so much more capable.

Except that they couldn’t alter the DOM, or handle events on DOM elements, the two things that developers really needed (even if they didn’t know it).

So the DOM was introduced in 1998, three years after applets and plugins. In 1995, you could write JavaScript code to dynamically render a page on load using document.write, but updating the rendered HTML was another story. Otherwise, JavaScript was limited to very very simple things.

When DHTML was introduced in '97-'98, the only major browser that had a reliable DOM was IE until Firefox came around in 2002. Netscape tried, but it was buggy to the point where there were no real workarounds to the huge gaps in missing functionality.

As far as 1995 was concerned, applets and plugins looked like the future. Honestly, the web was so new and so inferior to other things in 1995 (Macromedia, WYSIWYG tools, etc.), I think most of us saw HTML being replaced in a few years by a richer clients, applets or plugins.

Thats why people wrote Applets. Even if u wanted manipulate the dom (u could), u didnt, because the Applet was so much faster and more feature rich.

I remember when Java first came out. It seemed like a new and improved C++ and I was intrigued. When it became clear that it was being positioned as purely an applet language I lost all interest.

Then along came Javascript with its transparent attempt to ride the coattails of Java by adopting a similar name. No interest in that either.

You're right that Java was being promoted as a front-end language at first (Sun found a customer for Java), but I'm pretty sure the intent was to generate excitement by finding a killer app and then expand the market from there.

Also, Java applets and JavaScript were added to Netscape 2.0 at the same time and were meant to complement each other, not compete. It may seem like Java came first because JavaScript was called LiveScript for the first three months. I also don't think the JavaScript name change was intended to ride the coattails of Java, rather it was clarify and harmonize its relationship to Java.

I still look back and I'm amazed at how much stuff happened between the summer of '95 and winter '96. Windows 95 release. Netscape went public. 2.0 released 1 month later introducing Java and JavaScript, etc. etc. etc.

Sorry, didn't mean to imply that my reaction was any kind of truth about the situation. I'm just recalling the thoughts I can remember from that time, hoping that they have some relevance.

I'm sorry, I didn't mean to correct you as much as add color for other HN readers. So much happened in a very short period of time and I hope that people take away how much vision and strategy these people had at that time.

I think the point I'm really trying to make is that the Netscape team had a much richer vision of the web than what we use today. Before they built Netscape, Andreessen and Clark were considering building an online gaming platform. I'm sure you remember how big multimedia was back then.

If you look at the timeline, you can see where the were going. They started off with a focus on dominating the browser market, which they did in 4 months. In less than a year after their first release, they released the first version of an online platform. It added Java, JavaScript, and a plug-in architecture with standard plug-ins like Live3D so you could embed VRML into your HTML page. No one was even sure HTML wasn't going to be replaced by something better, so I have to imagine they were hedging their bets by adding three different ways to build on their platform.

If anything, I think your original comment reinforces that strategy. They knew there were a lot of C++ developers who wouldn't take to Java for whatever reason, so they offered a plug-in architecture for people who cared more about performance and experience than being cross-platform.

Had things gone differently (Microsoft not woken up), I can easily see Netscape creating a dominant internet platform that went beyond HTTP and viewing hyperlinked documents. They were already bundling email, website editors, conferencing, news clients, etc.

What did you need plugins for? Netscape and MSIE both were able to add a script tag to the DOM dynamically, and that was all you needed to build the rest of it.

You were able to use document.write somewhat dynamically, but the not reliably across all the browsers. Even if you did make an RPC call, there wasn't a lot you could do with it presentation wise because DHTML was two years away. (Even then, IE was the only one who had a decent implementation for a number of years after that.)

Plugins and applets filled a huge gap functionality wise.

You must have been before me. NN and MSIE 4 both had what we now call DOM Level 1, in 1997.

My recollection at the time was IE4 had a working DOM while Netscape's DOM was buggy and left a lot to be desired. It was there, but it was a struggle.

I don't say that to crap on Netscape. Microsoft was a well-funded company with a lot of experts who had years of experience create applications with DOMs. Also, they had the luxury of delivering a browser for one operation system.

Netscape was a brand new company that went public 7 months after it's first release and 1.5 years after its founding. They sold investors the premise they were going to become the Microsoft of the internet. They had a fraction of the resources while they were trying to creating browsers, email clients, collaboration software, web server, and a host of other software for multiple platforms.

> The browsers were still implementing the basic features

And they are still doing it. CSS Grid is not even 3 years old.

in 2004 a guy gave a talk about how they wrote large js apps, probably 1999-2000. they made a sturdy full fledged toolkit with nice prototypes. but at the time everything was in house

That's exactly why we were able to use it. For a while, we were IE only, but then we started to support Firefox (Only because the developers were fans and we started recommending it to users).

Oh my goodness. Flashbacks to an web app I was coding up for Universal Studios Music Group back in '99. It leveraged Visual Basic DCOM components hosted in Microsoft Transaction Server. I took over the UI from a dev that was extremely behind, and in a week threw together a fancy UI with a pop-up menu and some other asynchronous interaction concepts (later AJAX / REST provided the abstractions to make it easy).

That was a fun, well-paid project with lots of (non-exempt) overtime. Then the .com bubble popped.

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.

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

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.

That wasn't just the first large scale use of it, that's when AJAX was invented.

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.

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.

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.

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?

Dispersing their influence where? Windows was all that mattered then. No one cared about the “beleaguered” Mac that was losing marketshare and Apple was close to bankruptcy. No one cared about Linux. It’s not like now where there are four platforms that matter for consumers - Android, iOS, Windows, and Macs.

In the context of that time, Electron would be considered inferior.

IE wasn’t “cross platform” though. The rendering engine for the Mac was completely different and ironically more standards compliant and had a more complete CSS implementation than the Windows version.

I cannot remember the years, but IE ran on linux at some point in the 90s.

I seem to remember oddpost.com doing 'Ajax email' pretty significantly in 2002/2003, well before gmail.

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

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

In fact I'm pretty sure that's why Microsoft introduced XMLHttpRequest

https://en.wikipedia.org/wiki/XMLHttpRequest#History

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.

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.

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.

As someone who was at Microsoft and had connections in the IE team, I can tell you that Oddpost influenced IE itself, in that the team considered it a pretty novel thing to do with the browser and actually had the Oddpost dev team up to Redmond to pick their brains about how the browser should support these types of apps.

Outlook Web Access is absolute horseshit compared to OG gmail. Sure, it was JS-driven, but it wasn't good.

The apps you mentioned had nowhere near the impact that Gmail had in terms of showing what was possible

GMail had a massive impact, but I didn't really think it was novel from a technical JS perspective. It was really basic, and loaded fast. It had excellent fast search and very good junk mail rejection.

Most email providers had approximately 100Mb mailbox limit (I can't remember specifically), but Gmail had 1Gb.

It was novel to release gmail at that scale in javascript. It hasn't been done before. 1Gb was a crazy size.

Anybody remember gmail invites?

I remember Gmail invites. Ironically, Evan Williams (formerly of Twitter, now of Medium, at the time working at Google after they bought Blogger) was the person who sent me mine—and on the morning of April 1st, 2004. So I've had a Gmail account since the first day it was publicly available.

Yes, had one from an uncle.

I then realised that I could invite a second account, so I created a handful of accounts and still own them today.

Good times.

Sure, I bought one off ebay for 0.10€ :D

I actually got an invite from Google because I was on blogger.com back then (sad to admit it...)

I probably could have picked firstname@gmail.com were it not for the 6 letter minimum, so ended up with firstlast@gmail.com which still yields an absurd amount of messages meant to a variety of other recipients...

To me it was Maps in 2005 that really showcased what JS could do.

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

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.

Outlook was the first true web 2.0 (or SPA) website. It's what XHR was built for.

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.

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.

agreed- maps was the real game changer. gmail was just okay

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

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.

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.

I remember those times. Things like DHTML clocks.

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

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)

And god forbid you got yourself in an alert() loop!

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

Much better if it had gone with Scheme

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.

Something like TCL would be far better. Or Inferno.

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.

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.

That's exactly what makes Lua and JS directly comparable - they're both barebones, when it comes to stdlib.

But as far as the language itself goes, Lua is far superior, with a lot more consistency all around, and fewer traps.

To be honest, I was using JavaScript for years as an OOP language before I actually understood how I could use JavaScript as a functional language.

However, I don't think the limitation was the language. The biggest limitation really were bug ridden browsers. Trying to get something to work across all browsers was incredibly challenging because so many basic features simply didn't work.

Had the syntax been based on scheme, my guess is scheme's reputation would have suffered. I think people have a tendency to blame the thing that they understand the least, so I could see people blaming scheme for the browser's failings.

Also, I went to a university that taught SICP and I'm sorry to say it wasn't popular. Again, when things didn't work, there was a tendency to blame the thing that was least understood.

I could see a Lua-like syntax being approachable, but even that wouldn't have helped. Again, the biggest problem with JavaScript was being tethered to buggy browsers that often failed when you asked them to do simple things.

Then everyone would hate scheme now :-) The primary problems with JavaScript was browser incompatibilities and bugs, mostly related to the DOM, and a limited standard library. Using a different language syntax wouldn't have alleviated those problems.

But I like the idea of angle brackets for content and parentheses for script.

Jquery was invented and became massive for decades because it made js basically suck less.

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.

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.

That's nitpicking. Javascript was the only language that could be used to manipulate DOM so it's normal to conflate the two.

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

EDIT: I forgot about JScript vs JavaScript vs ECMAScript.

https://johnresig.com/blog/versions-of-javascript/

However much of this isn't relevant today.

So in other words: 1: to fix js chaining 2: to fix js compatibility Ergo to make js suck less.

No. The first is incoherent, the second ignores half my comment.

You're splitting hairs with that half of your comment so I ignored it.

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.

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

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.

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

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.

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?

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.

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.

> Don't write programs to run in the same space as websites.

Who do you imagine is going to find this advice compelling?

I know right. Why would you ignore the single best distribution channel that has ever existed for software?

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.

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.

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.

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?

VT-100, IBM 3270 terminals, X-Window, Tk, Qt, Oracle Forms (with some caveats).

And just because "web" more or less works doesn't mean we should stop trying. Web UI's for typical CRUD are expensive to build and maintain compared to 90's IDE's. Yes, I realize it made deployment simpler, but programming has at least doubled for the same feature set at the average shop. (There are exceptions, I know, I'm talking average.)

If somebody can justify "it must be that way", I'd like to see the logic. I'm highly skeptical. We just accepted our CRUD Rut as an industry because it's good job security, not because it's efficient. That's somebody else's bill. A good GUI-over-HTTP standard would make a boatload of dev problems float away. I really miss state, for one; it was a good thing. Oh Darling State, I surely miss thee, wherefore art thou? Jetsons tech was yanketh from my finger, and replaceth with Flintstone fiddle diddleth.

(And why are my posts getting bad scores? I don't get it. Ask first, and then neg.)

- Tcl/Tk

- Perl5

- Python

- VT220/VT100 terminals + ncurses

I used to think so, but with reactive components and css layout like grid, you have enough clear paths for most use. This dom thing seems like it's here to stay for a few decades more.

Everything I've seen so far either has a huge learning curve to do right/well, breaks over time, or both. If there is a product out there that solves these, that would be nice. I'm skeptical, but I'll ask around...

>New browser brands or version often "break" a lot of libraries and code.

When has it happened that browsers have broken standardized features? Browsers have gone through large lengths to stay backwards compatible. It's hard for me to think of things that have been broken besides nonstandardized stuff (like plugins, or things that only worked in one browser to begin with like IE).

Reply on news.ycombinator.com