Page 6 of 6 FirstFirst ... 456
Results 51 to 53 of 53

Thread: SIMD JavaScript Support Added To Firefox, Under Review For Chrome

  1. #51
    Join Date
    Aug 2011
    Posts
    28

    Default

    Quote Originally Posted by Pajn View Post
    Then why do you talk as you obviously have no data to back your statements?
    I did tell I was guessing and I didn't have any data.

    Quote Originally Posted by Pajn View Post
    I however, do.
    http://www.w3resource.com/browsers/java-support.php
    The numbers of computers that have Java installed is in fact higher since a lot of browsers
    now have started to block Java until accepted.
    These statistics are gathered from viewers of w3resource.com, whose users are developers. So, they're much more likely to have Java than the average user.

    Quote Originally Posted by Pajn View Post
    Asm.JS is a subset of Javascript yes. A totally static subset that is compiled from a language
    like C, but needs to be compiled again to be run on a processor natively. a.k.a. bytecode.
    Your point is correct, however it still isn't Javascript. Just a Javascript compatible bytecode.
    I don't understand why you call it a "bytecode". You can write it by hand, it's not so hard.
    This is an example (from the specs):

    function diag(x, y) {
    x = +x; // x has type double
    y = +y; // y has type double
    return +sqrt(square(x) + square(y));
    }

    Indeed, quoting from the asm.js FAQs:

    "Q. Why don't you specify a bytecode syntax instead of strange JavaScript idioms?
    A. For compilers like Emscripten or Mandreel, the syntax of a bytecode language simply isn't that important. In fact, most bytecode and machine languages have non-human-readable binary formats. However, we may create a more human-readable surface syntax for asm.js, which could be used for convenient disassembly and human read/write-ability."

  2. #52
    Join Date
    Jun 2011
    Posts
    956

    Default

    Quote Originally Posted by Pajn View Post
    And tailoring for different input types is easy as well. Right now there isn't a ready
    API for asking for touch support but I can check for a platform that will probably
    support touch (includes phone, mobile, tablet or touch in the User Agent) or platforms
    that are nearly always touch (Android).
    And no, I don't have to make any compromises at all.
    If you're tailoring the interface for specific input and screen sizes you're not just 'scaling up' the UI which was my point. Now I will give you that using something like CSS to do this is nicer than having to generate a specific UI file for each interface type.

    Quote Originally Posted by Pajn View Post
    People seems very happy with Spotify even if it doesn't look native. Or look at Android
    where overly other app looks completely different.
    Well just because they're okay with the current situation does not mean they wouldn't prefer a better one

    Quote Originally Posted by Pajn View Post
    And I I do want it too look native everywhere, I can do that. I will just have to write
    platform specific code for every OS, just as I would have otherwise any way. And I can
    still keep all background code the same. Mostly it is CSS that would be changed.
    Yes, and it can be more or less work on the native side depending upon if you're using the Qt way or the Mono way of going cross platform. That said if you've written your software properly the UI layer should be pretty trivial regardless.

    Quote Originally Posted by Pajn View Post
    I guess you mean Xamarin which does NOT run on Jolla and Ubuntu Touch for instance.
    Also it requires writing platform specific code so it isn't even write once compile everywhere.
    Yeah I meant Xamarin, and while Jolla is interesting to me from a user perspective, its marketshare is well past irrelevancy, however if they make it able to run android applications then actually yes I can, also you as stated above also have to write platform or at a minimum form factor specific code in order to make your UI scale so The web is no different here.

    Also while you're focusing on the writing of platform specific code you're forgetting one major thing that makes it so that distribution in a platform specific manner is transparent to end users. The only people downloading and running binaries are using a PC, everyone else is using a distribution network, commonly called an App Store, or on linux a Package Manager to handle software distribution. Which means that a "universal binary" is only a relevant concept within the scope of PCs.

    Quote Originally Posted by Pajn View Post
    What do you mean with "not going full in on the static typing"? If you want to statically
    type everything, then do. It just gives you the possibility to dynamically type it if you
    want (which you can do in languages like C# and Java too, just pass it as object).
    I mean that while it has static type checking in debug mode, it turns off and becomes dynamic type checking in production code.

    Also yes you can do that in C# and Java but using generics and type inferencing variables is generally speaking a much better practice, as you keep static type checking while getting an amount of dynamicism in the code.

    Quote Originally Posted by Pajn View Post
    First, that is much more work.
    Second, what happens to a user that want to run it on a platform for which you
    haven't built it? It doesn't matter if your code could support it or not, it wont help
    the user.
    Much more work here meaning really not a lot more work at all in the modern days of build servers, continuous integration, and virtual machines.

    Second if it's opensource then they can compile it from source if they really want to and it's not my problem (tm), it's the problem of the distribution's specific packagers.

    if it's closed source then not only is it not my problem but it's probably against their EULA or if not there'll be a clause in there that says I'm not responsible for you trying to run it on unsupported platforms.

    Quote Originally Posted by Pajn View Post
    And what about platforms that you can't compile to even if you want, like game
    consoles and smart TVs?
    Smart TVs run Android, e.g. I can distribute through the Google Play Store, so not a problem.

    .NET runs on the Xbox 360, (under development for) the PS3 & PS4, and if Microsoft isn't stupid will run on the XBone, It also runs on the Wii

    On the handheld side the PSVita (AFAICT based on their developer site) exclusively runs .NET, and I can't tell but I'm guessing you can also run it on the 3DS

    Also obviously except for the Vita I can use C/C++ for any of the consoles, and C++ is the go to language for that kind of development anyway, Application distribution is handled either via physical media or through their associated digital distribution system and so as a result multiple binaries are not a massive concern as separate builds are required anyway.

    Finally consoles are typically underpowered enough (the current generation is using netbook CPU cores) that they require device specific tuning in order to approach anything close to reasonable performance with modern graphics. Which means you need multiple versions of the code anyway.

  3. #53
    Join Date
    Jun 2011
    Posts
    956

    Default

    Quote Originally Posted by Luke_Wolf View Post
    .NET runs on the Xbox 360, (under development for) the PS3 & PS4, and if Microsoft isn't stupid will run on the XBone, It also runs on the Wii

    On the handheld side the PSVita (AFAICT based on their developer site) exclusively runs .NET, and I can't tell but I'm guessing you can also run it on the 3DS

    Also obviously except for the Vita I can use C/C++ for any of the consoles, and C++ is the go to language for that kind of development anyway, Application distribution is handled either via physical media or through their associated digital distribution system and so as a result multiple binaries are not a massive concern as separate builds are required anyway.

    Finally consoles are typically underpowered enough (the current generation is using netbook CPU cores) that they require device specific tuning in order to approach anything close to reasonable performance with modern graphics. Which means you need multiple versions of the code anyway.
    I will note I do mobile and desktop development not really game development nor do I target consoles, so people who do please correct me if/where I'm wrong on the language support.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •