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.
Ask HN: Why does front-end development change so often?
31–40 of 83 posts
Re: Ask HN: Why does front-end development change so often?
#32To 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)…
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.…
> 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.
Re: Ask HN: Why does front-end development change so often?
#33The 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 e…
> Typescript's inability to handle libraries intended for the web 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 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.
Re: Ask HN: Why does front-end development change so often?
#34Combination 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).
Re: Ask HN: Why does front-end development change so often?
#35Earlier quoted context omitted.
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.…
> 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…
>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.
Re: Ask HN: Why does front-end development change so often?
#36Earlier quoted context omitted.
> 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…
>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 cor…
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).
Re: Ask HN: Why does front-end development change so often?
#37Earlier quoted context omitted.
> Typescript's inability to handle libraries intended for the web 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 a…
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.
Re: Ask HN: Why does front-end development change so often?
#38Earlier quoted context omitted.
>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 cor…
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).
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?
Re: Ask HN: Why does front-end development change so often?
#39To 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.
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?
Re: Ask HN: Why does front-end development change so often?
#40Here’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.