Millions of small packages, new frameworks built every day, huge learning and re-learning curve, breaking changes, everyone is doing like he wants, browsers crashes more, mobile network bandwith is huge, tons of tools, transpilers, huge configurations, wasted days to just install, setup tools needed to run real tools, impossible to learn and follow everything, harder to find a frontend engineer, bad design and architecture, SPAs, microservices and other modern buzzwords everywhere, for simple feature 3 frameworks and 3MBs used, developers are not thinking, just copy pasting...
... (adding to the rant above)... having to use a "CLI" - by the way, a command-line is EXACTLY the opposite of having an "Interface". That's like saying a DOS prompt was an "interface". Maybe technically, but seriously, the lack of GUI's in all the new tools simply adds to the complexity. And, all these Flavor-of-the-day JS do some stupid simple "Hello World" or "To-do" example, and essentially leave it at that. Really? Sorry, Real Developers are paid to solve normal, boring, business systems software. Getting data from UI controls into a database, and back again. CRUD. Nothing seems to be developed by looking at the ENTIRE required "stack" in a comprehensive manner. These front-end tools seem to pretend that they are just fine existing in silos.
for simple feature 3 frameworks and 3MBs used, developers are not thinking, just copy pasting...
I think you nailed it right there. The problem isn't the ecosystem, it partially does contribute, but it is largely the inability to understand what to use for what problem. To be fair it's a hard decision to make usually, even experienced engineers get it wrong OFTEN. Most frameworks and tools are great at solving specific problems and once you face that problem those tools are a godsend. The problem I see is people try to overcomplicate things and use these tools where they aren't really needed (says a guy who wrote a personal site in react :/)
Another reason for the craziness is that you're working with a single language for the whole internet population. In the backend world there are a dozen of languages, each of which has gone through the same problems at a slower rate, smaller audience. With frontend there is one, and a few years ago everyone suddenly started caring about it, so you got 10+ years of innovation over a dozen languages/ecosystems packed into 3, of course it'll get crazy.
Contrary to what a lot of people feel it's a good thing. Innovation drives progress forward and propels new ideas into the open. To keep sane just stick to a few frameworks/tools you may need and know them on a high level, if you have a project that would benefit from one them learn them deeply. If you have a project that doesn't feel right with the ones you know, look for a new one or write one that solves that problem
It is impossible to learn everything, just learn enough to make yourself be effective at getting the project done
The way I see it, its mostly because of us developers. If we were to agree on a number of frameworks to wrap ourselves around and contribute to rather than trying each new framework simply because it had a specific 1 or two features that the others didn't, then we will have a variety of frameworks each with its ups and downs. Only then would framework developers and companies only focus on their frameworks to make them better and more stable while introducing new features. From my point of view, we need to make FE development eco system more like PHP eco system. You have a ton of frameworks for PHP but you know that a select few are worth learning and using almost for everything and you most probably won't need to learn another one if you already know a good one.
For example, PHP has Laravel, Symfony, CakePHP, CodeIgnieter, Zend, Yii, Phalcon...etc Almost all PHP developers know that if you want the best of the bunch, you'd go with Symfony or Laravel both are great and would be excellent choices. Other frameworks are good too but if you want the best you know its one of those two. Similarly we must have the same for FE frameworks. I only know about React and Angular and I know that both are fierce contenders so its a similar story with Symfony and Laravel. What we need is we should use those two frameworks more and report bugs send feature requests and so on to make them great. Now its up to their developers to make them better. I heard about a new framework called Vue.js and people are going crazy for it now. Most probably because it does few things better than either React or Angular.
My thoughts: medium.com/re-dom/master-the-dom-bc1a2a06089b https://youtu.be/0nh2EK1xveg
tl;dr; It's not that hard to control the DOM yourself. Frameworks can be easier to start, but a whole lot harder to master, than learning the standards.
I always try to keep update me, but its frustrating when i choose learning curve example for: it will be angular react or it will be vuejs with laravel!
I've been observing this current 'trend cycle' in web development with shock and horror.
Never in history has it been easier to sit down and write plain HTML, CSS, and JavaScript! Those are the three core pillars of the web as a platform - and it feels that instead of trying to get as close and familiar as we can with those three technologies, so many people are caught in the endless attempt to abstract away the web part of the web platform and approach it as a software development platform, almost ignoring what makes the web platform unique and powerful.
People use Babel for their JavaScript; SASS, SCSS, Stylus, and PostCSS for their CSS; and Jade/Pug and other HTML shorthands for writing their HTML. They use modules upon modules upon modules, building an intricate web of dependencies. The NPM left-pad fiasco should demonstrate how fragile the ecosystem and workflows people have been using are right now.
At the end of the day, the resulting websites coming out of these workflows are rendered as plain HTML, CSS, and JavaScript - I wonder how often it's easier just to write that output directly yourself instead of using all the other tools and workflows to conjure up the simple result we want to see at the end. (Once you've been solving the same problems for a while you would end up with a snippet-based workflow instead of a tool-based workflow)
The other danger I see in using too many tools to build websites instead of writing HTML, CSS, and JavaScript in a more direct way ➸ every tool is an imperfect abstraction of the idea you're working with. For example you can be more expressive in CSS than the code that CSS tools will work with and allow you use. If you use a linter, or other tools to help tidy up your code, they will often be stricter than the full range of expression the language allows. When you use multiple tools together, you become limited to only being able to express the parts of the language that all of the tools have overlapping support! If you use a lot of tools you're giving up a lot of freedom and flexibility, and this often leads to headaches and creating a lot of unnecessary labour for yourself. It's kind of like dividing by zero: as you're limited in expression in your whole project (with all tools) by the least expressive tool you have in your workflow.
Another way to think about it - every layer of abstraction away you are from your final output is like wearing an additional pair of sunglasses. If you wear 3 or 5 pairs of sunglasses pretty soon it will be too dark to anything clearly at all.
Internet has put the power to produce and distribute software into the hands of everyone. The result is an enormously diverse and intense activity. There's organic chaos, sometimes leading to beautiful solutions. It's evolution at work, and we' re going through the Cambric explosion. It isn't bad, it isn't good, it's just natural.
And indeed, there's less time than before to delve deeply into something. Therefore its important for developers to take some 20% of their time to study something durable in depth: a mainstream language, some fundamental algorithm, some classical concurrency problem. I've been programming for over 42 years now and I can tell you those things are durable investments. I can use knowledge like that with any technology, no matter how new.
And sometimes I take the time do do something thoroughly, just for fun, making my own contribution to biodiversity...
Jacques de Hooge
This sums up all my thoughts, things are getting really insane, and I started to look for alternatives like, well, reinventing the wheel on my own standards which make things really simple and easy to follow. I mean come on, learning Angular was harder than learning C then Angular 2 is out and you need to start the learning process again, then new techs and frameworks debate, which to use, which better, these questions are really annoying... That's it, I'm done of following "the trends"
Developers tend to follow every day emerging technologies not for the sake of improvement, but for the sake of feeling "cool" that they know. So we share part of making things more complicated.
The problem for me is keeping up too. Say I'm creating a back end system and I think it'll be nice to implement a nice web based GUI on top of it. I know HTML and CSS and am quite capable of crafting something nice. So I take a look at what I need to get a quick HTML/CSS baseline in there with a CSS preprocessor. I want to make sure this GUI is modern enough that it's easy to maintain going forward. So I have a Google to see what I need. And most of the time it tells me I want...
And so on. Before I know it I've got this mismatch of tools that installs all kind of configuration files in my project & enforces a directory structure I don't really need either. I've often started done the route and thought, screw this. Downloaded the dependencies myself, compiled the CSS myself and been much happier!
So the point of my waffle - if it's awkward enough for something experienced then yes - it's gone too far. It's fine for tinkering, side projects, quick prototypes etc. But for a stable product, you'd have to question if it's worth it at times.
For sure it's complicated, but this in my opinion is because Web Development has become the "lingua franca" of software development; the fact that, thanks to responsive design, one could develop the same (or a big part anyway) software for both mobile and desktops is a huge plus, and this helped this paradigm to spread anywhere, increasing use cases and peculiar scenarios. However, I honestly don't agree with the "over": it depends on what you need to achieve, and what your constraints are. As everything in life, the secret is to find the perfect equilibrium.
I believe that we haven't made modern front end over complicate but, we have made the development of front end overcomplicated. When I started working with front end design, I used a HTML, CSS and JavaScript file to make my front end. Now you have to create a development server, then you have all these "plugins" to make your development server faster and easier to use ( faster and easier are used loosely because most of the time it takes longer to set all of that up than the front end itself). I think that the development tools have not come far enough for developers so, we use so/so tools to get the job done that we spend more time hacking then actually getting our job done. I think that JavaScript has come a far way but it still is not far enough. As well documentation for these tools are no where were they should be.
My answer is yes. It's overcomplicated.
Web front-end developer create programs for a most popular environment - browser, because browser capabilities and API's are growing extremly fast and it's great.
But let's take a look inside browser. Browser has several separate knowledge areas: html ,css, javascript, dom, bom, data transport, specifications, implementations, tooling. Also you should work with this areas for several platforms: Windows, OS X, Linux, iOS, Android, Windows Mobile, TV. Also you should remember, for example, behavioirs for several render mode: default, transcoder, webview, standalone, quirks mode. Apply this on modern browsers - IE, Opera, Chrome, Firefox, Safari and you will get complex and extremly fast changing eco-system of code.
Just a moment, I forgot to add user experience, accessibility, testing, seo, design, usability, performance, semantics, progressive enhancement , graceful degradation, cvs, cli, ssh, package manager, security, build, livereload, pipes, data formats, fonts, graphics, gpu, open gl, sql, networks, tcp/ip, http, spdy, gzip, deflate, base64, mvp, mvc, mvvc, reactive programming, functional programming, object oriented programming, screen sizes, orientation, jit, ast, llvm, dns, workers, fps, regexp, csrf, clickjacking, bots, pc devices, android app, ios sandbox, nginx, crypto to front-end developer stack. And of course compatibility and bugs of all this things too. And only front-end developer with a huge base of knowlege and experience can look forward without fear.
And of course, it will be always overcomplicated. Frameworks just resolve some problems with capability and data stucture.
P.S. I don't know about .Net eco-system, but in Java in 2008 I have to write 25 variants of the game for most popular phone vendors - Motorolla, Siemens and so on. And of course I had to kept in mind a lot of thinigs, because java was a most popular environment...
The large number of options have come about due to the big gap between web standards and the technical requirements around using the browser as a software delivery platform. If web standards had more solutions for the technical problems that these numerous frameworks (attempt to) solve, and if these standards were widely implemented, you'd find all this framework and tool glut would fall away quite quickly.
For now, if you want to partake in front-end heavy web app development, you'll need to pick a good stack and stick with it. A lot of fronties appear to be converging on the same front-end toolchain consisting of React, Redux, React Router, Babel and Webpack.
Due to the backward compatibility issue, project maintainer is JavaScript world fix problems by adding things to it. Also they fix the fixes by adding to it.
I hope WebAssembly will end this loop.
This is where someone like me gets lost and can't figure out what to do or which way to go. I think everyday that I have the right plan of attack for what I want to accomplish until I see something else that is all the buzz of the moment within the 5 minute society club. Every other day when learning how to do something I end up thinking I need to know something else first and then I track that down to only realize I need to know something else first ad infinitum. Crazy man!
This is a pretty alarming concern, there is an alluvion of new technologies right now, and no one can keep up with everything, as a fairly new developer I always try to jump on every new technology that promises to make my life easier, however I'm quickly learning that there is no silver bullet and that the developers of technologies that we know and love learn about their weaknesses after they are out there being used by many.
Since a lot of points have been covered already I just want to add a thought: Your product website or whatever is unique to you, so no single product, framework or library will exactly match your needs, and also you only have so many days or years to come up with something to show for, so a great ability these days is to come up with a way of integrating a technology and making it yours, fit it to your particular needs. In order to achieve that, understanding the tools you'll use and why they were built, will get you a long way ahead.
I will be the devil's advocate on this one. While I agree that things have definitely got out of hand in front-end dev, these days, I also think it comes down to how you implement your stack.
For example, if you just use React/Redux and something like Babel for transpiring, this is still a fairly simple stack.
However , what kills me is when developers then tack on a plugin/library/dependency for every problem they have in their app. Form validation, routing, formatting, responsive, AJAX, etc, etc.
I think if we stick as closely to the core of the stacks we choose to employ, then this becomes manageable. You may have to do more work, but there is less to keep track of and fewer opportunities for random changes to a package wrecking your project.
You're echoing my frustrations with front-end development. I'm sure some would argue that it's worth the "wasted days" and "huge learning and re-learning curve" but I don't see it. I can't convince my bosses that the time is worth the effort. So, I have to learn on my own. I don't have a whole lot of motivation to do that, though. It's the up-front time to get everything installed and up and running and dealing with errors that inevitably appear even when following the installation instructions exactly as written... ugh. It's painful to think about. Yet, I continue to do it. This industry's de facto motto is: Change or die.
Of course, one has to figure out what is worth pursuing. That's the trick.
Honestly, I've been thinking this for a while now. I was looking at a React project recently and all that went into it and thought to myself "I think we've gone too far." There was a nice balance about 2-3 years ago but I feel like the last 2 or so years have literally been a game of one upsmanship as to who has the best and hippest tech stack.
Personally, I blame the larger tech firms like Facebook and Google for pushing new proprietary ways of doing things instead of pushing and expanding the standards. Go, JSX, etc might be cool but they seem to exist to answer problems that could be better solved by working to push better open standards like Web Components instead of spinning off on their own direction.
Worse, is now you've got generally stable companies Microsoft getting into the game with .NET 5, I mean DNX, I mean DotNet, I mean .NET Core and even though it's close to release, it's an absolute mess full of shims and missing libraries and work arounds.
Innovation is great. Innovation for innovation's sake is just foolish.
</rant>
It's been a long all nighter debugging this MERN project I inherited.
I couldn't agree more with Davor. I see young developers grasping new hyper-solutions everyday, but they can't, still, use simple logic to solve the smallest of issues (like image resizing using rule of three).
Yes, it is overcomplicated. At my office, we discuss this almost every day. As an example, after trying Capistrano, Jenkins and all sorts of stuff, our best tool for deployment is a bash script: no dependencies, runs everywhere, one simple file...
I believe that there are a lot of choices when it comes to front end development and that makes it hard for us to focus on 20 things at a time. We are not supposed to know every possible thing there is in web development but it would be cool if we can gather more information and use it. Same applies for life in general.
As we all know, web development as an industry grows more and more each day and people are trying to solve their development problems with new tools, frameworks, libraries, technologies etc. so they release a new tool they think it would be cool for others to check out and use but that adds another tool to use in your every day life. Yeah it will cut down on development time but it will increase the complexity of your project by x2 times.
That means, now people have to learn yet another tool, and spend extra time to use it. That ends up with people being way too spread around and now when you need people who strictly know only a few tools, the exact stack you use, you can't find them, because they are exploring the world of front end development and spending time learning new stuff while never master one thing from that stack.
Don't get me wrong, I love to experiment with different tools and technologies but for some projects, that might be an overkill.
People have to somehow limit their stack to a few tools, they can't work with more than 10 things at a time. It's great if you can use like 20-30 tools at the same time but it will drain your energy fast. It really depends what you are building though.
Here's a fun video to check out [from this point up to the 20th minute], he's talking about general web development but it still applies for front end development.
I believe we are in a time where browsers have to adapt to the new demands of developers and end-customers. Think ES6 or web components. Once browsers are on a level where they can fulfill the demands, build dependencies will go down as fewer transpiling, preprocessing and polyfills are required.
Further, front-end as we know it now is only a few years old and still developing in many ways. There is still a lot of experimentation and 'getting things right' going on.
You poured out my heart @pinal !
Grant W Parks
The idea used to be to make the environment ubiquitous and opaque so that the focus was on designing and coding. When one has to re-learn an environment with every project and frequently the environment is chosen using the "management via in-flight magazine" style approach, it's no wonder things are as bad as they are. Everywhere. One of my old clients is going on 2 years to implement an e-commerce site with Redux. Another is now over a year past "almost ready to launch" stage (although that's a PHP situation with way too many things tacked on). It's everywhere. Can someone point me to a great framework application in the wild? I'm sick of "todo list".