Announcement

Collapse
No announcement yet.

HHVM Continues Beating PHP At Its Own Game

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by Zan Lynx View Post
    Oh I love those angular sites. I hit one from a search link, see absolute garbage because I use NoScript, so I hit back and try another link until I find something that you know, actually uses HTML.
    Same. If a developer can't restrict the "behaves like an opaque application with no fallback" stuff to things which actually need it, like <canvas>-centric apps, then I just assume the developer is incompetent to the point of untrustworthiness and go look for a more competent, reliable source.

    (Can you tell that I'm a UI/UX specialist and a strong adherent to the progressive enhancement design philosophy?)

    Comment


    • #12
      Originally posted by Zan Lynx View Post
      Oh I love those angular sites. I hit one from a search link, see absolute garbage because I use NoScript, so I hit back and try another link until I find something that you know, actually uses HTML.
      if you are using noscript you cannot even see a simple dropdown menu and noscript allow some scripts to make works some sites, e.g google transtale, google search, etc. Besides of the hystory and technology of the dinamically web sites, talking about performance , which is more fast? An angularJs/emberjs/knockautjs/etc apps? or a php/python/+template system web page?
      Last edited by cocklover; 13 March 2015, 11:31 PM.

      Comment


      • #13
        Originally posted by cocklover View Post
        if you are using noscript you cannot even see a simple dropdown menu and noscript allow some scripts to make works some sites, e.g google transtale, google search, etc. Besides of the hystory and technology of the dinamically web sites, talking about performance , which is more fast? An angularJs/emberjs/knockautjs/etc apps? or a php/python/+template system web page?
        Honestly? It depends on what you're doing.
        If all you're doing is changing a few parts of the page, JavaScript is faster 99% of the time. However, if you're working with any moderate amount of data being passed back and forth or modified, PHP/Python/Ruby/etc sites with optional AJAX are going to be MUCH better in the long run.

        /me is n00b web programmer

        Comment


        • #14
          Originally posted by Daktyl198 View Post
          Honestly? It depends on what you're doing.
          If all you're doing is changing a few parts of the page, JavaScript is faster 99% of the time. However, if you're working with any moderate amount of data being passed back and forth or modified, PHP/Python/Ruby/etc sites with optional AJAX are going to be MUCH better in the long run.

          /me is n00b web programmer
          Which is why there's so much appeal to Node.js. It helps to close the gap between "easy now" and "better in the long run" by allowing developers to use the same JS-based model and templating code on both the server and the browser.

          Comment


          • #15
            Originally posted by ssokolow View Post
            Which is why there's so much appeal to Node.js. It helps to close the gap between "easy now" and "better in the long run" by allowing developers to use the same JS-based model and templating code on both the server and the browser.
            Two things:
            1. The "easy now" is subjective. If you're very proficient with Django and moderately proficient with JavaScript, then obviously using Python as a backend would be easier to you.
            2. As a noob programmer, I don't understand what you mean when you say "using the same template code on both the server and browser". My only interpretation of that makes me wonder why you would be using server-side structures on a client and vice-versa. Using the same model on both sides probably decreases complexity by a lot though, so it's got that going for it.

            Comment


            • #16
              Originally posted by Daktyl198 View Post
              Two things:
              1. The "easy now" is subjective. If you're very proficient with Django and moderately proficient with JavaScript, then obviously using Python as a backend would be easier to you.
              2. As a noob programmer, I don't understand what you mean when you say "using the same template code on both the server and browser". My only interpretation of that makes me wonder why you would be using server-side structures on a client and vice-versa. Using the same model on both sides probably decreases complexity by a lot though, so it's got that going for it.
              1. No argument. I'm one of those "Familiar with Django and moderately proficient with JS" people. Learning a little Node.js, both for its own sake and so I can use Socket.io to write one of my planned WebSockets projects, has been on my TODO list for a while now.

              I'm just saying it's one of the reasons so many people have taken the time to learn Node.js. (The other being how Node.js makes a great, lightweight companion to something like PHP or Django for adding a WebSockets-based feature to an existing application)

              2. If you generate your HTML pages using something like Handlebars.js and the server-side code is Node.js, you can set it up so that the two code paths are:

              No AJAX: Feed the data into Handlebars.js on the server and send rendered HTML to the client.
              AJAX: Serialize the data as JSON, send it to the client, and let the client-side JS feed it into Handlebars.js

              That way, there's minimal duplicated effort when it comes to producing the templates because the non-AJAX templates can just use the AJAX templates as partials (The Handlebars.js equivalent of {% include ... %} in Django templates)

              Comment


              • #17
                Wow guys, just 6 messages talking about the subject, and then, a war between PHP and Javascript, completely unrelated. I don't come that often, it won't help others it you don't discuss the topic here, hhvm evolutions regarding specs and performance.

                Originally posted by kozzi11
                I do not think that phoronix test suits depends largely on db operations. But on the other hand, because of hhvm I find out one problem in our ORM layer. And 3.6.0 is the first version of hhvm whitch works completely with out any hacks with out codebase.

                And it is realy fast. In some situation it is almost 10x faster than zend php.
                I know, and when I'm using PDO in my own apps to get access to mariadb database, it's working flawlessly. It's just when apps are using direct mysqli the usual PHP way that things get tricky, because HHVM is much stricter on variable types (port must be numeric, where phpmyadmin stores it as a string, and so on). Sometimes it's really easy to work around (cast the type, it takes only 10 chars to add to a single file of phpmyadmin, I could even file a bug and propose the fix myself, after I described it on my blog). Sometimes it's not. That's why I warn frequently about using HHVM even if it's damn fast (a 3 to 5 times faster on my home-server-hosted vm on Debian Wheezy).

                I'll test this weekend if something else is breaking or not, and if I can go deeper on the Leed bug. As I plan to deploy it on my blog, I have to test if nothing breaks with the new version.

                Comment


                • #18
                  Originally posted by cocklover View Post
                  if you are using noscript you cannot even see a simple dropdown menu and noscript allow some scripts to make works some sites
                  I think you should take a look at CSS 3 and HTML 5

                  Comment


                  • #19
                    Originally posted by Zan Lynx View Post
                    Oh I love those angular sites. I hit one from a search link, see absolute garbage because I use NoScript, so I hit back and try another link until I find something that you know, actually uses HTML.
                    Unfortunately, the web is moving further and further into a place where pure HTML sites are the exception and not the norm.

                    The problem with building a website using the progressive enhancement design philosophy is that it's a lot more work. Few toolkits these days work with progressive enhancement, so to do progressive enhancement you either have to restrict your selection of tools or build something from scratch.

                    Comment


                    • #20
                      Originally posted by Michael_S View Post
                      Unfortunately, the web is moving further and further into a place where pure HTML sites are the exception and not the norm.

                      The problem with building a website using the progressive enhancement design philosophy is that it's a lot more work. Few toolkits these days work with progressive enhancement, so to do progressive enhancement you either have to restrict your selection of tools or build something from scratch.
                      You basically end up doing twice the work if you want the app to be usable without JavaScript or at least some what SEO friendly. It fucking sucks.

                      Comment

                      Working...
                      X