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
I think there are a few different factors at play:
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.
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.
I would add
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.
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.
And many of those developers think that they are smarter than everybody else and instead of contributing to existing projects they are either doing another fork or reinventing something from scratch. I am strong believer in: 'Do not reinvent the wheel, improve it!' I think backend developers are more mature community, front end is still quite fresh, it reminds me of PHP in years of versions 1-3 where there was virtually no standards, everybody was inventing whatever they wanted and working on top of that. This days PHP is much more mature and the same will happen to JS and whole front end, we just need time.
IMHO it's just that front-end is very complex and we haven't found the perfect solution yet.. so a lot of great people are trying many things
Is it in your mind/words harder than backend development?
I feel that frontend has a lot more quirks than backend development has simply because of how hard it is to get UX right. Browsers are a lot better these days about standards but there is still inconsistency, especially if you want to target certain segments of the population like IE or Safari. Accessibility has general guidelines but YMMV with different screenreaders. And developers are not in the position to ask users to switch to a preferred compatible system just for their special snowflake shopping site or gig economy startup or CRUD app.
In the general sense I don't think frontend or backend web development is more difficult than the other. It has more to do with the problem being solved and the expertise of the individuals involved.
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.
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.
Because UI is hard and people think they can come up with some framework to "fix it".
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.
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 in javascript, it's very easy to roll out "frameworks"
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
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
To push back a little against this notion—is this even true? On the web front-end, I develop with React and Vue, which were released in 2013 and 2014 respectively. On the backend, I primarily use Phoenix, which was released in 2015. On the iOS front-end, I write apps in Swift, which was released in 2014. For our ML, practically nothing we use existed three years ago (except underlying layers, like language and below). That being said, you don't have to use the newer technologies if you don't want to. People use them because they offer advantages over the older technologies (generally), whether that be in development effort saved or performance and features. You can still build your web front-ends in jQuery, your backends in php or asp.net, and your iOS apps in objective-c. I hear the notion fairly often that web front-end development evolves more quickly, but I'm not sure that it's even true.
It's been true in my experience. I've had interviewers scoff at me for mentioning Bower and Grunt, saying that the latest best practice was Webpack. Is Webpack really better than Bower and Grunt? It's different, that's for sure.
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 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.
>Is Webpack really better than Bower and Grunt?
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.
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.
> I get the feeling that a lot of the web development community has trouble understanding the difference between different and better
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.
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.
>The reason these choices exist is because lots of very smart people are thinking very hard about ways to do things better
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.
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.
That's a nice theory but I think it's wrong. Can you provide an example of a framework that should have been an incremental improvement (or not written at all?).
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).
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).
React. Vue. Angular 2. Meteor. Vulcan.
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?
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?
> Do any of these frameworks actually solve problems that weren't being solved before?
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.
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.
> I've had interviewers scoff at me for mentioning Bower and Grunt, saying that the latest best practice was Webpack
This is how you know you don't want to work for them anyway. Putting "best practices" before requirements...
This is how you know you don't want to work for them anyway. Putting "best practices" before requirements...
> That being said, you don't have to use the newer technologies if you don't want to.
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?
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?
This varies by technology, but often you can get productive within a day or two with these technologies. I mean, the core Vue docs (entire essentials section, from Introduction through Components), is 12k words, including code. At 50 wpm (1/6th of college reading speed on non-technical material), that's four hours of reading. If you wanna skim the thing, you could easily see the gist of what it's about in less than an hour.
I'm not trying to argue about relative effectiveness behind Vue et al. I'm saying that, as a newbie, you wouldn't be able to know the difference.
"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.
"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.
Yeh, the exploding complexity due to the increasingly wide choice of tools seems like it could exacerbate already steep learnings curves for software development—but if you don't have some teacher/learning source that you just decide to trust as your guru, I'm not sure what choice you have other than to just dive in, or spend time researching options, or maybe a little of both. I guess the ideal option here is to have an expert that can give you advice that you just go along with, so if you tell them "I just want to build a clicker" they can just tell you "Just learn javascript and html and css" or w/e
> I guess the ideal option here is to have an expert that can give you advice that you just go along with, so if you tell them "I just want to build a clicker" they can just tell you "Just learn javascript and html and css" or w/e
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.
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.
If you look back another generation the difference is more apparent. What did you use prior to Phoenix? Node was popular for a bit, but Rails/Django was much larger. In their lifetime there have been a number of major players in the front-end (jQuery, Backbone, Ember, Angular, Angular 2.0, a few more obscure libraries). There have also been a number of build tools (Grunt, Gulp, Webpack) and a number of preprocessors (LESS, SASS, etc)
The churn has been real
The churn has been real
I avoid this "rat race." I have been building extraordinarily fast page per click apps in Java (and now Clojure, at one point Play/Scala) for over two decades. My usual front end is largely static but if I need a little dynamic I now add a touch of Vue or some websockets if push is needed. Minimal but custom JS.
On a decent connection it is rare for full click to rendered time to be over 80ms, and usually much faster.
I think too many engineers think too much has to be done on the browser side. It just isn't true, for the vast majority of cases, in my experience.
Of course, I have built an array of "modern" framework heavy front end apps, and back ends for native mobile apps, but I always start things simple and page per click. It gets the job done and is wicked fast.
On a decent connection it is rare for full click to rendered time to be over 80ms, and usually much faster.
I think too many engineers think too much has to be done on the browser side. It just isn't true, for the vast majority of cases, in my experience.
Of course, I have built an array of "modern" framework heavy front end apps, and back ends for native mobile apps, but I always start things simple and page per click. It gets the job done and is wicked fast.
Same here, except with Python/Django. If performance is an issue, then I'll pre-render as much as possible and serve from elastic or other k/v db. A small amount of JS (really small) can handle any dynamic portion.
The web environment was never intentionally designed to be what it has become (a system for drawing fully featured user interfaces and even games) and so isn't really equipped for it, you could argue it's missing a lot of widget primitives, the view-updates-as-string-manipulation is archaic to put it kindly and the whole thing is untyped and shackled to a weak language without so much as a proper this keyword.
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.
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.
> Typescript's inability to handle libraries intended for the web
Can you elaborate? TypeScript is incredibly popular for client-side development.
Can you elaborate? TypeScript is incredibly popular for client-side development.
Maybe I missed something, but my experience was that Typescript was capable of making useful conclusions (i.e. MyLibrary.MyType.width exists, but MyLibrary.MyType.dog does not) about other libraries, delivered to it via NPM, that were also written in Typescript. If your libraries were written in JavaScript to be run in the browser you were stuck doing `declare var mylibrary: any;` and writing "unsafe" code. This is also true of any global variables/functions/etc. that exist in <script> tags in your HTML.
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.
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.
Typescript allows you to essentially write a typed API interface for your library (instead of rewriting your entire library in typescript), but support is fairly spotty.
I think there are several reasons for this:
* 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.
* 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.
I think it's because all the relevant dimensions are so vast:
- 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 :)
- 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 :)
That’s a good point. Lots of fragmentation leads to lots of different approaches to similar challenges.
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.
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.
There are some excellent answers here. An additional (if not unpleasant) one is that there are a lot trendy devs who like to treat new technology like fashion. If you're not up on the latest, you're not one of the cool kids. It's a kind of ingroup/outgroup thing.
Then again. I thought jQuery and AngularJS was problematic when they were trendy. React is 6 years old and still doing it for me.
I find front end development extremely boring. Just my personal opinion. So you make another web page using a new framework. So what? How is it better or more valuable than what you could have built 5 years ago? Did you discover a framework that gives you faster time to market? Is it easier to support because it’s a smaller code base and multi platform? Is the performance that much better? Did some Ab testing really prove to you that you need to optimize load times because millisecond scale differences impact dollar value? You could have and that could perfectly justify a new set of frameworks that solve those use cases. The majority of the time in my experience, people just move from one toolkit to another not because they evaluated requirements or pain points and found something truly better but because it’s the cool new thing. It all ends up being garbage tech debt.
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.
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.
> "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."
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.
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.
How many apps require web storage? Are there sufficient requirements to implement web workers or service workers?
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.
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.
To come back to the OP: "Why does front-end development change so often?"
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. ;)
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. ;)
> How many apps require web storage? Are there sufficient requirements to implement web workers or service workers?
Most B2B apps and apps with monthly subscriptions.
Most B2B apps and apps with monthly subscriptions.
I noticed that even with a small project with only 3 dependencies the dev dependencies are still large. As an example I was trying to build this project tui.image-editor from GitHub, it has 3 dependencies but check how many dev dependencies it has https://github.com/nhnent/tui.image-editor/blob/master/packa... and how many those may also have, when I installed them with npm I counted around 10 deprecation warnings and I was thinking that in a few years we may not be able to build this projects, we may have to hunt around for old version of stuff, fix conflicts between packages and other nightmare scenarios.
Maybe it would be a good idea to commit the node modules to GitHub?
Maybe it would be a good idea to commit the node modules to GitHub?
I assume you are talking about GUIs over TCP/IP, in which case a large part of the reason is the mismatch between what is used by most GUI software versus what we use over TCP. Most of the best ideas get voted down, and there is no agreement about how high level or low level the language should be. As an example, see what I wrote in “The problem with HTML”
http://www.smashcompany.com/technology/the-problem-with-html
It’s worth remembering that Swing has been stable for awhile, after a terrible era when new layouts were being proposed every 6 months. And Flash had a long era , nearly 20 years, of remaining mostly the same (though ActionScript 3 was a significant change compared to version 2).
There has been a lot of talk about generating GUIs as pure SVG, but this hasn’t happened yet. Is that too low level? There has been some talk of generating GUIs with PostScript, but that hasn’t happened yet. Is that too low level?
I suspect change will be constant until the industry reaches some consensus about what level causes the least pain.
I don’t believe Javascript will survive. Eventually this current era will be a bad memory and we will laugh about Javascript the way we now laugh about Swing and ActionScript.
http://www.smashcompany.com/technology/the-problem-with-html
It’s worth remembering that Swing has been stable for awhile, after a terrible era when new layouts were being proposed every 6 months. And Flash had a long era , nearly 20 years, of remaining mostly the same (though ActionScript 3 was a significant change compared to version 2).
There has been a lot of talk about generating GUIs as pure SVG, but this hasn’t happened yet. Is that too low level? There has been some talk of generating GUIs with PostScript, but that hasn’t happened yet. Is that too low level?
I suspect change will be constant until the industry reaches some consensus about what level causes the least pain.
I don’t believe Javascript will survive. Eventually this current era will be a bad memory and we will laugh about Javascript the way we now laugh about Swing and ActionScript.
Why was this downvoted? What part of this is untrue or inaccurate?
If you think about the front end ecosystem, in an economics sense, you will notice these distinct players : browsers, JS libraries/frameworks, apps/websites consuming these to provide solutions for the end user and the web devs.
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.
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.
Here’s a controversial opinion. Most junior programmers start off programming front end. And most of them don’t fully understand the frameworks they are using. So there is a bit of a herd mentality when it comes to front end development. They will rush to the next hot thing because of all the shiny new things it can do.
Not sure that’s controversial ; )
There are some additional insights at a similar Hacker News Discussion. Why Is Front-End Development So Unstable? https://news.ycombinator.com/item?id=17190992
I started learning web development last year and have been completely overwhelmed by all of the tools, frameworks, etc. that are out there. I found the back-end to be a lot easier to pick up than the front-end.
Granted, I’ve been using Python for a long time and chose it (Django) for my back-end. It helped to not have to learn both the language, the framework, and concepts at the same time.
I was so frustrated with Vue that I ended up going with Elm. I did not have a background in functional programming, but I found it so much simpler than trying to learn Vue or React.
Granted, I’ve been using Python for a long time and chose it (Django) for my back-end. It helped to not have to learn both the language, the framework, and concepts at the same time.
I was so frustrated with Vue that I ended up going with Elm. I did not have a background in functional programming, but I found it so much simpler than trying to learn Vue or React.
Combination of "it is not there yet" and "a lot of people need it".
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).
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).
Web development has been the greatest nexus of software innovation for the last two decades, and its influence has transformed the entire landscape around it. It has fundamentally changed data storage (XML, JSON), app integration (embedded Google Maps, share buttons), graphic design (CSS sweeping away embedded images and paving the road to flat design), and much more.
Many of these innovations began as surprising hacks which pushed browsers beyond their limits and created significant problems with security, performance, and visual rendering.
As these hacks became mainstream features, developers took two different approaches to fixing the problems. Some worked on creating front-end libraries which smoothed over the flaws in the browsers, while others worked on the more difficult problem of fixing the browsers themselves.
Front-end Javascript libraries can significantly improve developer productivity and a new, improved framework will see rapid and widespread adoption. However, the slower work of fixing the browsers themselves continues in the background, making those Javascript libraries obsolete and introducing powerful new browser features.
As we speak, there is an incredible array of new features in the latest browsers which are going mostly unused, because most web developers don't want to touch them until that last 5% of older browsers die off. Today, it might look as if a certain web framework is the be-all and end-all of web development, but in reality the groundwork has already been laid for it to be obsoleted and replaced by better, faster, more secure, more productive tools.
Many of these innovations began as surprising hacks which pushed browsers beyond their limits and created significant problems with security, performance, and visual rendering.
As these hacks became mainstream features, developers took two different approaches to fixing the problems. Some worked on creating front-end libraries which smoothed over the flaws in the browsers, while others worked on the more difficult problem of fixing the browsers themselves.
Front-end Javascript libraries can significantly improve developer productivity and a new, improved framework will see rapid and widespread adoption. However, the slower work of fixing the browsers themselves continues in the background, making those Javascript libraries obsolete and introducing powerful new browser features.
As we speak, there is an incredible array of new features in the latest browsers which are going mostly unused, because most web developers don't want to touch them until that last 5% of older browsers die off. Today, it might look as if a certain web framework is the be-all and end-all of web development, but in reality the groundwork has already been laid for it to be obsoleted and replaced by better, faster, more secure, more productive tools.
A UI framework has to accommodate a huge range of projects of massively varying complexity, from barebones text layout to global enterprise across hundreds of types of devices. But people also want it to be simple enough to learn easily, prototype quickly, and maintain long-term without significant headaches. There ain't no such thing as a free lunch when it comes to simplifying complexity, so one framework cannot rule them all. So we get new ways to do stuff, constantly.
Browser developers are for some reason putting effort in JS engines, speed but ignore working on the UI elements, you still can't CSS the scrollbars in Firefox (so projects use big JS libraries) , you can't css the select element and it's options so again you have to use JS to create a custom select, but some projects will use some jQuery library for this missing components, others will use bootstrap, others will wrap this other ones... web components could make this mess a bit cleaner but for some reason they are not ready or nobody uses them.
There's actually two facts you have to consider side by side
1. Front-end dev changes often
2. Websites have become worse at being websites
Like AMP, single-page apps being mostly broken if not viewed in a pristine no-addon Chrome, loading megabytes of scripts to display a bit of text, overlays blocking the screen, sluggish scrolling, broken dynamic loading, misused and misunderstood statistical testing suites, fragile "graceful" third party content everywhere, less accessability, pop-ups, now scripted, again! ... the list goes on and on.
Being good at displaying text is now a killer feature of only few elite websites... Imagine that.
I believe front-end devs are much less sophisticated programmers than the frameworks they use. Those frameworks are usually years of work from big corps geared at a specific use-case. Back in the day, before so many new technologies, people were hesitant to write websites with tools they would not be able to write themselves.
Today, I do not think more than a fraction of front-end devs actually understand what all these new technologies are doing under the hood, nor could write them themselves.
And if you are already playing with Legos, it of course leads to putting in too much stuff without sense and too much stuff where it doesn't belong.
Finally, I think everyone (subconciously?) realized that the web has become bad. But if the only option you see is a new framework, then people chase after new tech instead of writing better websites with simple technologies.
1. Front-end dev changes often
2. Websites have become worse at being websites
Like AMP, single-page apps being mostly broken if not viewed in a pristine no-addon Chrome, loading megabytes of scripts to display a bit of text, overlays blocking the screen, sluggish scrolling, broken dynamic loading, misused and misunderstood statistical testing suites, fragile "graceful" third party content everywhere, less accessability, pop-ups, now scripted, again! ... the list goes on and on.
Being good at displaying text is now a killer feature of only few elite websites... Imagine that.
I believe front-end devs are much less sophisticated programmers than the frameworks they use. Those frameworks are usually years of work from big corps geared at a specific use-case. Back in the day, before so many new technologies, people were hesitant to write websites with tools they would not be able to write themselves.
Today, I do not think more than a fraction of front-end devs actually understand what all these new technologies are doing under the hood, nor could write them themselves.
And if you are already playing with Legos, it of course leads to putting in too much stuff without sense and too much stuff where it doesn't belong.
Finally, I think everyone (subconciously?) realized that the web has become bad. But if the only option you see is a new framework, then people chase after new tech instead of writing better websites with simple technologies.
I've been using the same tech stack for the past four years, and I'm not planning on changing anything major anytime soon.
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.
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.
Four years is nothing. That you seem to think this is a long time is telling.
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.
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.
I only mention it because OP implied it's changing every year, which it's not. I'm well aware C and make are more than four years old, no need to be condescending.
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.
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.
I find it actually slowed down in recent years. Things finally seem to settle around the React ecosystem (yes yes, Vue has more stars). I also think there are way more projects which help you get started now without having to know all the tooling around it right of the beginning.
Regardless if you are working on a project and you have to deliver then simply stick with what you know. It does not matter what is the latest shiny thing out there and in most cases it won't matter in a few more years into the project as well.
If you want to learn something (new) in the frontend space though and also build something useful, the best approach I found is to only adapt one or two new things and have most of it build on what you know (using the 80/20 rule).
Regardless if you are working on a project and you have to deliver then simply stick with what you know. It does not matter what is the latest shiny thing out there and in most cases it won't matter in a few more years into the project as well.
If you want to learn something (new) in the frontend space though and also build something useful, the best approach I found is to only adapt one or two new things and have most of it build on what you know (using the 80/20 rule).
Couple ideas:
Maybe it doesn't change often, but the developer pool is full of people early in their career who would rather find the next big thing and get in on the ground level than be 3-5 years behind the curve on the existing stuff. And then they tweet all day about it.
Maybe it does change often, because there's such a focus on build tools and developer ergonomics; and doing that in 201X lets you follow the treasure map made by the ppl who already figured it all out for systems programming decades ago. The kids are calling it transpilation and tree-shaking these days. They're writing APIs for GPU access, and assembly code for the bits that need to be really performant.
Maybe it doesn't change often, but the developer pool is full of people early in their career who would rather find the next big thing and get in on the ground level than be 3-5 years behind the curve on the existing stuff. And then they tweet all day about it.
Maybe it does change often, because there's such a focus on build tools and developer ergonomics; and doing that in 201X lets you follow the treasure map made by the ppl who already figured it all out for systems programming decades ago. The kids are calling it transpilation and tree-shaking these days. They're writing APIs for GPU access, and assembly code for the bits that need to be really performant.
I think there are a few reasons for that.
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.
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.
I think alot of it comes down to the fact that the internet, and frontend-development (web development mostly) is relatively new. And as with anything new, the community is just trying everything they can to make it work until something eventually sticks.
As someone who has done this for a while, I remember how difficult it was to try and build a UI using flash, then later with just html and jQuery, and now with modern libraries like React. So while it seems like every year there is a new "better" way to do something, but that is mostly because is is getting better and easier over time.
As someone who has done this for a while, I remember how difficult it was to try and build a UI using flash, then later with just html and jQuery, and now with modern libraries like React. So while it seems like every year there is a new "better" way to do something, but that is mostly because is is getting better and easier over time.
Front-end web development is at least as old as the web itself so I’m not sure I agree with that argument.
Immaturity. think about a time when you changed the most. When was it? Web apps use to be sites with a bit of javascript and they've been growing up these past 18 years. That's it. It's growing pains.
Related to this topic:
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?
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?
I'd say react.js. It has been proven to be a good choice for all kind of web applications (small, large) and even static web sites (https://www.gatsbyjs.org/, https://github.com/nozzle/react-static). Also it has an awesome community and awesome tooling (create-react-app), which allow you not to bother with "framework/library/build tool/transpiling hell".
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
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
Thanks, I keep hearing great things about React, not to mention the added bonus of React Native. I’ll look into it further.
it evolves quickly because the whole field is based on a couple of hacks, and the possibility manifold is being constantly dilated via the tiny hole they opened.
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.
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.
> it evolves quickly because the whole field is based on a couple of hacks
What are the two hacks the whole field is based on?
What are the two hacks the whole field is based on?
Aside from a critical mass of developers, another reason is: Because it can. I can access new, proposed features not yet implemented in any browser with polyfills and transpilation. Distribution is not a problem (sans file sizes) because the user downloads the newest version every visit. Now, if IE users would just go in a cave and die peacefully...
Fairly recently rendering in the client became possible and desirable. This was a paradigm shift, it raised a lot of new problems, and a number of attempts were made at solving these issues. The field is settling now on the ideas with the most merit. Reacts idea of the virtual dom is an example of an idea that is becoming a stable standard.
Is rendering the right word here? It doesn't feel like it is to me. I thought rendering was the final step in taking a DOM and turning it into something that is shown on the screen. Basically, the job of the browser. Based on your logic you're saying that before now rendering was happening on the server, but that doesn't make sense.
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.
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.
Curious, does javascript, the language itself, cause this rate of change (whether you see it as a good thing, or as a bad thing), over server side languages, java etc.
It's a fad, built of fads. Front-end stuff is able to do a lot more than it was a few years ago, in a lot of different ways. So everyone wants to get on board (it's a fad) to take advantage of that, trying various things out, hoping to find the best way (those attempts become fads) to do things. Most of it is noise and only time will tell what was signal. Some few classics will live on, but most of what is being done now will quickly be forgotten. So things are rapidly starting and also being rapidly relegated to the dust-heap.
The web is young so there's lots of room for growth (and thus lots of work to be done)
I often wonder how different things would be if JavaScript had a standard library.
The barrier to entry for frontend is lower and it's easier to present your new idea visually so people are more likely to bite. There's also a lot of money and/or glory in becoming and "influencer" and the easiest way to do this is to create a new framework.
> Why do you think front-end development is in such a constant state of change?
Browsers have been resistant to change and meeting standards for the longest time. This resistance to change has meant that the core libraries (i.e. vanilla Javascript) have been inadequate for large-scale front-end applications. Today browsers are much better than they used to be about keeping to spec, and the days of old IE hacks in your front-end code are mostly gone. In addition, you had other hacks in the front-end (using tables/floats and other arcane CSS tricks to get things to render properly)
These issues caused a surge in wrappers to appear to 1) encapsulate all of the hacks and 2) present a better interface than core JS had. jQuery was the biggest player at this time and you were crazy to try and develop without it. People became accustomed to jQuery and then started to iterate on that (we got Promises, we got people thinking about how to encapsulate and automate changes with an API, we got people thinking about how data should be bound to components). Backbone, Angular, and Ember all appeared to try and solve these issues
Fast-forward a few more years and you have a new set of problems and proposed solutions. Tools started getting complex and people would fork off new ideas
Today the browsers are better than they were years ago, and I expect we'll eventually revert to vanilla JS, but there are a couple of issues that the browser still hasn't solved:
* How do you componentize CSS with JS in a sane way? Loading everything into a global namespace is kind of crappy
* How do handle a growing language specification? Unlike server-side languages where you control everything, browsers may be on different versions, etc - how do you still write portable code?
* How do you efficiently cache, transport, and invalidate your assets? There are multiple schools of thought here, and I believe HTTP 2.0 will have a big effect on this
TLDR; the community is moving faster than the browser and building their own solutions to hack around problems, thus you have a lot of churn as problems evolve and the browsers get better
Browsers have been resistant to change and meeting standards for the longest time. This resistance to change has meant that the core libraries (i.e. vanilla Javascript) have been inadequate for large-scale front-end applications. Today browsers are much better than they used to be about keeping to spec, and the days of old IE hacks in your front-end code are mostly gone. In addition, you had other hacks in the front-end (using tables/floats and other arcane CSS tricks to get things to render properly)
These issues caused a surge in wrappers to appear to 1) encapsulate all of the hacks and 2) present a better interface than core JS had. jQuery was the biggest player at this time and you were crazy to try and develop without it. People became accustomed to jQuery and then started to iterate on that (we got Promises, we got people thinking about how to encapsulate and automate changes with an API, we got people thinking about how data should be bound to components). Backbone, Angular, and Ember all appeared to try and solve these issues
Fast-forward a few more years and you have a new set of problems and proposed solutions. Tools started getting complex and people would fork off new ideas
Today the browsers are better than they were years ago, and I expect we'll eventually revert to vanilla JS, but there are a couple of issues that the browser still hasn't solved:
* How do you componentize CSS with JS in a sane way? Loading everything into a global namespace is kind of crappy
* How do handle a growing language specification? Unlike server-side languages where you control everything, browsers may be on different versions, etc - how do you still write portable code?
* How do you efficiently cache, transport, and invalidate your assets? There are multiple schools of thought here, and I believe HTTP 2.0 will have a big effect on this
TLDR; the community is moving faster than the browser and building their own solutions to hack around problems, thus you have a lot of churn as problems evolve and the browsers get better
As some others have mentioned but more TLDR: It hasn't changed that much if you bet on the right horse at the beginning of the "SpaSplosion". React is the best example, having been around for close to 7 years.
For a while the biggest issue was that there was no SPA framework or module loader that had been around for more than a few years. Now at least we have webpack, npm and yarn. Things feel like they're becoming sane.
Assuming JS stabilizes as other languages have, React is a safe bet for another decade due to its popularity.
Another safe bet appears to be TypeScript. So if you are okay with following the crowd, a React + TypeScript project should feel "modern" and upgradable for a long time
For a while the biggest issue was that there was no SPA framework or module loader that had been around for more than a few years. Now at least we have webpack, npm and yarn. Things feel like they're becoming sane.
Assuming JS stabilizes as other languages have, React is a safe bet for another decade due to its popularity.
Another safe bet appears to be TypeScript. So if you are okay with following the crowd, a React + TypeScript project should feel "modern" and upgradable for a long time
Will webasm change this all again?
Unlike backend frontend isn't built on a solid foundation.
So 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.
So 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.
Because a few years ago it was the most easy to use language and people were creating brilliant tools and software libraries that, truly, changed the world. Because of the low barrier to entry everyone and their grandma became copycats by releasing their own revolutionary new framework. For a long while being a master of the majority of the JavaScript landscape made you elite. So developers minds were stretched, no, pulled apart by the diverging number of JavaScript frameworks.
Before long the list of things they were supposed to keep track of got so long that it just became impossible to do. I haven't been able to keep track of it since but I assume that just means the number of JavaScript frameworks is expanding faster than the speed of light.
Before long the list of things they were supposed to keep track of got so long that it just became impossible to do. I haven't been able to keep track of it since but I assume that just means the number of JavaScript frameworks is expanding faster than the speed of light.
[deleted]