131–140 of 398 posts
We also got faster machines that could handle the buckets of garbage average JS framework asks browser to do and internet speed that made 2MB JS blob the norm and not something you'd be fired over.
It's possible that building a website as a wholistic product (ala Ruby on Rails) is inherently less complex because it eliminates an artificial boundary. We see backend teams struggling to build APIs and frontend teams struggling to consume those APIs. Many of the technical problems, communication overhead, and complexity seem to lie at this API boundary. Consider what if the software team (singular) just created HTML UIs directly from the DB and eliminated the middleman? I'm looking at things like HTMX and phoenix live view as a potential solution.
Unpopular biased opinion. Frontend development is mostly done by people who are into visual things and less into logic. Unlike backend engineering, where people working are primarily choosing technology based on logic/merit and less by visual appearance. This leads to the adaptation of large number of garbage frameworks in frontend primarily because their landing pages look visually appealing. After some time fronten…
Hmm... in the early days of HTML+CSS, there were a lot of visual people in the field. Some of them wrote some JavaScript, but stopped when things got too complex. These days they are doing UX design or create designs in Figma, and don't really touch code anymore.
From manager POV it's great, they don't need to manage 2 teams and can move people from frontend to backend as needed. and then you end with chmod 777 like in old bad PHP days. But hey we put that in container now!
Because the browser nowadays is an "operating system" that needs to be capable of handling all manner of dynamic software: maps, video, image editors, games, etc. I haven't done Windows development, but I assume browser-based development complexity will continue trending towards essentially the same complexity as developing e.g. a Windows program.
Yes, the browsers export a lot of capabilities to the frontend. But you point no reason why the frontends must use those capabilities.
Because browsers don't support server-side declarative views natively yet. FE development wouldn't even be a thing if web servers could respond with something like const [count, setCount] = useState(0); You clicked {count} times setCount(count + 1)}> Click me
But... This is FE development, you think the backend devs would like to be writing this? Back when we all did MVC we had FE and BE devs anyways.
Context: I'm a Rails full-stack developer, I started developing web apps 12 years ago.
I still consider myself a full-stack developer, even if I'm a BE dev right now, since now we have FE and BE in the company I work for.
12 years ago, there were no FE/BE devs: there were only full-stack devs. We used to struggle maintaining tons of imperative JQuery/Prototype/MooTools/you-name-it JS code built on top of server-side declarative HTML.
It was an hell of development/maintenance. Imperative code was pretty easy to write at the beginning, but after 2000 JS LoC you had half of the view implemented in JavaScript. end-to-end testing tools were almost inexistent, so there was no way to avoid regressions on the messy JS code you wrote. After 10000 JS LoC you were pretty f*ked. This workflow was unsustainable for any web app that aspired to appear "modern".
In a couple of years, FE frameworks (AngularJS was the first among popular ones) started facing this problem. They offered you a declarative way to implement dynamic HTML views.
Moreover, companies killed two birds with one stone: they could totally divide FE and BE, so to hire way more developers as junior developers are better suited to work for FE, and reserve the senior ones, with more experience and better payed, for BE. This is another crucial aspect of BE/FE devs division.
Now, to answer to your question:
> But... This is FE development, you think the backend devs would like to be writing this?
We (BE devs) had done that for years. But now we'll fight hard against going back to full-stack, but only for our advantage: in this way, we can get treated way better and get payed way more.
... Long story short is that a web app is cross-platform (browser) program and that very quickly gets quite complicated requirements. Of which security, dependency management and frameworks are a big part. Because you need to know about them, and how they work etc..
Long story / ramble:
A simple static website can be as simple as a bit of HTML with CSS.
But when you introduce workflows and users it isn't long before security comes around the corner. And that introduces a lot of complexity, which frameworks and packages help with. (Don't roll your own)
So the security packages comes with typescript. Which makes you adopt typescript and adds a bit of complexity over JS. (But also typesafety! I'm a fan FYI)
And then you want the website work as a progressive web app, so you need a service worker. More complicated.
You then might want to add some sort of isolation of CSS, or use Sass or some other framework. To help with code re-use and avoid breaking things as the app gets larger. Also more complicated.
Then your PO says you need to have async workflows and let the user know when something starts and is done, with push messages. So you need a background worker and push messages.
And we're not even talking about the technical issues, like not all browsers supporting certain API's or certain styles. Or updates to package X breaking package Y, needing a package patch.
Not to mention keeping up with the evolving syntax and language capabilities. HTML, Javascript, Typescript, CSS, SASS etc... They all keep changing and evolving.
Because the browser nowadays is an "operating system" that needs to be capable of handling all manner of dynamic software: maps, video, image editors, games, etc. I haven't done Windows development, but I assume browser-based development complexity will continue trending towards essentially the same complexity as developing e.g. a Windows program.
Yes, the browsers export a lot of capabilities to the frontend. But you point no reason why the frontends must use those capabilities.
> Because the browser nowadays is an "operating system" that needs to be capable of handling all manner of dynamic software: maps, video, image editors, games, etc.
If frontends didn't use the "OS" capabilities of the browser, how would one build a multi-user real-time text editing app like Google Docs?
Edit (and off topic): Writing this comment gave me flashbacks of using Mapquest online for driving directions before smartphones. You had to print the directions out and bring them to your car on a piece of paper. It worked though!
Earlier quoted context omitted.
TWenty years ago windows development was a lot simpler than modern browser applications. Fire up visual studio and create a new winforms project. You could literally drag and drop your way to a modest application with only minimal programming 'under the hood' for the business logic. I still don't think anything has surpassed the usability of winforms for a developer just wanting to get something done.
drag and drop forms from 20 years ago assumed a desktop PC. Today your form has to work on mobile
Earlier quoted context omitted.
> these apps are a minority. I disagree with this. Almost all front-end projects I've worked on in the last 10 years or so have had some requirement that made pulling in react a better choice than trying to push back on business and/or get buy in to do everything server side. Providing users the kind of tighter feedback loops for their workflows is only possible with JavaScript.
And this is why half of the internet is borderline unusable. Page layout jumping around for 5-10 seconds after what appears to be a full page load, buttons simply not functioning, and god forbid you try to use the back button. I know some expert will say none of those things have to happen and has nothing to do with react, but the reality of it is that these things are incredibly common in modern front end developmen…
This is not why half the internet is borderline unusable. React will happily do a full page render in under a second (including network load time). The primary reasons for that are:
1. People writing code that does many network requests in series. 5-10 seems to be not uncommon for many apps.
2. Adverts and as SDKs.
The app I inherited at my last job was a huge 2MB bundle (due to including both the firebase SDK and a large charting library), which I assumed was the cause of the slowness (it was taking ~3-4 seconds to load). But it turned out that was serial network requests that were slowing it down. The app is still 2MB (we made good progress on removing firebase, but hadn't quite gotten there when I left) but it now loads in around a second.
Earlier quoted context omitted.
It's a mix of this FOMO and a lot of people not knowing how to wire up AJAX well. I've seen entire teams reach for react just because there is a portion of the page where some AJAX was required and react is the only way this new crop of devs knows how to do DOM stuff with server side effects.
In what way is react related to ajax calls? I don't get it :(
It does make some sense. People used to use jquery exactly that way, and react provides an even better interface for ajax. I wouldn't be surprised if most of the usage of react is there just because people don't want to query their servers by hand.