Second-Guessing the Modern Web

Check out the sibling comments. Complex does not mean hard to use. My car is complex, but it's pretty easy to get a driver's license.

Gatekeeping refers to making it seem like it's too hard to get into and therefore not worth trying for beginners/non-technical folk.

I'm an old dog, almost 20 years programming now. 30 years old. Started with basic, actionscript, java, c# and back to java.

Some guys had an app locally made, European big company acquires them laughed at them and force them to move to a 2019 new entreprisy platform of theirs.

I saw a portal these guys have to manage everything via SSO, they used like 30 different third party apps. Don't get me wrong we use planning stuff, wikis, analytics, but this was excessive.

Anyway, their super app was react-graphql-microservices (40 of them)-redis-elastic search-many dbs-aws services

Performance was horrible, data leaks everywhere, no trottling, google speed complaining. 15 engineers on charge of it.

A team of 1 backend engineer, 1 ux designer and 1 mobile engineer replace THE WHOLE THING in 1 month with: xamarin, rails, postgres with jsonb and fulltext search, s3 and some heroku. Oh about web js, we used some vue.js and I believe some jquery

We were surprised too. As a Java old dog I have seen this before with RIA apps in flex. Fear of missing out makes do stupid things. Warren buffet called them institutional impedance if I remember correctly.

Monolithic with modules is good until you crash with a hyper growth barrier, meanwhile simple is better

> As a user and developer myself, that's the sort of selfish attitude that really really angers your users.

A user is only unhappy if they withhold some money over it.

The core issue is that the web was intended as a document delivery platform, not an application delivery platform. That mismatch means one of two things: you either have to pervert your application to expose a document-centric UX, or you pervert the document platform to look like an application platform.

I would say in 95%+ of cases, perverting your application is the better choice: my core issues with the web now are surprising/malign UX patterns and terrible performance, not cross compatibility or lack of features offered by browser APIs.

That doesn't mean you should forgo JavaScript entirely, but the construction of the UI and UI interactivity should not be its primary responsibility.

> A lot things can be easier if you do things the "wrong way".

> It depends on your setup and use cases whether or not something is overkill, but for any reasonably large app just doing some HTML and javascript is not going to be enough to keep things maintainable...

I don't think you are responding to the point that the previous comment is making. The point is that there is a spectrum from let's say, traditional, to full-on SPA.

When presented with most spectrums of choice like this, it's expected that most people will weigh in requirements first and choose the solution based on the requirements (if they are an engineer, or pretending to be one.) In terms of expertise, they might love to write SPAs, but they realize that the other options on the spectrum exist for reasons other than being in, or out of fashion.

The problem is that some folks overemphasize what's in fashion. There are many reasons for this, and it's something that happens across other disciplines, not just programming. That said, we have a unique situation with programming in that someone can be quite an expert while only understanding one end of the spectrum. It's very easy for these folks to hold sway.

When it comes to the "wrong way", I agree with you, but I'd go further. If the requirements demand a SPA then you need to go all in and use the best modern tools. There are a lot of things created as we moved out of the full page render ages which don't result in good SPA development (for users or devs.) Embrace Typescript, React, etc because these solutions have evolved from that in-between stage.

Using "browser compatibility, accessibility concerns, localization/internationalization" isn't a great argument here. These are often orthogonal requirement. It's easy to argue that full page rendering, or static HTML meets all these more easily. These apps can't compete if you need particular interactive experiences.