Regarding old browsers: Promise, Destructuring, Class, ES6 syntax, and many other things simply don't work. Webpack adds polyfills and babel do the shims for basic support. V1 and future versions are backward compatible. You cannot guarantee anything regarding browser vendors and it does not matter which feature we are talking about. If you wish to support deprecated browsers, well, that's up to you, but analytics says IE10 and down usage is less than 0.5% of overall user-agents.

My library - slim.js - is a web-components authoring library. Basically, it's just a base class with some superpowers. The website is written in slim.js and it works on all browsers. There are users of my library and overall it seems they are satisfied. Also, many google internal applications are written with Polymer. It's a fact that web components work in production. I would say that for B2B applications (long-lifecycle applications) you should definitely use web components for your core UI or core library, then you could migrate between frameworks and survive the frameworks churn every time it happens.

Code first, (maybe) test later Ignore YAGNI (You Ain't Gonna Need It) rule Undescriptive function/class names "There's a package for that" approach Job security Use micro-performance tweaks and single-liners for show-off Use bitwise tricks when you can use simple Mathematics Commit using non descriptive messages Don't know what is force-push and rebase

It's popular. But comparing to WebStorm it really falls behind. The most important problem I had is that it does not support debugging node clusters. Any app with several node workers cannot be debugged. Another pitfall is that it fails with many popular loggers and you simply have no access to logging during debug time. Last but not least, debugging again, it fails many times with breakpoints on transpiled and source mapped, where Jetbrains got it right. It's my quick editor replacing sublime or notepad++, but when it comes to heavy lifting I'm in favor of Webstorm.

I'm sorry you feel that way. I can understand you as a vanilla developer. But I don't understand why people don't like wc standards. People use plenty of unsupported features with babel, they use scss, they use decorators and hell they even use typescript. But a standard? Are we crazy?

The standard is gaining popularity => all vendors will get there (everybody want's to have chrome marketshare). It's a fact that Safari and FF both support it with developer flags (meaning it's in beta state). Polyfill exists and is very lightweight (and doesn't reduce much performance) => Can run on all browsers Standards + Polyfills are no worse than big libraries with alternate implementations. In-fact they are better; Standards based code "plays nice" and inter-op across frameworks and platforms (With the exception of virtual DOMs that doesn't give a damn about anything). TLDR => Use standards (with polyfills for now) and you still have reduced code size and better developer experience, with the power porting of code across applications, etc. I published a post about the expensive price we all pay (developers as well as software companies) because of us being held prisoners by library "sandboxes". Read here if you have ~5 minutes .

Imagine this: Visiting a website (or downloading a file): Client texts Server: "Hey, send me X please" Server texts Client: "Here it is: [data]" Now compare this to a socket connection: Client calls server: "Hey, whats up?" Server: "Hey, good, i'm holding the phone, talk to me when needed" Client: "Sure, and if you have something to say, I'm listening" .... Time passes by ... Server to client: "Hey you there? I just wanted to tell you [data]" ... Time passes by ... Client to server: "Hey what about X?" ... and conversation goes on ... Now the side effect of a TCP socket connection is that the server needs to "hold the phone" for all incoming traffic and communicate with them. As opposed to simple HTTP requests ("SMS messages") that can be cached or delegated - it requires more resources.

I partially agree with you. Read my publish about it if you have time (5-6 minutes read).

Quick answer: Impossible. Long answer: Possible to mimic. Drag and Drop and define the wrapping div of an iframe as the drop-target (most libraries support that). Once it is dropped you should use your preferred messaging API between the iframes and "inform" the iframe that it should handle the drop event. You can pass strings (and use JSON data if needed) - on the "other side" (inside the iframe) your code should be able to handle the drop. I'm not sure about how much support you can get if you want to drop into specific portions of the iframe, If I had to do it I would check if it is possible to calculate the x/y position of the drop, then on the "other side" calculate what is positioned there and respond accordingly. It's going to be rough, but possible. Good luck.

Basically not all tags are "self-enclosing" and require a full tag closing. But most browsers 'ignore' this and complete the tag closing automatically and vice-versa removing extra closing when invalid. There's a list of "void tags" (self closing) here . All "void tags" should never contain any text or child nodes. <br/> is an example. <textarea /> is another. These cannot have children.