Ask HN: Are there any solid arguments against SPAs in 2017?

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.

I think we agree and are misunderstanding each other. Yes if you have an SPA there is no refresh, no throwing things out, and it's good.

Was*, GrooveShark shut down in 2015.

You are correct. My post was not about grooveshark or in any way related to grooveshark.

meta64 is more of an APP than a webpage. For example, opening and closing dialogs is done by creating and destroying a DIV. It's not done by reloading the page, and rendering a new template on the server to send down. The reason I don't want to destroy the state of the DOM and client side variables is this: Have you ever seen a desktop app that resets all its variables back to null when a user clicks a button? Have you ever seen a desktop app that calls its 'main()' routine over and over again? Ask yourself why. There's just no reason to reload everything. Just start the app, and let it run. DOM is perfectly capable of updating the screen/page without a URL request being sent. Sending a url request to update something is stone-age thinking and 1990s design. It's the exact reason the world is moving to SPAs

The browser will maintain the history if you opened the editor in a new page like HN does. For example, if I hit the back button or if there was a cancel button when composing this comment, I would return to exactly where I left off in the full list of comments.

I agree you can get into a slightly weird situation if you hit the back button after composing a new comment but your site would suffer the same.

I tried to reply to your post replying to this about using BACK button, but that is also a disaster for apps. Back button is NEVER used in SPAs. Anyway HN is not showing me a reply button so I can't reply to your actual post to the child node of this.

That scenario is already handled (and arguably a lot better) by the middle mouse button and existing browser functionality.

In a way modern SPAs with a large JS installed payload/app on a browser are very simiar to a 'desktop' app communicating via a form of RPC to some remote services. The main "epiphany" most developers are still missing today is how to make a SPA/WebApp consume ONLY a data-serving API in the browser that gets back ONLY JSON (no HTML) from the server calls, and yet be able to render itself into HTML. The main leap of knowledge is to learn how to do HTML rendering on the browser, and not the client. Let the server be only an raw Data API, that sends back DATA and no presentation. Like Microservices.

Your metaphorical engine weighs a metric ton and it’s very difficult to imagine how it’ll develop into anything resembling a racer. I’d put more effort into the car analogies but they’re making me physically ill.

> The architecture is state-of-the-art.

You should also probably back this statement up with something. Right now it appears to be a lot of self-horn-tooting.

But hey, sure, let’s spend the same half-minute to talk about the code. I open to a random TypeScript file – thank goodness you’re using TypeScript, because the JavaScript you’ve put under version control for some reason would make any non-vendor code in the language difficult to find in this time – https://github.com/Clay-Ferguson/meta64/blob/d9f3740118e8099....

  declare var Dropzone;

