1. 39
  1.  

  2. 9

    I am not a Marxist, but I do believe the terrible state the modern web is due in no small part to ‘material forces’. The lowly underlings front-end engineers (under)paid to produce this muck don’t have much choice. As Hayek wrote: ‘if you want less of something, tax it’. Mass personal data collection should be taxed out of existence. There should be mandatory performance budgets for tech companies: those found using more bytes, kWh, etc. than alloted should be fined out of existence. We need the economic externalities of these cybernetic abuses factored in, better, these need to be major business constraints. Firms should live or die by whether or not they deliver efficient software. We can’t just pretend that there is no cost to all this worthless tech vapor-culture. Big tech companies like Facebook and Google should be abolished by antitrust or whatever other means. Given the anemic and utterly captured states of contemporary geopolitics, it may be up to non-state actors to stop these toxic flows.

    1. 10

      Someone (I think it was Maciej Ceglowski) suggested treating PII not as a monetizable asset, but as toxic waste. That would go a good way to resolve the issue, I think.

    2. 3

      Django is uncool now ? Guess I’m getting old…

      1. 1

        I guess the author is mainly referring to doing server side rendering with Django. At least to me there is no reason why the mentioned API cannot be using Django while still adhering to the ‘cool’ SPA pattern.

      2. 3

        React has a lot of momentum online. Until some counter-movement of simplification gets results and spreads the word, React devs can always point to Facebook and ask “what have YOUR ideas got done?”

        1. 4

          I can again point at Facebook and say that it started with PHP templating.

        2. 3

          I wonder if something like Phoenix Live View will end being the the technology that unseats React?

          Interactivity is definitely a a strong attractor. For me, my recent projects have definitely been JS focused, as opposed to rendering on the server side, though that is mostly due to finding gotoB.js.

          The one problem with technologies like Phoenix Live view, is that absent a very easy way to keep track of clients on the server (which Live view provides), it’d be hard to graft onto existing web frameworks. C# might be able to graft something like that in, Python and Ruby would struggle a great deal with all the multiprocessing/async that would be involved for them, at least I’d think so.

          1. 1

            I’ve been thinking about this one a lot, so much so that I decided to do a medium-ish project using primarily Phoenix templating, including LiveView. My takeaway so far has been that, while the experience overall has been positive for me, I think “unseating” is going to be an uphill battle (although not impossible).

            One issue is that React just has so much momentum right now. The ecosystem is huge, and more and more developers joining a team or starting a project are going to reach for React quickly for reactive interfaces (or at least be willing to). One consequence of that is the ecosystem for both code, utilities, and even tutorials or documentation are feeling more and more weighted towards React and its ilk.

            An example of the ecosystem note above was looking at headless. All of the options out there provide dead simple utilities for React + JavaScript integrations. If they do have options for server-side rendered examples, Elixir isn’t on the list (at least I haven’t seen it). Granted, this is specific tooling was often designed for use with the “JAMstack”, but it’s still indicative of the hurtle in front of another piece of technology on the client to take a sizeable piece of market share from the incumbents.