Do you remember what browser testing was like?
Remember the quirks of browsers’ different understanding of transparency, of z-index, of events, of DOM compliance?
I think the suggestion that getting it right could take a week in the context of a particular application is actually not particularly hyperbolic.
Mind you, I was doing cross-browser testing long enough ago that I am one of those people who can say they independently invented AJAX in-house.
The problem is that even without a framework, you didn’t have a blank slate (which would have been better). You had a moving target of blank slates, you had platform differences, you had drag vs touch-drag, entrenched older browsers and the simple frustration of testing on an array of real devices, all sorts.
Now, if you were talking about 2015, then it starts to get a bit flatter.
serious question, why, when people from a field you are unfamiliar with tell you that something has particular constraints in that field, do you confidently assert that you know better?
It's no accident that after certain complexity people will just go for a blank canvas (afaik Google docs is also canvas-rendered).
The problem is that for drag n drop you mostly want to support normal dom.
This is how I feel about global illumination. Game devs claim it's hard but they're just noobs who don't know how to write a lighting shader.
I'm not a game dev, but it can't be that hard.
You claim you've implemented drag-and-drop "a dozen times", then dismiss other developers' experience as if your anonymous assurances settle the matter. I'm posting under my own name and linking to my own work. You're asking us to take your expertise on faith while keeping your work conveniently out of reach of the scrutiny you apply so casually to everyone else's. Put up your dozen examples, or at least one. Let us see what you implemented and whether it supports your claims.
I implemented the "drag and drop" direct manipulation object editing tools in The Sims 1, and it was necessarily extremely complicated to give players effortless control while maintaining the illusion of simplicity. The fact that you may think it's simple is the triumph of years of painstaking design, review, programming, iteration, testing, bug fixing, redesigning, refactoring, tuning, and tweaking.
The Sims, Pie Menus, Edith Editing, and SimAntics Visual Programming Demo:
https://www.youtube.com/watch?v=-exdu4ETscs
In The Sims, you could pick up a chair, carry it without holding the mouse button, see rapid, reversible, and incremental visual feedback as it snapped into valid places or slid through walls and tables where placement wasn't allowed, and rotate it while picking it up or placing it. Making that feel natural takes a lot more thought than saying "just implement drag and drop."
Don’s review of The Sims Design Document, Draft 3 – 8/7/98:
https://donhopkins.com/home/TheSims/TheSimsDesignDocumentDra...
Direct Manipulation:
https://en.wikipedia.org/wiki/Direct_manipulation_interface
>In computer science, human–computer interaction, and interaction design, direct manipulation is an approach to interfaces which involves continuous representation of objects of interest together with rapid, reversible, and incremental actions and feedback. As opposed to other interaction styles, for example, the command language, the intention of direct manipulation is to allow a user to manipulate objects presented to them, using actions that correspond at least loosely to manipulation of physical objects. An example of direct manipulation is resizing a graphical shape, such as a rectangle, by dragging its corners or edges with a mouse.
Randall B. Smith explored this in his paper "Experiences with the Alternate Reality Kit: An Example of the Tension Between Literalism and Magic" (CHI+GI 1987). His Alternate Reality Kit at Xerox PARC let you grab and throw objects with mass and momentum, but also manipulate the physical laws themselves. Deciding where to follow people's physical expectations and where to give them magical powers is part of the design work.
Alternate Reality Kit by Randall Smith at Xerox PARC 1986 (VPRI-0131)
https://www.youtube.com/watch?v=I9LZ6TnSP40
And gamedev actually makes drag-and-drop vastly simpler compared to general purpose desktop drag-and-drop, because you don't have to deal with dragging and dropping to and from other apps that you have no control over, with vastly different data models, their own bugs and limitations, partial or downright incorrect implementations of the protocols, and private extensions. You have to query metadata, discover supported formats and representations, and asynchronously negotiate how to transfer, interpret and convert the data, while working around whatever the other app gets wrong.
Have you actually ever worked on implementing a desktop user interface toolkit, and the intricate machinery for general purpose drag-and-drop, or just used them without having any idea how they work under the hood?
From your blithe shallow dismissals of other people's hard work and deep knowledge, it's painfully obvious you've never even heard of the ICCCM, let alone pored over its many pages of technical details, diagrams, and state machines, then actually tried to implement non-trivial drag-and-drop that works between any X11 application.
https://donhopkins.medium.com/the-x-windows-disaster-128d398...
>As a result, one of the most amazing pieces of literature to come out of the X Consortium is the “Inter Client Communication Conventions Manual,” more fondly known as the “ICCCM”, “Ice Cubed,” or “I39L” (short for “I, 39 letters, L”). It describes protocols that X clients must use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late — by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past.
>The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn’t work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It’s so difficult, that many of the benefits just aren’t worth the hassle of compliance. And when one program doesn’t comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release.
>In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry’s standard naked emperor.
>"Using these toolkits is like trying to make a bookshelf out of mashed potatoes." - Jamie Zawinski