Ask HN: Why does front-end development change so often?
All technology moves quickly but front-end development evolves at a whole different level. What is popular one year is “old” the next and often a totally different menthodology. Why do you think front-end development is in such a constant state of change?
82 comments
[ 0.25 ms ] story [ 144 ms ] threadSo someone people don't learn the stuff in use (or find it difficult to achieve the current trend in preexisting technology) in use and find easier tricks/concepts then base their whole framework on that.
Now newbies, who want to quickly achieve something gravitate towards the new shiny things which makes the current Trend easy but makes rest of the things difficult.
You can optimize technology along any axis, but if you optimize it along one axis it will be deoptimized along some other axis.
For example, think of interactivity. When people wanted to build interactive website, they brought stuff like websockets/single page application but now websockets can't be cached like a http API and SPA throws monkey wrench into SEO.
Now, you made current trending thing (interactivity) easier for newbies but made other things like initial page load time, SEO difficult.
These are my noob level observations, as you gain more experience you'll find many examples of this happening in wild.
Similarly, to achieve scalability people brought in JWT instead of Session cookies and lost ability to revoke the token without maintaing a blacklist or using short lived tokens which you've to refresh every few minutes increasing RPS load for the server.
So the moral of the story is that you need to understand what a particular technology makes easy and what it makes difficult then you select the appropriate technology without chasing the hype.
1- back-end frameworks tend to follow either the Rails or Sinatra models. We may get new frameworks in new languages but their structures are fairly similar. Datastores have been changing but usually get abstracted into a supporting library. GraphQL a bigger change than we've seen in a while.
2- front-end requirements are changing faster with a greater number of developers solving more varied problems.
3- front-end is at the top of the stack so is less constrained. Making changes in the back-end can have consequences to all developers of a product. Front-end changes only affect the front-end devs who likely do both the app along with new frameworks being built.
ES5 plus XHR rent a hole to a bizarre parallel world where the whole page was an applet. We are still working out what that means.
Unlike every other development context, this whole world is an accident.
I made my first website in 1996. Youth, listen to me.
What are the two hacks the whole field is based on?
- devices: desktops/laptops, smart phones/dumbphones, lynx, curl, uncountable browsers
- programming languages / paradigms: in the end it's all HTML/CSS/JS, but there's lots of ways to generate these
- in whatever PL you selected, a bewildering array of libraries
- open source and commercial offerings
- small single site pages to things like MSDN
- public facing pages to large internal legacy intranets
- use-cases, from wikipedia to youtube
- running in a browser vs in a container like the spotify app
- languages (like english vs german), so unicode etc. issues
- vast amount of developers doing the work, with very different backgrounds
To the degree things works, it's small wonder really :)
I had always thought of the top-down development of Windows and Mac as a negative but now see the benefits because it forced developers to get behind tools and technologies.
1. Javascript has a massive and diverse community. Developers that would otherwise avoid the language must learn to use it. So, where other languages would rally around one framework (because of the self-selection), Javascript rallies into sub-communities around methodologies and architectures.
2. Javascript is gaining new developers at a very high rate. All these new minds bring new ideas, new combinations of ideas, and lots of re-invented ideas too. All of it, even revisiting old ideas, pushes the collective industry in new directions.
3. Frontend developers have had to layer on top of a set of tools barely adequate for what we're trying to accomplish. For example, jQuery should never have been necessary, but was revolutionary when it came out. Today there's still not great solutions around storage, security, performance, etc. Solving these problems improve the abstraction and allow higher-level frameworks to appear.
4. Based on what I've seen there appear to be very few UI toolkits that aren't kind of garbage. Human interaction and rendering pretty bits is hard. Generally I think the industry (even outside webdev) is still looking for the "right answer" to the problem.
For example, your comment made me wonder what I would point out as example of maximum complexity in either field -- distributed systems, tight performance constraints, exceptionally magical functionality, and so on. Everything I thought of is something that's done in both backend and frontend systems.
I do feel that the industry perception is that backend development is more technical. But I don't believe that is true anymore personally, and I think that perception is rapidly changing.
For what it's worth, I'm much more of a backend developer myself.
5. All those new developers entering the web development community want to make a name for themselves, and there isn't as much opportunity for that if you are just using a framework created by someone else.
What are the minimum technologies needed to get a solid front-end stack, with a nice balance between modern features without framework/library/build tool/transpiling hell?
For example, I don’t want to learn TypeScript when vanilla JavaScript will suffice. I’m wary of picking up the “hot” new frameworks because they haven’t stood the test of time and may get deprecated/irrelevant.
Basically, I want to have a flexible and minimalist stack, but also with a good balance of features (i.e. not just a static HTML site).
Any ideas?
Check this repo if you're interested in react: https://github.com/enaqx/awesome-react
You can also check vue.js, I have heard from many people that it's very good and some even say that it is better and easier to get started with than react :) I've never worked with it so I can't say much about it
* The APIs for building web UIs are really hairy and difficult to understand. * The fact that the web is a standard and quick way of getting apps to people means lots of people are heavily invested in it. * There's still a disconnect between developers and designers. This means many libraries seem to be developed around recognizing past patterns rather than a forward-looking vision. At least that's my guess. * Other human things such as the desire for recognition, users taking any level of UI polish for granted and expecting more over the years, and so on. * The surface area of features exposed on the frontend is enormous. You have forms, arbitrary shapes, layout, color, state management, querying external data sources, and so on.
You combine the above and you get massive technology churn. Maybe people underestimate the complexity involved.
I get the frustration though because at the end of the day we're still pushing pixels onto the screen. Even a lot of the primitives haven't changed in a while. We still have our colored boxes and text arranged in some configuration. You might expect all the good ideas to have been tried already.
Maybe it would be a good idea to commit the node modules to GitHub?
I think it's mostly a perception issue due to the fact that front-end development was historically a poor experience and things have greatly improved in a very short time.
My tech stack dates back to 1972, with the last major update in 1999 and the last notable minor update in 2011.
That isn't even a particularly old tech stack. Some stuff dates back to 1957, with major updates in 1977 and 1990.
Honestly the big "revolution" was the change from imperative frameworks (jQuery, Backbone) to component-based frameworks (React, Angular 2+, Vue). Everything else is just an incremental improvement in one way or another.
UI is inherently complex. The relationships between views, states, data and events blows up very quickly, and inevitably lead to code that gets messy. So people come up with frameworks to organize code and auto-generate some stuff. But then complexity doesn't really go away, so frameworks also get messy, and people come up with more frameworks.
Does it get easier overtime? Probably a little bit. But overall there is no silver bullet.
That said, the concepts are not different. Once you understand where the mess comes from and what the next framework is trying to "fix", things become a lot clearer, and you don't really have to learn much of anything to be able to use the newer stuff.
EDIT: also in javascript, it's very easy to roll out "frameworks". In other languages, UI libraries are deeply connected to the lower-levels of the operating systems. On the web, you just make a library that manipulates the DOM and CSSs, and everything else is done for you by the browser. It's much easier.
Also worth mentioning that the switching costs for changing frameworks in JS is incredibly low. You can just load different JS files and presto - you can use a new framework. No servers to setup or anything like that
I get the feeling that a lot of the web development community has trouble understanding the difference between different and better. That's why we see so many wheels get reinvented so often. Is React a better way of manipulating the DOM than, say, Angular? I don't know the answer to that. It certainly is a different way. Is Webpack better at combining and packaging code than Grunt and Gulp? It's a different way of of packaging code.
In other communities, there's a much more nuanced discussion of whether technologies are appropriate. In the web development community, there's a much greater emphasis on painting technologies as absolutely "good" or "bad", "current" or "obsolete", without the suggestion that this new technology can coexist alongside existing technologies and address new use cases that the existing technologies didn't address. I've heard of numerous (and participated in two) projects which migrated from an existing framework (such as Angular, Ember, or Knockout) to React, solely because React was newer. There was no consideration whether React was a more appropriate framework for the task at hand. There was little consideration of the costs of the transition. It was a knee-jerk decision. "This framework is old, and the code written in it is nasty and buggy. We need to "refactor" (read: rewrite) our code to use React so that we can be current with the state-of-the-art best practices in web development."
I compare this with, for example, the Python community, where there is much more of a detente between frameworks like Django and Flask. Even though Flask is newer, there wasn't ever really a question of Flask replacing Django. Flask was merely seen as a solution for cases you'd have to strip out of a lot of Django (like its ORM and much of its middleware) in order to get a simple interactive website up and running quickly. There wasn't nearly as much of a push to use Flask because it was merely newer.
I think you're confusing the HN community with the web dev community :) Everything I picked I picked because it was better for a specific reason. React solved the problems I was having with writing reusable code. Webpack takes all the grunt-work out of Grunt. TypeScript purely for the ease of refactoring.
> I've heard of numerous (and participated in two) projects which migrated from an existing framework (such as Angular, Ember, or Knockout) to React, solely because React was newer.
You can do this with any project The reason these choices exist is because lots of very smart people are thinking very hard about ways to do things better -- it's naive to think there's no merit to them because some people you happen to know are making poorly informed decisions.
Well, that's one way of thinking about it. Another way of thinking about is that it's a lot easier to gain recognition and mindshare for releasing a new framework than there is in refactoring or implementing improvements upon an existing framework. This incentive structure applies at both the corporate and individual level.
I've found, from my experience working at large tech companies, that many frameworks get started because a senior engineer wants a demonstrable project to demonstrate their leadership and technical skills in order to get a raise or a promotion. A new framework is definitely a high-impact project with a very clear deliverable and a well-defined set of requirements. So they make a new framework and then market the absolute daylights out of it, since one of their goals isn't just to create a new framework, but also to demonstrate some level of adoption for it. So the framework is pitched as the next big thing, which makes all existing frameworks obsolete.
Scale this motivation and approach up to the level of corporations rather than individuals, and you have the modern web development ecosystems. Corporations want goodwill and mindshare, and they know that one of the ways to get that is to release a framework that everyone uses.
The only possible example I can think of is React vs. Vue, but even then there's a pretty fundamental differentiating factor which is that Vue is lightweight (e.g. easier to drop in to an existing non-Vue project).
Do any of these frameworks actually solve problems that weren't being solved before? Did rewriting Angular 1 in Typescript really improve things for the user?
Yes. React solved two big problems in the front-end space: building re-usable components as a first order concern and moving away from the imperative DOM. As mentioned, Vue is arguably pretty similar except with some concretely different goals.
Angular 1 -> 2 was not about just Typescript, it was a large-scale refactoring to move away from some of the more imperative aspects towards a more component-based architecture which incorporates some of the advances made since Angular 1 was introduced.
Vulcan's a framework which uses React and Meteor is it's own separate thing so I'm not sure what you're trying to identify here.
This is how you know you don't want to work for them anyway. Putting "best practices" before requirements...
IIRC, grunt/webpack would be the comparison. bower is more of a package manager (akin to npm), no? bower has been deprecated (from a year ago or more, no?) Worked on a project in 2015/2016, set up the project with bower, and I noticed by early 2018, deprecation notices kept coming up in the build logs. Not a major crisis, but I wouldn't start a project with bower in the mix today.
re: newer/better - I know some folks who transitioned to react from other stuff, and it really is 'chasing a trend', but their goal was primarily to be 'relevant' because they are specifically trying to attract a certain type of developer (IE, one that is focused on the newest stuff), because they think they'll get funding or more cachet or something else along with it (move in the right circles and you're a bigger target for acquisition?).
The opposite of this is a current project - a slapdash offshored project using codeigniter 2 (and was started in 2016, IIRC, well after CI2 was EOL). There's dozens of bugs, and fixing each one involves far more time than a rewrite would involve, but ... "it's working, and we don't want to rock the boat or lose momentum or...". So there are projects which chase the latest trends for the wrong reasons (and maybe sometimes legit reasons), and there are projects that cling to the past for bad/poor/wrong reasons. I'm not dogging on CI2 specifically, but the fact that we've got a pile of broken code that, even when 'fixed' will still only work on PHP5.
When you're new to the scene, how on Earth would you know?
Seemingly everybody's doing it, there's no sane source on whether it's worth using or its tangible benefits, and you can't make heads or tails of it – you need to be in the game already to even begin doing so.
Web dev may not be evolving, but it certainly is developing into new forms fairly frequently. As my newbie coding days went by, I witnessed the rise of Angular as this massive new way to handle web codebase. After some time, it grew into Angular2, with a seemingly indiscernable structure to its apps. Around the same time, came Vue, which is "the same thing as Angular, only better". And that's before I started getting around Github...
This kind of development doesn't match the mental model we have for improvement in a technological sphere. If there's something new, it must be better, right? Bigger TVs, smart TVs, 3D TVs... You could still watch your old TV (not really, 'cause the transmission's gone digital, which few, if any, old TVs support), but you'll be behind — and given the frantic pace of the everyday life now, how'd you know better?
I'd sworn off frameworks until bigger projects entirely. You can get a lot from regular JS, without the overhead of learning and keeping up the mental model of a new framework. I can afford to, because I'm an independent developer who codes for fun. Could people in the industry afford the same?
"Just try it" isn't a good argument when all you see are big, unfamiliar names that you're apparently supposed to know – and without guidance, learning web dev on your own, you effectively do, even if just to see that you don't need it. It's overwhelming.
Imagine having to learn color theory and all kinds of subtle differences in the production of crayons you could have before you sit down to doodle something in your spare time. Imagine having to read your literary national treasure section whole before you want to write that cool short story you had when you took that shower. Ridiculous!
So, I argue, is the fact that there's seemingly an obligation to read up documentation for major frameworks before you sit down and code your first clicker-number-increaser.
Exactly! Needn't be an expert person: I think it would be enough to have a respected source declare so in their blog, or in an article. Then, folks could point newbies towards these starting resources, much like they do with the classic blog posts.
In a more ideal world, people who search "what framework to use js" would encounter that post/article and see for themselves.
The churn has been real
There is tremendous competition at all levels.
Browsers (Chrome, Safari, Firefox) are competing each other fiercely and provide rapid advancements in capabilities.
Libraries/frameworks (Angular, React, Vue, D3, and a bazillion others) are competing more fiercely for a stronger hold on the market.
Website owners compete harder and want the "latest" tech to grace their product offerings creating great demand for the latest tech.
Web devs compete even more fiercely to stay relevant by picking the latest tech in the market.
Add to this advanced browser capabilities, increased computing power and fragmented screen sizes (phones, desktops, laptops, tablets) with faster data speeds and you have a bustling ecosystem that changes more rapidly than any player can keep up with.
Building a native application with native APIs using JavaScript sounds interesting. Okay, you built another user interface. How many of these do we need to build? How many apps does the typical user have installed or even use among the ones they did install?
I remember recently turning on some tutorial for a web app that was linked from HN. Angular on the front end, node on the backend, framework B for writing tests, framework C for running them, some other tool for the build process. Another tool or plugin for minification. Okay great. You know the frameworks of the month. Congrats.
I learned HTML back in late 90s in grade school and went on to build PHP apps in the early 2000s for my Unreal clan. By college, I supported a stack for my university written in CakePHP. I remember using django for a class project in my CS program. My first job out of college, there was a tangled mess of asp.net, .NET web MVC and .NET web apis. My next company, there was a ton of stuff in Spring and various APIs using jersey.
Honestly, none of the real value was in any of the web apps. The value was in the backend logic (if there was any significant business logic at all) and more so in data and real system design, balancing between function, redundancy, resiliency, extensibility, and some notion of scalability depending on who the customer was and what expected or unexpected scenarios could arise and how our systems would behave.
Unfortunately I see too many folks caught up in the framework of the week or framework of the month when there’s so much more depth if you’re willing to explore.
These are all responsibilities on the frontend as well... Website =/= Webapp. It almost seems that a lot of backend developers are not making this distinction nowadays, even though SPAs are already out there for years.
In the frontend there is the ever-responsive UI workload, the option for web workers, and service workers are on the rise. To keep your state there are JavaScript objects, web storage (session- and localstorage) and IndexedDB. WebGL anyone...? Newly developed JavaScript should sometimes work in the browser as well as in Node.js. I am solely mentioning technology here, not any implementation - this is thanks to the frontend of the web, as sandboxed app platform (and JavaScript), being so versatile. Next to the system design of the app there is also the gap to its UI/UX design to fill. ...All should work reliable on devices with very limited resources, as there is no option to scale on the client side.
"How to reach offline functionality?" Is a question with all of the complexity belonging to the frontend. Whereas the frontend is the data's real-time interaction, the backend becomes more the reliable async distribution of data. I'm sorry, but frontend app development is everything except from boring for me.
Go back to the core design and simplify it. Keep what you need and everything else is noise.
My point was people pick the new and coming framework and it turns into tech debt. If development was more requirement driven, we wouldn’t be in this mess.
I think a lot of technology that was solely available to the backend for a long time is now possible to do in the frontend (including machine learning with Tensorflow) ...it's a quite new and limited (but save) form, but the advantages in using those capabilities are clear to me.
As everything is quite young there isn't an established pattern yet and a lot of active research is happening. Just in the last 5 years alone we got quite an amount of additional languages: Elm, TypeScript, Flow, ReasonML, PureScript. I personally like the functional approach of React to transform the interaction of the imperative DOM to a declarative one, but there is still a lot to be done until we reach something like an MV* pattern for SPAs. If I were to make a guess, I would guess that all the active change in the frontend (including the urge for WebAssembly from some) is truly because of the hope for an MV* pattern that combines all those technologies with the advantages of the web.
If you were to take on some tech dept, please make sure to keep it interesting for the future development. The essence of the web is to not find a common agreement, and I think the active development on the frontend mirrors this sentiment quite well. ;)
Most B2B apps and apps with monthly subscriptions.
Edit: I thought about it and it seems like generating is the right word and rendering is still just something that happens on the client-side no matter what.
This environment is simultaneously so restrictive (in that you can't really introduce new languages except by having them transpile to JavaScript) and so bad that people end up trying to tie it into something more cohesive (React's virtual DOM, Typescript) and then only partly succeeding (React's dependence on setState and things often being much easier to do with document.getElementById than in the React way, Typescript's inability to handle libraries intended for the web), leading other people to try do it better.
Can you elaborate? TypeScript is incredibly popular for client-side development.
To be clear I don't expect it to be able to do this, reading JavaScript that was written without types and deciding what the types are sounds more or less impossible, it's just a demonstration of how you tend to end up with an imperfect solution as a result of the decisions made early on in the web's development.
Former means that you still can produce improvement with a small team or even individual. It also mean that people are in constant search for something that would fix them very real problem they have.
The latter means that many such small teams are trying and having enough experience to be able to improve something small. It also means that people talk about it a lot which leads to information dissemination (so you learn about new things fast).