Live data from Hacker News

Ask HN: Why does front-end development change so often?

news.ycombinator.com

51–60 of 83 posts

Re: Ask HN: Why does front-end development change so often?

#51
post #17

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)…

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'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...

Re: Ask HN: Why does front-end development change so often?

#52
post #50

Earlier quoted context omitted.

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…

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 hav…

> 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.

Re: Ask HN: Why does front-end development change so often?

#53
post #17

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)…

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

Re: Ask HN: Why does front-end development change so often?

#54
> 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

Re: Ask HN: Why does front-end development change so often?

#55
post #16

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…

> 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

Re: Ask HN: Why does front-end development change so often?

#56
post #9

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.

Re: Ask HN: Why does front-end development change so often?

#57
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.

Re: Ask HN: Why does front-end development change so often?

#58

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 ne…

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

Re: Ask HN: Why does front-end development change so often?

#59
post #17

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)…

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 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.

Re: Ask HN: Why does front-end development change so often?

#60

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 ne…

Is it in your mind/words harder than backend development?
Post reply on HN