6 ms·
"On a shared medium like the web, where content has to run across all OSes, platforms, and browsers, backwards-compatible strategies are far more likely to succ
by jheriko 13y ago
"On a shared medium like the web, where content has to run across all OSes, platforms, and browsers, backwards-compatible strategies are far more likely to succeed than discrete jumps."
This is a valid point, but hits on something that constantly grates with me. We already have something massively more cross platform and performance focused than JavaScript - C. The problem is that the standard library for C is utterly lacking, and there is a lack of focus on developing mechanisms to deploy native code /directly/ across the web.
Don't kid yourself either - all the data being thrown around at the moment is always (always, always, always otherwise it wouldn't even work!) translated into native code in some way - we are already throwing native code around the web, just in a horribly inefficient way. In todays world of sandboxing and virtualisation all of the security arguments that used to be completely reasonable are quite thoroughly invalidated.
I really do believe that fixing this from the technical perspective is not an impossible or even hard problem to solve - I can not stress this point enough. Game developers are constantly re-solving this problem in limited, optimisation focused ways. JavaScript implementations themselves are ultimately built on top of this technology or other technologies built on top of it. The standard libraries of modern scripting languages are possible to use from within the constraints of C. We have already solved all of these problems and there are myriad examples.
On the other hand, the political problem could be intractable... and thats sad.
Worst of all perhaps, C can be made better for performance without much thought or effort, and none of the new languages I see actually tackle this problem, which is quite real and measurable and impacts everything from productivity to the environment - they (quite rightly in many ways) focus utterly on ease of use and massive standard libraries. Why can't we focus this effort on fixing C, or providing a better alternative?
Why are we trying to catchup with native code performance instead of using just native code? Why aren't we improving native code performance in a serious way?
- steveklabnik 13y agoJavaScript is sandboxed, and safe. C......... isn't.
- jheriko 13y agobut it trivially can be - this is very measurable and lots of people do it. see for instance iOS, OS X, Android, Windows 8... actually I can just list the modern operating systems that don't provide such an environment out of the box: (end of list)
- LionRoar 13y agoI can totally understand your frustration that shines through. Basically I agree with you. 8 years ago I saw the start of an explosion of new languages/frameworks/etc. All solving 1 of more things of a bigger problem. To my mind it became too fragmented, too many layers where too many things can go wrong and if not, will have a performance penalty. So I went to a more abstract approach by working visually in models. After some tries I discovered the OutSystems development environment for web applications and am working with it since on a daily base. The advantage of working visually is that I don't know or see what the compiler creates. (of course I encounter some SQL, JS, CSS and HTML) However, sometimes I miss text based coding, so this year I looked around to see if the development situation had become better. In my opinion it has not. There seems to be less fragmentation but that's probably caused by the fact that only a select set survived. Besides that new initiatives have been started. Personally I like the idea of using C as a cross platform language; because it already IS. However, I wouldn't be surprised if the lower levels of the used languages use it already in some form (remember it always needs to go native). Besides that, I think that if C would be the standard then within a couple of weeks you will have language X to C compilers and then have ABC->X->C and then have a webvariant WEB->ABC->X->C while undoubtedly someone will create a Javascript to web to abc to x to c compiler. And than there we are again where we started :) So in my opinion the problem lays with the chains. Some abstraction is needed of course but not several layers on layers. I would like to see more direct to (e.g.) c compilers: JS->C, Web->C, ABC->C, X->C whereby it is not the goal to program in C but have it as an intermediate format. I believe that software development has not grown forward enough. There is plenty movement left and right but not going forward. So, I am back to my visual modelling environment and will check later on...
- flohofwoe 13y agoIMHO the "sandboxes" those OS'es provide are all terribly broken. You'll have to sign your code, you can't distribute your code outside of app shops (either completely impossible like on iOS, or scare-dialogs pop up like in OSX), there are gate keepers which dictate what software gets in the app shops and which don't, and which can remove your app from the shop at a whim. And did you look at the Windows8 Store Apps API? It's a f*cking joke. Innovation doesn't happen in those closed-down environments, only commerce (but commerce depends on innovation).
- derefr 13y agoNative code is, at the bottom of its ladder of abstraction, always held at the behest of some vendor's platform or another. Microsoft, Apple, and Google will never agree on a set of standard C libraries that could be used to build rich, modern graphical applications. If they could, we'd never have needed the web for anything other than the ideas of hyperlinks and intents--everything else could be done with URL-specified zero-install applications. (This was the future portended by Hypercard.) But things didn't go that way. Instead, each vendor built its own walled garden, with its own platform-specific libraries to do the same things. The web, in this reality, is simply our attempt at encapsulating away the entirety of the OS, along with all its platform-specific libraries, as a sort of really-big-BIOS, and then building vendor-neutral platform on top with APIs that will work on every computer, running every OS. But the fun thing is, once we get this web platform nailed down, and it can do everything? Once the OS beneath it is redundant in every respect? We can "molt" the outer layer away. The future of Operating Systems will be the lineage of today's ChromeOS and FirefoxOS, not Windows or OSX.
- steveklabnik 13y ago> The future of Operating Systems will be the lineage of today's ChromeOS and FirefoxOS, not Windows or OSX. Today was my first day using stock ChromeOS on a Pixel as my main machine. It was pretty great. I hope you're right about this future.
- jheriko 13y ago"Microsoft, Apple, and Google will never agree on a set of standard C libraries that could be used to build rich, modern graphical applications." this is probably very true, but it isn't even a real problem. the standard library can be expanded to encompass rendering, audio, networking and co. regardless as to platform nitty gritties we can implement a layer over the top (lots of people do this to make games already). when i look at the web as an approach to being platform independent i see something which is truly quite poorly constructed. the kinds of bugs and problems in the webstack are utterly alien in my world... libraries to work around browser bugs? laying out objects on a screen 'complicated'? its just shoddy all over... especially the browser implementations and the myriad frameworks piled on top of javascript and CSS. coupled with the staggering loss of performance and increase in complexity I have no desire to use web tech to develop my cross platform products - and my native development moves at an extremely rapid pace. i qualify this very heavily with "i know how to do this and have done it alone and in teams many times more often than once" a great example of this is everything already in the C standard library which - whilst it seems simple today now its done - hides a great deal of OS and platform specific details which vendors still disagree on but programmers in that environment are largely (and rightly) unaware of. a quick look into the Win32 apis, X11, BSD socket implementations or the Cocoa/Objective-C stack on OSX will show up just how different the platforms can be in their 'low level' interface for many things.
- azakai 13y agoC is not sandboxed, and C has lots of undefined behavior. For those reasons, it is problematic for the web, which needs to let people view any site from any browser and platform, in a safe way. People have tried to "fix" those issues with C, and usually they end up going pretty far, ending up with stuff like the JVM or CLR.
- jheriko 13y agothis opinion is utterly unjustifiable imo and exactly what i mean by 'the old security arguments are obsolete' your comment suggest that you simply don't understand sandboxing and virtualisation i'm afraid. nor how the technology of the web works down to the metal.
- nkurz 13y agoAre you familiar with the joke that ends with the punchline "I don't know, but he's got the Pope for a driver"? For all I know, you have the knowledge and experience to hold your own, but do you realize that in just this thread you've defended your position by suggesting that (among others) the authors of Emscripten and Rust don't how understand the how the web works at a low level? This seems unlikely. I think you have a good point to make about the indirectness of asm.js, but your style of argument leaves something to be desired.
- pcwalton 13y ago> Why can't we focus this effort on fixing C, or providing a better alternative? asm.js is a way of fixing C so that it's safe.
- jheriko 13y agonot even remotely close. sorry. i would qualify it but i imagine it is wasted based on the comment...
- flohofwoe 13y agoWell you can't get out of the sandbox or even crash the process you're running on with C/C++ compiled to asm.js. To me this qualifies as "safety". Of course you can mess up, fragment the local heap/typed-array and produce memory leaks. But it's all contained.