3 ms·

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

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

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.