by mathewsanders on 8/6/21, 6:20 PM with 90 comments
We’re using a headless CMS with content in the page broken into hundreds of individual elements, where a React client app renders the data from the CMS API to our users.
In addition we seem to be grabbing the PDFs from the server, converting to Base64 and then rendering as an object in the react app (rather than just linking to the pdf file directly).
The team (4 developers, 1 automation/QA, 3 designers, scrum expert, product owner and product manager) is in their second quarter working on the site, and aiming to release this MVP next quarter so around 9 months to build 15-to-20 page site.
When I started my career 20 years ago, this is the type of project where maybe 2-3 people would build out over a few weeks.
When Content Management Systems were first introduced, one of their selling points was that it reduced reliance on developers for ongoing BAU content updates as ‘business people’ could make content updates and potentially even some sort of workflow to have reviewed or signed off (perhaps by compliance etc) with our set up the CMS is so complex that we’ll have any requests for changes submitted to team and have a developer make the update.
What benefit do we get from this complexity compared to just having static HTML pages that someone would update manually?
There are no concerns from our project sponsors around how long this is taking or the costs involved.
How on earth did we get to this stage where such bizarre complexity is accepted as normal?!
by yongjik on 8/6/21, 6:35 PM
A more objective take would be simply that "they don't know better." Hire a bunch of junior developers right out of college, and throw them in a pool of layers, and they'll think this is how "a real job" is done - they've never seen anything better. It doesn't help that their go-to example of best, most polished websites (imagine google docs) are built by hundreds of engineers, with as many layers.
Once it becomes an ingrained culture, it would be extremely hard to turn around.
by runawaybottle on 8/6/21, 9:03 PM
Now, types in Typescript for every little thing means you are a good developer. Not necessarily judicious use of types and small type footprints, but insane obsessive, compulsive, exhaustive list of types for even the most basic function signature. This is what it means to be a good developer.
What we lack as a group is the ability to have a sit down in the current and say ‘some of this is not needed, we tried it, it’s always worth a trying, but perhaps we can cut down on some of this granular component composition, perhaps we can only use a little bit of typescript, perhaps we can reduce state management’.
We don’t have the mechanism to self-reflect, so our only form of healing is to keeping barreling forward. In other words, lie to ourselves, and run from the problem.
by kilroy123 on 8/6/21, 10:25 PM
Just yesterday, I needed a function that consumed some data from an endpoint, and did one of two things:
- Open a window with a PDF in so the user can print.
- Focus a god damn input field in a form.
That was it.
My manager, who isn't even a "front-end" guy, took my PR. Then changed it to some overly complex mess with an entire separate file. Huge comments. Overly built for a hundred different use cases and did it "the react" way.
We're literately opening up a new window or focusing an input.
I tried to push back but it went nowhere. He's right and I'm wrong. Never mind my 10+ years in the industry. He's the manager.
by bjourne on 8/6/21, 10:24 PM
We can assume that alienation is rife in the software industry. Someone writing a module for some extension interface for some in house editing tool for the accounting department may not care much. So they prioritize other things. An engineer wants to learn new programming languages because it looks good on their cv and a manager wants to lead large groups because it also looks good on their cv. Thus overcomplicated projects written in newfangled programming languages is in both their best interest. Especially if they are contractors. Then the simplest solution is almost always the wrong one.
by jaredcwhite on 8/7/21, 1:05 AM
It's actually worst practice for all but the largest companies and teams. We as an industry need to start doing a much, much better job communicating to all relevant parties that the best way to build most web sites/apps most of the time will look radically different from how Big Tech does it, and that's actually expected and reasonable.
by tacostakohashi on 8/6/21, 6:59 PM
> What benefit do we get from this complexity compared to just having static HTML pages that someone would update manually?
In the good old days, HTML was simple because it was just text + <h1>, <p>, <b>, etc markup and HTML forms, and web authors were ok / expected that the web browser would do the heavy lifting and render it appropriately for the client OS using native toolkits / widgets.
These days, the publisher wants 100% control over everything, so all that rendering / toolkit that was previously left to the browser is re-invented in JS.
Ask your superiors why you need to embed a PDF viewer in your page instead of just linking the to PDFs and letting the client open it in their local browser / Acrobat / PDF-viewer of choice. They'll probably mumble something about a consistent experience, what if the user doesn't have acrobat installed, etc.
by chrisrickard on 8/6/21, 11:13 PM
Ajax spawned "Web 2.0", which in turn spawned the batteries-included-JS-frameworks (which overtook simpler libraries & plugins). Resume driven development then made them the standard, and we now have a generation of programmers who think a GET request only returns JSON, and were never taught it can also return HTML ;)
by cblconfederate on 8/9/21, 10:03 AM
> The gateway to the law is open as it always is, and the doorkeeper has stepped to one side, so the man bends over to try and see in. When the doorkeeper notices this he laughs and says, "If you're tempted give it a try, try and go in even though I say you can't. Careful though: I'm powerful. And I'm only the lowliest of all the doormen. But there’s a doorkeeper for each of the rooms and each of them is more powerful than the last. It's more than I can stand just to look at the third one.”
by alex504 on 8/6/21, 10:39 PM
Technologies have improved, and requirements have gotten more complex. It sounds like the team you are working on is either doing things in an awful way or the requirements are such that there is a lot that needs to be done.
20 years ago it was very difficult to build anything remotely complex. 2-3 people could build a very simple, static site over a few weeks. If you showed web developers 20 years ago what a modern web app looks like today they would be impressed.
It is certainly possible to use a bunch of technologies that complicate things unnecessarily but even then it shouldn't take 9 months for four engineers to build a simple site.
by david927 on 8/6/21, 6:53 PM
Good architectures (think both software and construction, both) only use what they need. They are complete not when there is nothing left to add, but nothing left to take away. Good architectures make changes and extensions effortless.
Instead, as Alan Kay says, "Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves." He said that a while ago and it's getting worse.
by csomar on 8/6/21, 9:25 PM
HTML has become complex to account for new features that users want. So did CSS (which makes you rely on SASS) and so did JavaScript (and now you complex apps require a strong-typed language like TypeScript).
A few years ago, HTTPS was used by prominent websites only. Now, it's required for even the simplest website. Implementing HTTPS can be simple (if you use Cloudflare) or a bit complex. (if you are running Nginx). But the complexity level did definitively increase.
by midrus on 8/7/21, 5:47 AM
At my last job I was horribly looked down at when suggesting doing simpler things. People want to master a single gold hammer and use it for everything, no matter what the business problem is. React is THE WAY, Go is THE WAY, kubernetes is THE WAY and now it doesn't matter (we don't even think about it!! what's the actual f**ng business problem we're trying to solve). We just use THE WAY tools because otherwise we're doing "legacy".
It's sad, really sad.
by is_true on 8/6/21, 9:17 PM
They all worked in marketing an their company had them do a react course.
by BitwiseFool on 8/6/21, 9:42 PM
https://en.wikipedia.org/wiki/Holy_grail_(web_design)
I'm kinda glad I'm back-end only.
by ryalb on 8/8/21, 11:18 AM
I just quit a full time job in a Huge-Non Profit where my main project was to make a simple CRM, based on about 10 simple but intertwined tables. This CRM would have saved the hours of hundreds of overworked/burned out people.
The frontend was made entirely with Bootstrap. A functional, life-saving MVP without any dynamic content could have been made in a month with a team of 3 developers.
However, all of the feedback we constantly got was only to make it look more modern and dynamic (and debatably worse from a UX standpoint).
Mid-development we were forced to add Vue.js to our tech stack. I quit because my conflicts with the business side were becoming hopeless, the project has still not seen an MVP, 1.5 years and two avoidable burnouts in the making.
My thinking is that people feel the need to deliver something as modern and sexy as possible to get more credit. Completely losing track of the functional aspects of things.
by sbacic on 8/9/21, 8:37 AM
The second, and my preferred theory, is that the modern web stack has not adequately followed increasing user requirements, forcing us to take much longer to develop what seems like trivial new features. It's not that i18n, or larger images or maintaining state in the browser is some huge, insurmountable problem that can't be solved. It's just that our tools are so woefully immature that we spend more time wrestling with them than we do actually working on the features we're being paid to work on.
And for what? For some vague illusion of choice that for the vast majority of people doesn't even matter? I don't care if I use Redux or one of the bazillion different variations on the idea. Ditto for Sass, Tailwind or what have you. The web layer needs to solidify already, give us a decent bedrock to build our apps and websites on and just get out of the way.
by relaunched on 8/9/21, 2:02 AM
There are probably a handful of sites that needs this level of engineering. But, for everyone else, that isn't running at a huge scale, it's hugely taxing.
by ipnon on 8/7/21, 2:16 AM
[a] React, Angular, Vue [b] EC2, Droplets, VPS [c] Request, Axios
by sergiotapia on 8/6/21, 7:49 PM
We're also going to use esbuild to compile our very minimal alpinejs code. Most interactivity will be built using phoenix liveviews.
We're hitting the eject button on this whole ecosystem. There is a rot in node/npm that I think will never really go away as it's baked into the culture.
by Graffur on 8/7/21, 8:54 AM
It forces the developer to break things into components which is essential for any maintainable UI.
Since React is the the most popular JS library it is easier to hire for.
SPAs that are done well are a better user experience because the page 'loads' once and then feels faster. That is what users expect.
If a company has multiple sites, it makes sense to be consistent with tech across those sites.
It's ready for future requirements. If you didn't use React and you kept getting requirements for the next few years you would be more likely to end up with a ball of mud if you were doing plain HTML and JavaScript.
One part that I agree seems complicated is the build and dev environment.
by rajacombinator on 8/7/21, 11:00 PM
by jituc on 8/9/21, 7:24 AM
I remember a mid sized saas app of one client, built completely on plain vanilla php,css, javascript(jquery was used) and mysql database.
It was handling millions of request from thousands of paying clients without a hitch. Only fancy thing he did was an automatic backup system using custom script using replicated database. It just works.
by mikewarot on 8/6/21, 7:48 PM
It took quite a bit of convincing to get him to just let text wrap in a web page. Eventually he got used to this new normal.
I suspect much the same is happening here... instead of just letting people see the PDF link, they have to emulate the PDF viewer, and likely other things are being done in a similar vein, trying to keep control of something that should be left up to the browser.
by girishso on 8/7/21, 2:39 PM
by atmosx on 8/8/21, 7:02 AM
That said, the web is complex today because user expectations grew significantly. A website must be compliant with all browsers, mobile ready, save state without users clicking a 'save' button, etc. A CMS might do all that out of the box with boilerplate generic code.
by nojvek on 8/7/21, 3:36 PM
The more people you add to a project, the more the scope balloons in complexity, not faster.
I have seen this play out so many times.
by mbrodersen on 8/7/21, 3:26 AM
by 908B64B197 on 8/6/21, 9:01 PM
You know if you just click the link your browser will render it right?
> There are no concerns from our project sponsors around how long this is taking or the costs involved.
Who and where are these people? And where's your development team?
by mbrodersen on 8/7/21, 3:31 AM
by tored on 8/7/21, 4:34 PM
by p0d on 8/7/21, 4:42 PM
Personally I like to understand what I am writing. My last project was php, bootstrap and plain javascript.
I appreciate that others want to piggy back on the work and support of others. We all do.
by gitgud on 8/8/21, 6:33 AM
That's when the layers of complexity begin to creep in...
by cpach on 8/6/21, 7:38 PM
Makes me curious about the context. I guess it’s a company that maybe has managed to either raise too much money, or prioritized quite poorly where to spend the engineering power…?
by gls2ro on 8/9/21, 6:21 AM
A while ago (maybe 7-10 years), I consulted for a company with over 3000 technical people (devs, sys, support, PMs, POs ...). My work was primarily with management regarding what people now call DX (Developer Experience), another new term that I will not address now.
When I was there, they were starting the transformation from Waterfall to Agile. One of the outcomes of this process was the realization that the teams cannot work agile because their technical architecture does not fit this model. So let's first take a moment to underline this: they did not decide to change the technology because the clients had some needs that their current architectures and technologies could not fulfill, but because their current tech stack did not allow an agile way of working.
They went full-on and hired an external company to teach them the newest technologies and work with them. So here is what happened: these cool new guys who were speaking at dev conferences and writing articles about the future of technology came. After one year, everything was transformed into "Javascript," "Microservices," and Reac. I was first amazed on how much energy both management and employees have put into this transformation, how active they were, how much learning happened. Kudos to them for having that much focus and power to achieve this transformation. Then I participated to an internal hackathon, 2-3 full days, where each team was working on their ideas or projects. What was the result? In the end, many Git repositories with microservices and react apps but almost no real solution for a problem solved. Mostly only designers were the only ones trying to create an interface that could solve the problem they choose. The devs spent most of their days setting up big automated infrastructure, focusing on build pipelines and setting up local and production environments, and losing sight of the main purpose: solving a real problem.
I realized that the main issue with tech companies or any other company is transforming toward an organization or architecture without having the actual need that the new structure solves. Because this way of doing things usually does not leave a lot of room for critical thinking about why something is better or worse as a technical solution. It defaults to using what you already know, but what you already know might not be fit as it was not the result of a kind of organic learning based on encountered problems but was imposed on you by a stronger outside context.
So now, what kind of developers do you think the company hires: mostly young developers that know microservices and react. So every newly started project is a SPA on Microservices.
by k0t0n0 on 8/8/21, 5:43 PM
I worked on a recent project where after spending 1 year they still don't have a basic auth working.
by muzani on 8/7/21, 9:10 PM
by eurasiantiger on 8/6/21, 6:28 PM
Scalability. Scalability is the answer.