4 ms·

Once your browser has loaded the page, it's always (and I mean 100% of the time) more efficient to get whatever data you need from your server in the form of JS

Once your browser has loaded the page, it's always (and I mean 100% of the time) more efficient to get whatever data you need from your server in the form of JSON, and then use that json to update ONLY the part of the page that is changing. Even if your entire DOM tree is changing that's STILL no excuse to do a page reload. The only page reload that ever needs to happen is when the user first browses to your url.

ec109685 10y ago
Why do you think executing JavaScript to render a piece of content fetched from the server as JSON is always more efficient? Browsers are really efficient rendering HTML, so it all depends on how complex your JSON to DOM element transformation is. With async parsing / loading of JavaScript, your new page can be rendered before the JS is even loaded, so the extra initializaion per page view is hidden from the user. Which site feels better, yours or Wikipedia?
- ClayFerguson 10y ago
  My site is not finished, so you can't judge it by the experience. However, it is most definitely vastly superior to Wikipedia. meta64 is hierarchical like a directory tree, and can go to any depth. I haven't written the whitepaper yet, but my design makes wikipedia look like the ancient artifact it truly is compared to meta64. All my API is fully JSON up and JSON down(REST-like), and is like a microservice api. The server is a service with an API. The javascript client is in control of rendering the data it gets from the server. I'm convinced that's the most efficient design.
  - Isofarro 10y ago
    Yoiks. 12 seconds until the first piece of content is displayed (compared to Wikipedia's 0.6s). That there (TTFC - Time to first content) is the perennial problem of client-side apps, the inability to get the first piece of content immediately to the user. Since you say it's all JSON APIs, it should be trivial to build something on the server to server-render the initial page with content and serve that up while the rest of the application tries to download itself into the browser.
    - ClayFerguson 10y ago
      if I had minification on, your comparison would be apples-to-apples. I have it off for now, for debugging. Also my APP installs itself the first time you visit the page. Think of it as an APP INSTALL. Wikipedia is NOT an app, and has nothing to install.
      - Isofarro 10y ago
        Thinking of it as an app install feels like an anti-pattern. Like when you turn on the Xbox for a quick five minute play, and have to sit through a 15 minute update before you can even do anything. It's a bad user experience. This approach was a commercial failure on the native platform level (those Office-like app suites with network install of components each time you needed them). It was also a commercial failure on the "build my desktop from scratch when I boot up" environments. It yet another tick in the "does not belong in a browser" list. Perhaps Single Page Applications need to run inside a window where there's no browser navigation bar, no url bar. Stripped down so far it's not actually a functioning browser. That feels very much like a native GUI library at that point. Except for that ludicrous notion of the app needing to be installed each time the chrome/window is launched. I can't see how "install the app each time you land on this website" is competitive against native's "install this app once, and run many times" approach.
        ClayFerguson 10y ago
        A well-designed web app will have a version number embedded in the filename(s) of the large file(s), (like the filename of a minified JavaScript file containing the entire app) so that upon first visit to the page the app is downloaded and "installed" (cached), but on subsequent visits your browser grabs the file from its local cache. This is really a seamless and excellent form of deployment, and when done correctly the browser only waits for new downloads when a new "version" of the app has been deployed to the server. So well written SPAs like meta64 do have the "install this app once, and run many times" behavior.
- deleted 10y ago
  [deleted]

ec109685 10y ago

Why do you think executing JavaScript to render a piece of content fetched from the server as JSON is always more efficient? Browsers are really efficient rendering HTML, so it all depends on how complex your JSON to DOM element transformation is. With async parsing / loading of JavaScript, your new page can be rendered before the JS is even loaded, so the extra initializaion per page view is hidden from the user. Which site feels better, yours or Wikipedia?

ClayFerguson 10y ago
My site is not finished, so you can't judge it by the experience. However, it is most definitely vastly superior to Wikipedia. meta64 is hierarchical like a directory tree, and can go to any depth. I haven't written the whitepaper yet, but my design makes wikipedia look like the ancient artifact it truly is compared to meta64. All my API is fully JSON up and JSON down(REST-like), and is like a microservice api. The server is a service with an API. The javascript client is in control of rendering the data it gets from the server. I'm convinced that's the most efficient design.
- Isofarro 10y ago
  Yoiks. 12 seconds until the first piece of content is displayed (compared to Wikipedia's 0.6s). That there (TTFC - Time to first content) is the perennial problem of client-side apps, the inability to get the first piece of content immediately to the user. Since you say it's all JSON APIs, it should be trivial to build something on the server to server-render the initial page with content and serve that up while the rest of the application tries to download itself into the browser.
  - ClayFerguson 10y ago
    if I had minification on, your comparison would be apples-to-apples. I have it off for now, for debugging. Also my APP installs itself the first time you visit the page. Think of it as an APP INSTALL. Wikipedia is NOT an app, and has nothing to install.
    - Isofarro 10y ago
      Thinking of it as an app install feels like an anti-pattern. Like when you turn on the Xbox for a quick five minute play, and have to sit through a 15 minute update before you can even do anything. It's a bad user experience. This approach was a commercial failure on the native platform level (those Office-like app suites with network install of components each time you needed them). It was also a commercial failure on the "build my desktop from scratch when I boot up" environments. It yet another tick in the "does not belong in a browser" list. Perhaps Single Page Applications need to run inside a window where there's no browser navigation bar, no url bar. Stripped down so far it's not actually a functioning browser. That feels very much like a native GUI library at that point. Except for that ludicrous notion of the app needing to be installed each time the chrome/window is launched. I can't see how "install the app each time you land on this website" is competitive against native's "install this app once, and run many times" approach.
      - ClayFerguson 10y ago
        A well-designed web app will have a version number embedded in the filename(s) of the large file(s), (like the filename of a minified JavaScript file containing the entire app) so that upon first visit to the page the app is downloaded and "installed" (cached), but on subsequent visits your browser grabs the file from its local cache. This is really a seamless and excellent form of deployment, and when done correctly the browser only waits for new downloads when a new "version" of the app has been deployed to the server. So well written SPAs like meta64 do have the "install this app once, and run many times" behavior.
deleted 10y ago
[deleted]