<< How about a thread-safe but lock-free version of the DOM based on something like Clojure's atom? So we can manipulate the DOM from web workers? With cursor support?
How about immutable data structures for side-effect-free functional programming? >> and transients! to complete the picture. I think maybe aside from the thread-safe DOM idea, everything below that should belong to the ES7 discussion list. On Tue, Feb 10, 2015 at 1:46 PM, Marc Fawzi <marc.fa...@gmail.com> wrote: > > How about a thread-safe but lock-free version of the DOM based on > something like Clojure's atom? So we can manipulate the DOM from web > workers? With cursor support? > > How about immutable data structures for side-effect-free functional > programming? > > How about .... Will think of more > > Sent from my iPhone > > > On Feb 10, 2015, at 1:09 PM, Jonas Sicking <jo...@sicking.cc> wrote: > > > >> On Tue, Feb 10, 2015 at 12:51 PM, Marc Fawzi <marc.fa...@gmail.com> > wrote: > >> i agree that it's not a democratic process and even though some W3C/TAG > >> people will engage you every now and then the end result is the browser > >> vendors and even companies like Akamai have more say than the users and > >> developers > > > > Developers actually have more say than any other party in this process. > > > > Browsers are not interested in shipping any APIs that developers > > aren't going to use. Likewise they are not going to remove any APIs > > that developers are using (hence sync XHR is not going to go anywhere, > > no matter what the spec says). > > > > Sadly W3C and the developer community has not yet figured out a good > > way to communicate. > > > > But here's where you can make a difference! > > > > Please do suggest problems that you think needs to be solved. With new > > specifications that are still in the development phase, with existing > > specifications that have problems, and with specifications that > > doesn't exist yet but you think should. > > > > Looking forward to your constructive contributions. > > > > / Jonas >
