1. 7

  2. 5

    Just FYI, when viewing in Safari on OSX, the page goes completely blank after a few seconds.

    1. 4

      Hmm, same with firefox on windows. Looks like there’s some javascript error happening here.

      OK, looking into it a little more. This is really strange. At first, the site loads with minimal styling, which is good in one sense, as it gets the content to the user in the quickest manner possible. Then it grabs some more styles and when it’s ready, renders those. I’m a little divided on whether this is the best way to do this, because the change is pretty abrupt. Not a huge deal though, we can live with that.

      But then you realize that the Escher frontend framework is rendering all that content, and a single error is what causes the whole page to go blank. Here is the home page’s source code minus the javascript:

      <!doctype html>
      <meta charset="utf-8">
      <link rel="import" href="pkg/Escher/basics.html">
      <link rel="import" href="pkg/Escher/widgets.html">
      <link rel="import" href="pkg/Escher/tex.html">
      <link rel="import" href="pkg/Escher/codemirror.html">
      <link rel="import" href="pkg/Escher/layout2.html">
        <signal-container id="root"></signal-container>

      What kind of atrocity is this?! Just looking at the HTML structure, the following problems are apparent:

      • All those link tags belong in the head
      • We have a closing div tag, but no opening tag
      • There is absolutely no content in the HTML.
      • Escher is using a non-standard signal-container tag, and injecting content into it.
      • There are 2000+ lines of javascript ON THE INDEX PAGE (that’s more javascript than there is content, not even counting the linked javascript).

      What good are web standards if you aren’t going to follow them? Why are you using javascript, a dynamic language, for static content, something HTML excels at? This disappoints me, as I was expecting something completely different coming from the Julia community, which seems to be interested in doing things the Right Way, for the most part.

      The correct way to do this is firstly, put your content in the HTML. If you want to make it pretty with javascript, that’s fine, even dynamically applying the styles I have no problem with. Just make sure that the stuff that comes from the server could be potentially read (not necessarily has to be able to interactive) with javascript turned off. Especially for blogs and other read only sites. This guarantees that when your JS breaks, the content will still be there. And please quit abusing the DOM with fake elements that don’t exist. (I know, I know, web components are the future, Google said so, yada yada. The folks who actually designed ECMAScript disagree with you.)

      Secondly, use the right tools for the job. Are web components actually necessary for a simple blog interface? Do you NEED 2000 lines of JS to render a blog post? You obviously care at least a little about loading performance, as you took steps to get the page to render quickly on slow connections, but you are defeating yourself by forcing the browser to download tons of JS before it can do anything. If you just put the content in the HTML in the first place, you give the user everything they need to read your article with only marginally more data served than the article text itself.

      Progressive enhancement folks, when did it stop being a thing? Or was it ever a thing?

      Gah, sorry for the lack of coherence there, but I’m fuming over here. This is why the ‘new’ web is getting itself a bad name. Not because it’s broken, but because the big players (Google, Facebook, Twitter) have made it uncool use it the way it was designed. If you aren’t building the next Facebook, you probably don’t need their technologies.

      Just use Jekyll or something similar for your blogs people, there’s no reason to reinvent the wheel. Especially when that particular wheel works really, really well.

      I’m sure Escher probably has a use for something… maybe. All I see though is another React/Angular-esque frontend framework, and I haven’t even bothered to look at the backend.

      I’m just going to leave some frameworks here that actually get it right for the most part.

      And I’m just going to leave this talk too.

      Now I’m going to go take a long walk to cool off before I break something. I’m planning on writing a blog post on this once I get my thoughts more organized.