Oh okay I guess we’re not using types here

  let config: Object = {
  ⋮
      var submitButton = document.querySelector("#" + thiz.id("uploadButton"));

This… this isn’t how you reference elements in your “state-of-the-art” architecture, right?

  if (!submitButton) {
      console.log("Unable to get upload button.");
  }

  submitButton.addEventListener("click", function(e) {

I guess the state of the art means you can’t use your browser’s debugger. Or it’s just for consistency given that you’re circumventing the rest of the browser too.

  this.on("queuecomplete", function(file) {
      meta64.refresh();
  });

What? I have no idea what this does (`meta64` isn’t declared, I guess because this file is allergic to modules. it also appears to be a singleton or global, neither of which particularly screams “good design” when named in reference to your app) but it looks like some kind of indiscriminate state update given that nothing is being passed to it. Maybe it’s not that, but no time to find out. We’re running out of seconds here.

Wait, back up a moment:

  submitButton.addEventListener("click", function(e) {
    //e.preventDefault();
    dropzone.processQueue();
  });

Isn’t a major aspect of most of these fancy SPA frameworks that you don’t have to do this?

  $("#" + this.id("dropzone-form-id")).dropzone(config);

> This… this isn’t how you reference elements in your “state-of-the-art” architecture, right?

oh no it is. Bonus points for kebab-case when the other two we’ve seen so far are camel. I’m nitpicking style because a meaningless literary device involving cars made me irritable. Sorry.

  let ret: boolean = false;
  for (let file of this.fileList) {
      if (file["name"].toLowerCase().endsWith(".zip")) {
          return true;
      }
  }
  return ret;

That was a useful variable! I would write this:

  return this.fileList.some(isZipFile);

and then probably not write this in the end because it’s a filename check but we’re here to talk about architecture or something, not that:

  const isZipFile = /\.zip$/i!test;

`!` is a macro for bound property access in my state-of-the-art architecture.

  runButtonEnablement = (dropzoneEvt: any): void => {
      if (dropzoneEvt.getAddedFiles().length > 0 ||
          dropzoneEvt.getQueuedFiles().length > 0) {
          $("#" + this.id("uploadButton")).show();
      }
      else {
          $("#" + this.id("uploadButton")).hide();
      }
  }

I would think a F1 racer ninja rockstar architecture would be able to bind the visibility of this button to some state. More bonus points for not using `toggle()` and the same select-by-id antipattern.

  $("#" + this.id("uploadPathDisplay")).html("Path: " + render.formatPath(attachment.uploadNode));

Select-by-id again. I’ve suppressed the urge to gag by this point. `.html()` instead of binding this to some appropriate component? Nothing new. Mysterious global `render` due to declaring things allergy? Par for the course.

Let me know if you would like a review of any other files so I can decline and spare my mental health thanks

> Show me one issue in the code and I will thank you, but you won't find much fault there.

You need to get off your high horse. Not even Jon Skeet thinks he creates perfect code.

Your project is nowhere near "great example of modern architecture in a web app". You depend on mysterious global variables everywhere, mix jQuery with HTML tags hard coded in strings (with classes and everything) and have no unit or E2E tests. I applaud your overconfidence though. Most people are ashame of their code, even when it's ten times better than this.

Serious tip: invest time in learning React+Redux/MobX or Vue. I promise you it will make your life much better once you realize your shortcomings.

«Based on your definition of "giant global variable" the $ in JQuery is also precisely that.»

Which is part of why I haven't used JQuery in ages. The last time I saw someone mention JQuery as a best practice example was arguably a decade ago, if not longer than that. If you are doing things by a book, it's not a book that was written any time recently.

At this point, any library I see that uses a global variable and doesn't support proper module loading is a code smell and a sign that the library is probably not well maintained.

«You may not even know this, but packaging an app into a single downloadable JS file (modules not even necessary) is actually the modern approach. It lends itself to better compression+minification.»

Actually, this has changed a lot in recent years, and your ignorance of how module systems work also shows up here. First of all, you can have compression+minification and modules. Even in the bad old RequireJS days when AMD loaders were state of the art there were good AMD bundlers. With modern EcmaScript 2015 modules (ES2015) there are a lot of great bundler options, Webpack being a particular darling right now, but there's also others.

This sort of bundling, compression, and minification is now seen as the last step in the chain, the job of the application/website developer and no longer something that every JS library under the sun needs to do bespoke. A big reason for this is developer experience (it's easier to debug when everything is a large collection of modules), but it also makes for a better user experience (the final application knows more precisely what modules it needs to operate [tree shaking], and in what order [optimizing bundles for specific use cases/first impressions]).

Overall, frontend web development is shifting to share modules with more backend operations and the node ecosystem's npm (and relatives that piggyback on it like jspm and yarn) has become the package/module management ecosystem of choice. This is great for developer experience, whether or not you are doing your backend development in Node, because you have an easier access to a larger ecosystem of libraries, an increasing number of which are "universal"/"isomorphic" running just as well in the browser as on a server running Node (or app running in Electron or an app running in Cordova).

Furthermore, for some of these platforms bundling+compression+minification isn't even necessary, such as an app or server loaded directly from the filesystem instead of shipped to a browser via HTTP. Even that is changing best practices because HTTP/2 mitigates a lot of the reasons that you even need to bundle in the first place (HTTP/1.x often can only handle a single file per connection while HTTP/2 was designed from the start to bulk download a collection of files in a single connection; the connection overhead being the biggest reason to bundle in HTTP/1.x).

There's a lot of great stuff to learn about the current state of the art with respect to modules and ES2015 and modern frontend development ecosystem if you thought to give it a try instead of sticking to old practices now long considered harmful (not just in JS, even, but in about any language: giant global stateful singletons like JQuery are a miserable antipattern any time they show up in any language in the history of programming).

Combining a response to a few comments here.

> Based on your definition of "giant global variable" the $ in JQuery is also precisely that.

jQuery’s `$` and `jQuery` are giant global variables when you include jQuery as a <script> or by concatenation. When you load it as a module, it adds no globals, which is rather nice. Look at https://www.npmjs.com/package/jquery’s “Babel” section, which is also how you use it with TypeScript.

You also seem to be under the impression that polluting the global namespace is the only bad thing about globals. It’s one factor, but it’s also just generally an indicator of bad design. Organizing global mutable state into singletons and namespaces doesn’t help with this. You’re also crowing about TypeScript but throwing away many of its benefits by not using modules or typings for the libraries you depend on.

> You may not even know this, but packaging an app into a single downloadable JS file (modules not even necessary) is actually the modern approach. It lends itself to better compression+minification.

(ES6) modules actually quite necessary if you want your minifier/bundler to be able to remove unused code reliably. Closure Compiler can only do so much.