Ask HN: Why does front-end development change so often? • Hacker News Board

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

#61

Post by spricket » Sun, Jan 20, 2019, 7:33 PM UTC

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

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

#62

Post by throwaway98121 » Sun, Jan 20, 2019, 7:38 PM UTC

aastronaut wrote: post #49

throwaway98121 wrote: post #19

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…

> "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." The…

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.

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

#63

Post by lkrubner » Sun, Jan 20, 2019, 7:41 PM UTC

lkrubner wrote: post #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…

Why was this downvoted? What part of this is untrue or inaccurate?

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

#64

Post by SomeHacker44 » Sun, Jan 20, 2019, 8:00 PM UTC

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.

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

#65

Post by bobthepanda » Sun, Jan 20, 2019, 8:19 PM UTC

MuffinFlavored wrote: post #60

thomasmeeks wrote: post #8

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?

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.

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

#66

Post by twtw » Sun, Jan 20, 2019, 9:07 PM UTC

thomasmeeks wrote: post #8

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…

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.

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

#67

Post by pryelluw » Sun, Jan 20, 2019, 10:09 PM UTC

SomeHacker44 wrote: post #64

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…

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.

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

#68

Post by i_phish_cats » Sun, Jan 20, 2019, 11:14 PM UTC

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

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

#69

Post by torte » Sun, Jan 20, 2019, 11:30 PM UTC

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

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

#70

Post by aastronaut » Mon, Jan 21, 2019, 12:48 AM UTC

throwaway98121 wrote: post #62

aastronaut wrote: post #49

Earlier quoted context omitted.

> "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." The…

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.

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