5 ms·

As someone on a team working very hard on cutting-edge techniques to improve web development, I disagree entirely. While I complain more than anyone I know abou

by sgrove 12y ago

As someone on a team working very hard on cutting-edge techniques to improve web development, I disagree entirely. While I complain more than anyone I know about the underlying infrastructure, it's a salvageable situation. In fact, because of the lack of standardization on a single toolset or approach (e.g. Cocoa, WPF, etc.), we're in a position to improve well beyond the current SoTA. Some examples: React.js from IG/FB: One of the first opportunities in the browser to treat rendering as a stateless canvas, freeing us from the complexity of time-management. ClojureScript[1] - and more importantly, the immutable data structures from ClojureScript, let us simplify our UI programs conceptually. And combining it with React (Om), we can make UI's both fast and simple Datascript & friends: Bringing entire in-memory databases client-side. All of these, and the wide-open nature of the web as it exists today, means we're in a position to experiment with radically new ideas and find a much more efficient way of representing our goals. It's a really exciting time to be working on this stuff. Nevertheless, I upvoted because I do believe we're in a plato's-cave situation with current practices in web-development. There's very little overlap between the desktop and web world, so many of the lessons haven't carried over - how to manage complexity, the important of tooling, etc. But we're making our way, bit by bit (or more recently, leap upon leap) [1] I'm admittedly biased as I've put considerable amounts of effort into the project, and it's not without its warts. GC pressure can sometimes be very tough, and the tooling needs a lot of work.

