3 ms·

> When you write new code in a function or HTTP/event handler, we send a diff of the Abstract Syntax Tree (the representation of your code that our editor and s

• pbiggar 7y ago
  You're exactly right that this style of development would be completely unsafe using PHP+FTP, which is why we had to include all the other stuff: the feature flags, function versioning, DB migrations.
  • voidr 7y ago
    What I was pointing out that hitting save and getting a result on the live server was achievable in the 90s, there is nothing new about it. The reason we stopped doing that is because we wanted version control, we wanted to work in teams and we wanted unit and integration tests, which I doubt that you could run within 50ms. > the feature flags, function versioning I can easily replicate that with at least early 2000s PHP(would probably work with 90s PHP as well). > DB migrations We do have DB migrations in all web frameworks that are worth using.
    • pbiggar 7y ago
      > The reason we stopped doing that is because we wanted version control, we wanted to work in teams and we wanted unit and integration tests, which I doubt that you could run within 50ms. A good way of thinking about Dark is to suppose that instead of stopping doing that, we found a way to make it work. > I can easily replicate that with at least early 2000s PHP(would probably work with 90s PHP as well). If you could replicate it, you'd do it. Except you need version control, unit tests, etc, etc. So you need tooling that has those things to make the feature flags work.
      • thecatspaw 7y ago
        > A good way of thinking about Dark is to suppose that instead of stopping doing that, we found a way to make it work. You found a way to run multiple selenium tests in less than 50ms?
        • necovek 7y ago
          You seem to be married to a particular technology and approach: I would imagine Dark deploys a versioned/feature-flagged alternative in 50ms, allows you to run tests on it, and once you are satisfied, you switch to it in "production" (even if it's already "deployed", it was not "activated: — we could argue that they are using deployed in a slightly different sense than usual). Tests wouldn't be Selenium, and Dark can probably deduce which tests are affected by a particular code change (if it's close to purely functional/no side effects), so it does not need all of them ran. I generally like the idea and approach technically, but wouldn't be using them because of lock-in nature. I also worry about feature flags: for longer lived "features" (they happen!), code ends up being more complex and hard to maintain, and when the time finally comes to drop them, it's a mess.
        • necovek 7y ago
          Note that I am also guessing they are transpiling Dark to JS for the frontend, thus allowing them to use a common infrastructure for everything.
• jrockway 7y ago
  I am not sure people are getting these results with PHP and FTP. Sure, the build time is zero seconds. But each page load takes 100ms because it's doing the same work over and over for every request. Yes, even if you cache opcodes. We have a legacy PHP app and an "echo hello world" request takes 100ms. An extremely complicated request then takes 102ms to process. It is shockingly slow, but it is not something you will notice unless you have a lot of instrumentation, so you might be lead to believe that your performance woes are caused by something else.
  • vrodic 7y ago
    You must be doing something wrong. There's a lot of overhead for frameworks like Symfony, yes. But it's possible to write reasonably productive and modern website code where you can get sub 20ms responses (doing auth, fetching from db, processing and rendering html). I know because I've done that, on PHP 5.4.
    • bbmario 7y ago
      Full checkout experience here, 18ms average. PHP 7.3, Symfony.