I'm never convinced that React, Redux, Vue, etc made frontend any better.
I find they have a niche use case and they aren't The Silver Bullet of frontend development.
Other than that they aren't as productive as rails, Django based monoliths.
thoughts?
Top comments (21)
Absolutely agree. I miss the old days when I could simply write some HTML, include a
.jsand.cssfile, include a couple third-party scripts like Bootstrap and jQuery, and BAM! That's all you need to get started.Nowadays, first you need to install
yarnornpm. Then pick a frontend framework to work with. Once you have that, make all the components and layouts you need. Then once you have webpack and all its loaders setup, you can write some HTML. But wait! All the cool kids are using preprocessors. Let me modify my webpack build to usepug-loader. Oh, andsass-loader, too. Ugh, wait... shouldn't I be using TypeScript...?Not old days if you ask me. You can still do that today.
And something many forget is, those extra extra files generated by frameworks on setup is, you guessed, for the framework, not the developer.
So the framework I use, after generating my project, from a single command line, I go into where I wanna create my
.tsand.cssand.html, and start writing code. That's it.It's easy to think the old ways were better. In some cases, yes, for hello world projects. But for big scale applications, frameworks ensured a consistent way of doing things.
and then comes the hooks update 🤯 and all you're code is not that shiny and modern
In some ways front-end dev is complicated. I think a lot of the reasons is because javascript is much much faster than it used to be and it has enabled us to make fantastic software that was simply impossible before modern JIT js compilers.
As a response we have made websites much more reactive and complicated. When we complicate things we try to find ways to organize them and make it easier to manage. Thus the frameworks were born to solve the problem of creating very dynamic sites. Additionally things like webpack were born to bundle your code, to write code in modern ways for old browsers, etc.
Do you need anything but handwritten css and vanilla JS to make a front end work? Definitely no, you dont need it. Once your site become less of a medium to display things and more of an application to do things then the frameworks and such become much more useful.
So is front-end really over complicated or are we, as developers, using more complicated tools than the job requires?
In my opinion we are using more complicated tools than the job requires.
Yes. And that wouldn't be the fault of the tools. The one wielding the tools is to blame.
Me using a chainsaw to cut a piece of leaf doesn't make the chainsaw "overcomplicated"
I'm wrongly using the right tool for the wrong job. Just like I wouldn't wanna cut a tree log with a hand blade, I wouldn't try to cut a single leaf with a chainsaw.
I think as developers, we've abused our toolsets, thus making our tools appear the bad guy
I agree its a the carrot-on-a-stick analogy if you think about it. I love the evolution in development and its great having those richer experiences but it seems like at some point we have lost sight of what it is that we were trying to do in the first place: improve efficiency, better output with less bugs.
And what if we write in pure HTML, CSS & JavaScript?
Let's not forget that's exactly where we came from. We used to write in pure Javascript. Today, it's Typescript. But HTML and CSS are still in their pure state, for the most part
I still write Vanilla JS
Good point, and a big driver for other non-frontend frameworks such as Spring, Spark or Docker - everyone knows where to look and understands the shape of the source.
I also think that these 'opinionated' approaches encourage good practice (apart from EJBs - there has to be one black sheep in the family), embodying well thought-out design patterns and providing examples of problems they address.
They absolutely are supposed to. But if you have worked on any number of projects you will have noticed that it definitely hasn't in practice.
People on the front end especially seem to go out of their way sometimes to find their own special way of implementing something. Often jumping through 100 hoops only to land one step backwards.
Agreed. I think there is a real problem with the industry poorly handling the level of people migrating to it. Priorities that have been established over the last 50 years, mainly after decades of pain and failure seem to be completely ignored in favour of ideals we know don't work in practice.
Also I am not sure its an academic problem. I know a lot of people with a good understanding of their language features who just aren't very good at writing elegant solutions to simple problems.
Maybe their problem is that they are (ironically) too clever for this job.
Sorry to revive an old thread but I agree. It is overcomplicated it isn't complex. That has little to nothing to do with react, redux or view which have if anything made it more straightforward aside from some general scaffolding/ boilerplate.
What has seemed to be continually getting worse is developers completely overcomplicating problems.
There seems to be a huge focus in this industry to convince people that anyone can code and that all it takes it to learn a programming language which betrays an ignorance the most important part of any engineering profession. The ability to think.
Hopefully its just teething problems.
It's exactly as you say. There is no such thing as as a tool suited to everyone and every use case. Each is good at certain things and sacrifice certain other things.
One of the more irritating things, I think, that so-called "modern" front end developers are missing about the "traditional" separation of concerns between JavaScript, HTML, and CSS is that each language is, in fact, designed for and suited to certain concerns that DO change independently of each other in a UI. And some of those concerns (particularly the semantics and presentation) need to be contributed to by designers, copywriters, accessibility experts, etc. It is neither scalable nor egalitarian to make everything go through traditional programmers as gatekeepers.
Somewhere along the way, people got so fed up with HTML in particular not keeping up with providing for what was being repeatedly built that they decided the big problem was that separation of concerns existing instead of components that combined all three. The former is understandable and the latter isn't wrong, but it's not the complete picture, either. Just look at what's happening in those frameworks over the course of only a few years: that scoffed-at separation of concerns is being reinvented in various non-standard ways.
But in the meantime, several generations of developers have been taught nothing but frameworks and scorn for the web platform. Who would, in this climate, be willing to take the risk of leading evolution in the platform?
The JavaScript framework community in particular likes to play the victim about this. Oh, the web gatekeepers made fun of React as spaghetti code and said it would never work. All the while apparently oblivious to their own hypocrisy given their own disdainful attitudes toward the work-in-progress of the web. In full view of and often aimed at living people who were still working to solve the very problems the framework devs were anxious about.
The one no-go thing for the platform is doing away with HTML and CSS and doing everything with JavaScript. For dozens of reasons published about endlessly over the last 30 years and easily learned unless you're the type of person who thinks they know everything already. But, no, surely the platform developers were out of touch fat cats and the framework developers were the wunderkind. Framework developers were not making any trade-offs inappropriate for the platform level at all, no sir! People eat this crap up and I'm sick to death of it, as you can surely tell.
But these frameworks could make web development better. They already have for many people. That's just a fact. But they're short term solutions that need to make their way into the platform in a way that works in the platform. That's good for everyone, especially users.
I actually blame technology marketing for this problem the most! Developer evangelism is a worthy cause, but it's also led to everyone talking like every tool is the next Coming of Jesus. That's good for no one.
instead of advocating for framework people should focus in making the platform better and more suitable for making apps.
Payments Api, Service Worker, Push Notification, Add to homescreen are good features that aim to make the platform better.
I think open source frameworks and libraries are a place to experiment with and mature ideas that will improve the platform. I also think they'll always exist, because there will always be new things we need after addressing the last batch. On top of that, I don't think everything can be provided for by the platform. There are all kinds of niches and domains that need attention and tools that wouldn't make sense for the platform. Not to mention people just have different preferences in developer experiences.
An issue as I see it is that it seems the majority of developers aren't great at figuring out which side of that line something is on. Or if not that, at approximating something that could translate more straightforwardly into one. It seems common to get caught up in the abstraction layer on top of the platform.
This is something browser vendors and web standards organizations should really focus on. It should be easier to learn what kinds of things could work, to pitch those ideas, to get actionable feedback, and so on.
As of now the very people that are most needed are alienated from making those contributions. I agree it's what's needed, but how does the industry get there from here?
I have been giving React Native a go over the past month and at first it was pretty exciting and challenging (coming from a more backend .NET development background) but as I started to encountered the multitude of issues from waking up one morning and finding the build that worked last night no longer works and some obscure hack job was required in a node package (really WTF).
All was well until React Navigation decided to break today and this pretty much made me give up on doing anything substantial on React Native for the time being. Due to my experiences I decided to look into the problems further and I am alarmed at how many issues exist and usually are resolved by the 100th poster going "oh yeah you need to add this line in this obscure place" - that rings alarm bells for me sorry.
But this seems to be a common occurrence with these front end libraries - they are great for a while but as you start add other packages things break or you update your node packages and something was updated somewhere in the 50k packages that is causing the issue.
What I keep asking but no one is answering is: how the **** are these issues happening? They shouldn't be and in a production development team this shit can kill productivity dead in the water (and leave people a little burned).
Don't get me wrong when things were moving along it was a great workflow I was getting through my tasks but today has been a total whitewash and to add insult to injury I think I have no choice but to wipe my dev machine completely because pulling previous "working" commits are also broken (how is that even possible).
Sure I could dig into all of it, find the root cause and fix the problem but why the hell should I be doing this?
Novelty has worn off for me - sure was fun firing up console windows feeling like I was on Linux again and I can see the value from an automation perspective but when you have 1000 moving parts and something goes wrong its very very painful.
It made frontend better, depending on how it was used.
It's all about the use cases.
None is better than the other. Just best for what they were designed for.