d2p 12y ago
The fact that we have great web apps shows that things aren't totally broken; that's not really my suggestion. I just think we need to be thinking forwards and planning for future web apps. What we have is not going to do us for the next 5, 10, 20 years :(
- Turing_Machine 12y ago
  I'm not sure why bolting all that stuff on to machine language is conceptually any better (or any less a "hack") than bolting it on to Javascript. It's all Turing machines/lambda calculus at the bottom, right? Javascript is slower, sure, but (with recent developments) not that much slower. The porting issues involved with making something work cross-browser are much less than the porting issues we used to face in making something work on (e.g.) MS-DOS and Mac. With JS the UI needs tweaking. With MS-DOS and (classic) Mac OS you had to do a full rewrite from scratch. Things are arguably getting a lot better.
  - thsealienbstrds 12y ago
    I think theres something to be said in favor of it. Not all programming languages have js execution model. Does js even support true concurrency already? Not last i checked: there goes a whole class of potentially useful applications. We really do want support for these things. It is good for creativity, therefore innovation, because we have more tools to work with.
    - Turing_Machine 12y ago
      What do you mean by "true" concurrency? I think web workers will use multiple cores, if you have them, but don't quote me on that.
      - thsealienbstrds 12y ago
        True in the sense of multiple cores, instead of just asynchronous execution on a single thread. Anyhow, it was just an example... What I'm trying to say is that we want to really explore the capabilities of the web as a platform for computing, as much as possible. Therefore we need as much flexibility, tooling, languages, you name it, as possible. I'm actually suggesting the 'C++' way of creating a platform... i.e. stuff it with as much flexibility as you possibly (reasonably) can and then let natural selection do its work. JavaScript ain't it.
        Turing_Machine 12y ago
        C++ can be compiled to Javascript that runs at reasonable speeds (not just toy applications, either). See: https://github.com/kripken/emscripten/wiki https://github.com/kripken/emscripten/wiki And yep, I was right. Web workers do make use of multiple cores, and there's at least one parallel programming library that takes advantage of it: http://adambom.github.io/parallel.js/ http://adambom.github.io/parallel.js/
        sgrove 12y ago
        Web workers are atrocious though. They're very strangely hobbled by either requiring a serialize->deserialize round-trip when passing data back and forth, or you can sidestep it by 'transferring' the object across contexts (it then 'disappears' in the original context). The reasons for doing it rather than sharing are obvious (the race conditions would be hard to track down, etc.) - but there's no escape hatch for languages like ClojureScript which has immutable data-structures (and therefore don't care about mutable race conditions) and persistent/structural-sharing datastructures (and therefore would be very costly to serialize/deserialize, or totally broken by the transfer model). Really a shame.
- sgrove 12y ago
  I didn't think that was your suggestion, but I agree with Turing_Machine re: compiling to JS. It's only a slightly more insane API to the VM than x86 is to the internal instruction set on a CPU, anyway. Weird machines all the way down. What we have is a very messy, primordial soup. But the more important things are in reducing complexity (while maintaining performance), and in that realm immutable datastructures, fp, etc. are the (current) clear contenders to lead the way. We'll get there, we should just do our best to make sure we don't repeat the mistakes of the past that have become institutionalized on other platforms - or worse, ignore them and make even more dire mistakes (DOM as the lowest-common denominator, etc.)

by sgrove 12y ago

d2p 12y ago

The fact that we have great web apps shows that things aren't totally broken; that's not really my suggestion. I just think we need to be thinking forwards and planning for future web apps. What we have is not going to do us for the next 5, 10, 20 years :(

Turing_Machine 12y ago
I'm not sure why bolting all that stuff on to machine language is conceptually any better (or any less a "hack") than bolting it on to Javascript. It's all Turing machines/lambda calculus at the bottom, right? Javascript is slower, sure, but (with recent developments) not that much slower. The porting issues involved with making something work cross-browser are much less than the porting issues we used to face in making something work on (e.g.) MS-DOS and Mac. With JS the UI needs tweaking. With MS-DOS and (classic) Mac OS you had to do a full rewrite from scratch. Things are arguably getting a lot better.
- thsealienbstrds 12y ago
  I think theres something to be said in favor of it. Not all programming languages have js execution model. Does js even support true concurrency already? Not last i checked: there goes a whole class of potentially useful applications. We really do want support for these things. It is good for creativity, therefore innovation, because we have more tools to work with.
  - Turing_Machine 12y ago
    What do you mean by "true" concurrency? I think web workers will use multiple cores, if you have them, but don't quote me on that.
    - thsealienbstrds 12y ago
      True in the sense of multiple cores, instead of just asynchronous execution on a single thread. Anyhow, it was just an example... What I'm trying to say is that we want to really explore the capabilities of the web as a platform for computing, as much as possible. Therefore we need as much flexibility, tooling, languages, you name it, as possible. I'm actually suggesting the 'C++' way of creating a platform... i.e. stuff it with as much flexibility as you possibly (reasonably) can and then let natural selection do its work. JavaScript ain't it.
      - Turing_Machine 12y ago
        C++ can be compiled to Javascript that runs at reasonable speeds (not just toy applications, either). See: https://github.com/kripken/emscripten/wiki https://github.com/kripken/emscripten/wiki And yep, I was right. Web workers do make use of multiple cores, and there's at least one parallel programming library that takes advantage of it: http://adambom.github.io/parallel.js/ http://adambom.github.io/parallel.js/
        sgrove 12y ago
        Web workers are atrocious though. They're very strangely hobbled by either requiring a serialize->deserialize round-trip when passing data back and forth, or you can sidestep it by 'transferring' the object across contexts (it then 'disappears' in the original context). The reasons for doing it rather than sharing are obvious (the race conditions would be hard to track down, etc.) - but there's no escape hatch for languages like ClojureScript which has immutable data-structures (and therefore don't care about mutable race conditions) and persistent/structural-sharing datastructures (and therefore would be very costly to serialize/deserialize, or totally broken by the transfer model). Really a shame.
sgrove 12y ago
I didn't think that was your suggestion, but I agree with Turing_Machine re: compiling to JS. It's only a slightly more insane API to the VM than x86 is to the internal instruction set on a CPU, anyway. Weird machines all the way down. What we have is a very messy, primordial soup. But the more important things are in reducing complexity (while maintaining performance), and in that realm immutable datastructures, fp, etc. are the (current) clear contenders to lead the way. We'll get there, we should just do our best to make sure we don't repeat the mistakes of the past that have become institutionalized on other platforms - or worse, ignore them and make even more dire mistakes (DOM as the lowest-common denominator, etc.)