12 votes

In defense of the modern web

9 comments

  1. [4]
    Akir
    Link
    The big problem I see in this piece is that the author talks about ways in which a JS-rich page / application can improve on things, but the problem is that it often isn't. Furthermore, when a...

    The big problem I see in this piece is that the author talks about ways in which a JS-rich page / application can improve on things, but the problem is that it often isn't. Furthermore, when a standard HTML element is replaced by a customized element I find it common to see that expected functionality doesn't work.

    A good example of this is the dropdown input selector. Very often I see these super stylized dropdowns that I somehow can't select with the tab key even though it's inline in the form. When I click on it, it doesn't give me the option to jump to a selection based on which letter I press on the keyboard. On the other hand, a very small selection of dropdowns I have seen customized actually extend this functionality by adding search functionality when you start typing. This is obviously a better solution than even the default HTML version, but it's still seen far less often than the broken variations.

    Of course, frameworks are supposed to save us from this problem. But there are quite simply too many frameworks, and your framework is never going to handle everything, so you'll have to add another one, and that just adds yet another layer of bloat. How many other useless modules am I going to have to download just to be able to have the style dropdown that this designer wants?

    Honestly, the largest problem with arguing with pro-SPA people is that there is an ephemeral problem with quality when it comes to JS applications. Developers simply don't know what is happening to their codebase at a low level. It most often comes across when you have a broken or slow website, but I think the most telling sign is actually much simpler - when a form does not use any of the HTML5 input types. It seems stupid, but since every SPA developer talks about how much better their UX is I think it's important. If I tap on a field asking for a number and the alphanumeric keyboard pops up on my phone, your app has a glaring design flaw. And this is a design flaw that I see absolutely everywhere.

    If you are the type of person to handle every last detail like this, I would congratulate you. You are clearly the cream of the crop. But the problem is that most people are not, and few businesses will care about these nuances.

    13 votes
    1. [3]
      Wes
      Link Parent
      This can partially be blamed by historically poor mobile support for input types tel and number.

      If I tap on a field asking for a number and the alphanumeric keyboard pops up on my phone

      This can partially be blamed by historically poor mobile support for input types tel and number.

      4 votes
      1. [2]
        Akir
        Link Parent
        According to caniuse, tell has been supported by the major browsers since 2011 and number has been supported for about as long except on Firefox desktop. But then again it doesn't look like they...

        According to caniuse, tell has been supported by the major browsers since 2011 and number has been supported for about as long except on Firefox desktop. But then again it doesn't look like they have historical data for most mobile browsers.

        I know that mobile browsers don't tend to implement the whole spec for number in particular, but those extras can still easily be added with JS if required.

        4 votes
        1. DrStone
          Link Parent
          The number input type has enough problems that the UK design team switched to inputmode, which has less much historical support. I can't this other article now, but I remember reading about more...

          The number input type has enough problems that the UK design team switched to inputmode, which has less much historical support. I can't this other article now, but I remember reading about more issues and mobile keyboard inconsistencies when using number/tel. It's a bit of a mess.

          4 votes
  2. [5]
    Macil
    Link
    I love this description of what other web frameworks do badly that React does well: I've always said that one of the biggest benefits of React is that it lets you write your "first render" code...

    I love this description of what other web frameworks do badly that React does well:

    I'm not aware of any other platform where you're expected to write the logic for your initial render using a different set of technologies than the logic for subsequent interactions. The very idea sounds daft. But on the web, with its unique history, that was the norm for many years — we'd generate some HTML with PHP or Rails or whatever, and then 'sprinkle some jQuery' on it.

    I've always said that one of the biggest benefits of React is that it lets you write your "first render" code and your "update the view" code as one thing. Other systems where you have to write those things separately in different styles and places are tedious, error-prone, and often push people to skip implementing "update the view" behavior.

    9 votes
    1. Wes
      Link Parent
      I considered that the standout quote, too. It really is crazy how many languages are needed on the web. The big three being HTML, CSS, and JS of course, but a server-side language like PHP is...

      I considered that the standout quote, too. It really is crazy how many languages are needed on the web.

      The big three being HTML, CSS, and JS of course, but a server-side language like PHP is often needed as well. And sure a bit of jQuery couldn't hurt. Want a database? There's SQL for that. Working on a bigger site, maybe you should add Sass or TypeScript. Of course to configure that server you'll need to get familiar with the black magic of .htaccess. Great, now you can build your website.

      I'm used to this approach, but it really is insanity. I completely understand the argument that we should be unifying under the JS banner.

      I'm also a huge fiend for performance, and want the web to be as quick as possible. I'm consistently blown away at the amount of wasted bits that get spent on sending bloated CSS and JS down the pipe. Sometimes this is due to a heavy framework, as in the case of reddit's redesign. Sometimes it's just devs that are far too used to having a gigabit connection, and don't realize how slow their 5MB site is.

      I agree with the author's optimism that this approach can be made to work. The technology for SPAs started off as relatively experimental (look at Angular vs AngularJS), but it's improved with time. Newer, lighter frameworks continue to emerge (Vue, Svelt) which offers compromises for those who don't need an entire React stack.

      Additionally, improvements to the browsers themselves will be better-tailored to these new paradigm. APIs like WebComponents and the shadow DOM are suited to the component-based nature of most SPA frameworks. The module system introduced in ES6 replaced the older module system used in node and babel. These innovations and experiments tend to get introduced into the browser spec when they work, and this keeps things lighter for the actual websites serving content.

      Give the new paradigm some time - it'll get there, too.

      8 votes
    2. NaraVara
      (edited )
      Link Parent
      I think it's sometimes worth reminding people that in the "good old days" of the web, most sites would force you to watch some kind of Flash based splash page that would lag your computer out even...

      I think it's sometimes worth reminding people that in the "good old days" of the web, most sites would force you to watch some kind of Flash based splash page that would lag your computer out even if you had a perfect connection. And you'd keep getting random notices that RealPlayer needs to update. So it's not like websites were ever truly "lightweight." They could be, but the drive to shittify them comes from clients, not any inherent issues with the underlying technology or frameworks.

      7 votes
    3. [2]
      imperialismus
      Link Parent
      Here is a platform that works like that: video games. You do not write your engine or interaction logic in the same language as your shaders. Many games will also use a scripting language for...

      Here is a platform that works like that: video games. You do not write your engine or interaction logic in the same language as your shaders. Many games will also use a scripting language for certain things.

      I am on the completely opposite end of the spectrum with this. I’m a big fan of domain-specific languages that don’t try to do everything, but do one thing very well. Some languages allow you to embed them very easily into a more general language, but JS is not well suited to it.

      It doesn’t help that JS itself is not a great language. Why do people adopt TypeScript? Because it’s JavaScript, but safer and less error prone.

      If you want your site to work everywhere, there’s no getting around HTML and CSS anyway, and as far as I know, React doesn’t do away with them totally either. SQL is the native language of databases and it’s actually perfectly suited to them, in a way that Javascript and any other language is not. Any high-performance application interfacing with a relational database doing anything less than trivial will end up having SQL. An ORM is great for basic stuff, but any ORM worth its salt provides an escape hatch for when you need it.

      I simply don’t see why it’s a negative to use different technologies that are suited to different domains. If you understand the domain, you can learn the domain-specific technologies, if you can’t, you probably didn’t understand it well enough to not screw it up in Javascript anyway. I’m not saying that every single component of your application needs its own bespoke technology, but there is a middle ground.

      Am I old-fashioned for thinking it’s easier to read the basic structure of a DOM in HTML than it is in Javascript? Maybe I am, but on the other hand, HTML is made only for structure, not styling or behavior, so it makes sense that it does that thing well.

      3 votes
      1. Macil
        Link Parent
        I don't mind the difference between HTML, CSS, and JS/TS; React isn't about getting rid of that division, though it can make it more convenient to work with that division. (You can group the HTML,...

        I don't mind the difference between HTML, CSS, and JS/TS; React isn't about getting rid of that division, though it can make it more convenient to work with that division. (You can group the HTML, CSS, and JS for each component together, instead of having separate HTML, CSS, and JS files that are kept in parallel. Imagine having your code, shaders, models, and texture files for a lamp inside one folder together, easily copy-able between projects, instead of having one big shader file that has the lamp's shader somewhere in the middle, one big model-pack file with your lamp's model somewhere in the middle, etc, and when it comes time to copy the lamp between projects, you're hunting through each of the files for lamp-related stuff and repeatedly having to test whether you got everything that's necessary because the files only have implicit dependencies on each other and the system can't report you're missing some. Depending on how you use it, React lets you have your components declare explicit dependencies on what they need.)

        React is more about making it so you don't have multiple different systems producing HTML for your "first render" code vs your "update the view" code. In a classic PHP web app, if you want an interactive widget to be on the page at the start, then you need to write PHP code that produces the HTML for the widget with the right data inside of it, and then you need to write Javascript which recognizes that widget on the page on load, adds the interactivity, and for re-rendering the widget with new data, you need to re-implement the HTML template in Javascript that you already had in PHP. Also, you might want to make it intelligently re-use existing elements so scroll and cursor positions inside the elements aren't lost. Also, if any of your Javascript can load in new HTML dynamically, then you need to make that code re-run your widget-finder code on the new HTML.

        To make some game engine analogies:

        • Imagine you have a map editor that lets you set up how the level exists at the start (with level geometry and enemy placement), but you want something to happen midway through during runtime, like some more enemies being spawned or some level geometry being added. What would be nice is if these later additions could also be configured through the same map editor, and marked in some way so the script can spawn them later (and maybe tweak some extra settings at the time). What would be bad is if the map editor strictly only worked for things placed at the start of the game, and you had to place and entirely configure the additions through code only with manual coordinates hardcoded into your script. It would be super awkward if the map editor had a templating system to let you place specifically-configured enemies easily, but then your script couldn't use those enemy templates and had to duplicate the functionality of that templating system for all of the dynamically-spawned enemies. If you ever changed the level geometry in the map editor, it will be easy to move the initial enemy spawns with the level geometry too, but then you'll still need to go back into the script and manually update all the coordinates for the dynamically-spawned enemies.
        • imagine a map editor that lets you place enemy entities and let you connect scripts to them, so whenever they spawn they do some action. Now imagine if instead, the map editor wasn't integrated to the scripts, so to do that, you had to write a script which searched for the specific enemy (maybe by coordinates) to get them to do some action. Now imagine if you then changed that enemy to not be spawned right at the start; now you've got to add some glue code to your script to handle that. Certainly not impossible, but it's not on the happy-path, so you end up avoiding connecting scripts to enemies by default, when if it was easy instead, you'd probably take advantage of that ability more often.

        In these analogies, the level represents the HTML and all the interactive widgets inside of it, and the level editor represents the server-side templating code. Each of the analogies is about bridging the gap between the "first render" and "updating your view"/runtime code paths.

        2 votes