4 ms·

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 v

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.

aastronaut 8y ago
> "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.
- throwaway98121 8y ago
  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.
  - aastronaut 8y ago
    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. ;)
  - aastronaut 8y ago
    > 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.

aastronaut 8y ago

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

throwaway98121 8y ago
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.
- aastronaut 8y ago
  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. ;)
- aastronaut 8y ago
  > 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.