I think the comparisons with other frameworks like JQuery or Angular are a little out of place. I don't really see Ext as a competitor in that area. It's not really a traditional JS framework, it's more a GUI library that just happens to use the browser as the backend and JS as the programming language.
I mostly saw it used for intranet applications, where not being forced to deploy stuff for each change is a big bonus. In these cases, you're not coming from knockout, backbone or react -- you're fleeing from the wrath of Java Webstart and Swing. And compared to those beasts, ExtJS is a welcome change.
Yes, all the bad things said in the post and this thread are certainly true, but that still makes ExtJS better than some of the alternatives in this peculiar shithole. And no other framework/library seems to move in that direction. Components, sure, but no full-fledged widgets that end up in providing a desktop-like experience. Most widget libraries I've seen were enhancements/additions to mostly conventional web pages (Cappuccino as a possible exception).
Sure, you don't want to provide a 80%-ish emulation of native GUIs on the real internet. But for the corporate stuff like CRMs, it's darn useful. Even ravishing the DOM is better than Swing.
I very much agree with all of your points. ExtJS is hard to beat in terms of the breadth of its widget set, layout configurations, data handling models, etc. Just for the almighty GridPanel, it's worth it I would say. But it's also more appropriate for internal, non-public facing apps. For that, you get pretty much all the usual benefits of a web application (ease of deployment, etc.) without getting lost in a traditional desktop GUI jungle. It's true that the library is frighteningly monolithic and the learning curve quite steep, but personally, I very much appreciate the declarative syntax, the very complete documentation, the multiple examples, the flexible MVC structure and the fact that it can easily result in nice decoupled code, as you can plug any backend you like, as long as it communicates through a well-defined protocol (I personally favor Python and Flask).
Wasn't Flex a better alternative to ExtJS in this problem-space?
Recently I've seen entire apps packaged up as Silverlight, which seems to work well - especially where security (exam marking in this case) is important. Not sure how they're built mind, and it took an age to download, but for intranets it's another interesting approach.
The etymology of "guy" is worth looking up. Apparently derived from Guy Fawkes, who was burnt in effigy. And said effigies became a synonym for "grotesque person" which in turn became just "person". In view of that, male or female shouldn't really matter and, yes, I've heard it used for both genders. (Quite often in the "you guys" form, which is yet another way to compensate for a lack of appropriate grammar in English).
Yes, because the only reason those regulations are in place is a lobbying industry trying for a monopoly. Care for the safety and treatment of the actual passengers would never enter the mind of a politician.
And of course this is true for every country affected.
This looks like it's handy for learning purposes, but is there actually any practical use for this? I don't think that the code size and the pace of development really require changing the core language.
Past re-implementations have focused either on the learning experience, code size (for embedding or Unix "purity" reasons) or the license (i.e. not GPL).
Most of these tools are small enough and simple enough that they sort of "get finished." Probably not interesting but to some purists.
There is something to be said for the nice clean implementations of some of these tools. There is a little to be said for the language itself.
Really, something bigger and better is needed. A new HTTP server, a new sendmail or something, a new DNS server. I'd love to see Go or Rust take on Bind and produce a safe, secure, high performance implementation. The Ada guys never stepped up and produced anything interesting to show their tools' superiority, there is a lot more interest and community in Rust and Go. What's the leakiest, buggiest part of the equation right now? Go make a better one.
Given the current glacial pace of bash development?
The problem is that the only other 'standard' shell scripts can rely on is POSIX/Bourne, which is a bit anemic. Back in the days, this was the realm where the Korn shell was supposed to reign. And amongst commercial unices, it actually did help (the license of ksh88/93 prohibited widespread BSD/Linux use). But sadly most of the features that zsh/bash copied or invented themselves concern the UI, not programming capabilities.
I've seen some pretty big programs in ksh93 and it was half-way decent. Then again, quite often you shelled out to awk/grep/ed and had to fight their incompatibilities... I don't really miss those days.
On the other hand, sometimes I wish Linux scripters/programmers would be forced to use a slightly incompatible system now and then so that they don't assume that the whole world is GNU. I'm not misanthropic enough to say that said system should be IBM AIX, though.
> the only other 'standard' shell scripts can rely on is POSIX/Bourne
Have you seen POSIX? Have you read Bourne shell documentation? I haven't. The former is expensive, the latter is not that easy to get.
I have read Single UNIX Specification, though, which is available on-line.
> But sadly most of the features that zsh/bash copied or invented themselves concern the UI, not programming capabilities.
Shell is not intended for regular programming. It's intended for small automation scripts. If you need to write anything bigger, choosing shell over Perl, Python or Ruby is a fundamentally bad idea. BTDTGTT.
And do you know how much of SUS-guaranteed shell syntax you use, anyway? Do you know what is a bashism and what is in the specification, so you can claim SUS-compliant shell has too weak language?
> Have you seen POSIX? Have you read Bourne shell documentation? I haven't. The former is expensive, the latter is not that easy to get. I have read Single UNIX Specification, though, which is available on-line.
What is the distinction you are trying to make?
Single UNIX® Specification, Version 4, 2013 Edition
Technically identical to IEEE Std 1003.1, 2013 Edition and ISO/IEC 9945:2009 including ISO/IEC 9945:2009/Cor 1:2013(E), with the addition of X/Open Curses.
I see this as the perfect example why the article is mostly wrong. It supposes a personal motivation for "ignoring" allegedly good advice, whereas I'd bet that a lot more readers are looking at things from a objective, scientific angle where just anecdotes don't really count ("every person I tried this on" ain't that much better than "it works for me!").
Probably some variation/inversion of Hanlon's Razor.
Not everyone who wants to see more evidence for every claim and trick is doing that out of sheer denial. There might be some room for the Nirvana fallacy here ("SuperMegaFoodStuff didn't make me into an Adonis in a week, so it's crap"), but in general I'm pro-skepticism.
Note that some dialects have their problems with the u-umlau, in which case you'll actually hear "Hugl". As the article is referencing someone from such an ü-challenged area (Mr. Holzer), maybe the writer just heard it that way.