4 ms·

What has changed in the limitations of the DOM?

• xemoka 11y ago
  Perhaps not in the limitations of the DOM, but how we deal with it is changing.
  • TheLogothete 11y ago
    Their arguments are just as valid as then. Web interfaces will never be as rich as desktop ones. Cloud connected desktop applications will gain a lot of momentum going forward.
    • vram22 11y ago
      Right, roughly what I said in a parallel comment. Good to see others think so too.
• nostrademons 11y ago
  Quite a bit, actually. Since 2007, we've gotten Javascript JITs, Canvas, WebGL, consistent box models, consistent event models, flexbox, CSS transitions & animations, CSS transforms, localstorage, IndexedDB, websockets, HTML5 audio & video, history.pushState, and several other features. And components (custom elements + Shadow DOM) are coming, and already implemented in some browsers. Pretty much anything you could do in a native Windows app in 2007, you can do in a webapp now, except pwn your computer. Only problem is that the goalposts have moved: now everybody expects you to be able to do it on a phone as well, as well as access the camera, accelerometer (which you can do on the web, actually), contacts, calendar, and bluetooth hardware.
  • TheLogothete 11y ago
    Uhm... the DOM is single threaded and sequential. It will never EVER be comparable to native clients.
    • nostrademons 11y ago
      Web Workers.
      • TheLogothete 11y ago
        Yeah man. I've never heard of those. They sound like the best thing since sliced bread. Only if they could access the DOM... Seriously... what are you even talking about? Why do you even mention them? You read single threaded and thought "Quick, I must come up with an answer! I can't let a stranger on the Internet change my opinion!"?
        • nostrademons 11y ago
          So, it's hard to understand exactly what it is you're trying to accomplish and why Web Workers wouldn't work for you because basically every single desktop GUI framework is single-threaded when it comes to actually updating the components on the screen. Win32 uses the GetMessage/TranslateMessage/DispatchMessage event loop. Swing has the UI thread, and then to update the UI from a background thread, you need to call invokeAndWait or invokeLater and pass a Runnable. Cocoa and iOS have Grand Central Dispatch, and to update the UI you pass a block to dispatch_async on a dispatch queue. Android has you call View.post() with a Runnable that contains your UI modifications. WPF has two threads, a rendering one and a UI thread, and you're supposed to pass long-running operations off to a threadpool and then call Invoke or BeginInvoke with a delegate to actually update the UI from them. Web Workers are exactly this model, applied to the web. It's a dispatch queue running inside a threadpool. To update the DOM, you postMessage back to the UI thread and make your modifications there. Are you willing to let a stranger on the Internet change your opinion?
          • TheLogothete 11y ago
            This is getting tiresome. You cannot access key objects with webworkers. It's a lipstick on a pig. If you want to kiss it, be my guess, but please do not try misguide other people to do so.