5 ms·

It's because of all the icky data-sync for the client/service round trips. An async, slow, failure-prone concern wired throughout the entire codebase. I/O hurts

It's because of all the icky data-sync for the client/service round trips. An async, slow, failure-prone concern wired throughout the entire codebase. I/O hurts everyone in subtly different ways and it's hard to solve so you see a lot of churn. service/database has this problem too (the ORM flamewars of the 00s) but to a much less degree because it is in a happier place on the latency chart: https://gist.github.com/jboner/2841832 https://gist.github.com/jboner/2841832

nicoburns 8y ago
I agree with this. It also doesn't help that frontend code usually has to run on several versions of at 3 different runtimes. With backend code you can freely either stick with an older platform for stability, and adopt a new platform for new features. With frontend you don't have that choice in the same way.
dustingetz 8y ago
Continued: Churn is further compounded by the Lisp Curse; an individual hacker can scratch his itch in Javascript all by himself and then stick it on github, the other three 1995 langs (Java/Ruby/Python) never quite reached this level of empowerment of individuals. That's great but also means an explosion of activity from smart inexperienced hackers who don't quite have a full understanding of the problem they are trying to solve because they are just one person. And when the problem is I/O that's a recipe for going in circles. http://winestockwebdesign.com/Essays/Lisp_Curse.html http://winestockwebdesign.com/Essays/Lisp_Curse.html
rubber_duck 8y ago
Not really - those things exist in native frontend as well but it's more stable than js. Writing GUI is not trivial, people take stuff like data binding/templates/MVC etc. for granted nowadays, go check out early desktop UI libraries like say win32/MFC/winforms/gtk+. Took a long time to get to stuff like WPF, Qt quick, etc. With browser there were several constraints : ES5 is extremely error prone and scales very poorly to larger codebases slow JS VMs missingt for sane layout like flexbox 1. Got better with npm, we pack, es6 transpilers, typescript/flow and tooling built along the way 2./3. Got solved by finally depricating everything < IE9 (IE in general if you're lucky) and tooling I'd say angular is relatively stable now and decently productive once you get a hang of their patterns, I've been using it for different frontend projects since early betas, written ionic apps for mobile with it - have very few complaints about the framework, some of the stuff didn't always work along the way (like ahead of time compilation, i18n) but recently (5+) I've had 0 issues with the framework and I'm quite productive with it. I think the alternatives will mature as well and things will settle.
- dustingetz 8y ago
  Native frontend on desktop and mobile have in-memory database and sync out of band. Web browser tab is too resource constrained to run a in-memory database, and less secure as well (you don't have root on your iphone so Facebook can restrict your data access patterns, prevent scrapers, prevent mass-delete of all those old posts, etc)
  - rubber_duck 8y ago
    Those things don't remove the sync issues, blocking the UI thread, they just enable a slightly better use experience. And dealing with asynchronous code is not the only issue in writing frontend code, GUI apps can be really complex beasts, managing that complexity effectively requires tools that didn't exist in js world untill recently.
    - dustingetz 8y ago
      They kind of do though, the complexity of data sync can now be dealt with entirely separately from the complexity of the app logic itself (which is not true of, say REST architecture)
michaelchisari 8y ago
Related to this is the idea that people believe front-end software development is easy. In reality, it's one of the most challenging, chaotic and difficult parts of the development chain, especially when talking about web development.
- collyw 8y ago
  Its difficult but not in a "satisfying to solve" way.

nicoburns 8y ago

I agree with this. It also doesn't help that frontend code usually has to run on several versions of at 3 different runtimes. With backend code you can freely either stick with an older platform for stability, and adopt a new platform for new features. With frontend you don't have that choice in the same way.

dustingetz 8y ago

Continued: Churn is further compounded by the Lisp Curse; an individual hacker can scratch his itch in Javascript all by himself and then stick it on github, the other three 1995 langs (Java/Ruby/Python) never quite reached this level of empowerment of individuals. That's great but also means an explosion of activity from smart inexperienced hackers who don't quite have a full understanding of the problem they are trying to solve because they are just one person. And when the problem is I/O that's a recipe for going in circles. http://winestockwebdesign.com/Essays/Lisp_Curse.html http://winestockwebdesign.com/Essays/Lisp_Curse.html

rubber_duck 8y ago

Not really - those things exist in native frontend as well but it's more stable than js. Writing GUI is not trivial, people take stuff like data binding/templates/MVC etc. for granted nowadays, go check out early desktop UI libraries like say win32/MFC/winforms/gtk+. Took a long time to get to stuff like WPF, Qt quick, etc. With browser there were several constraints : ES5 is extremely error prone and scales very poorly to larger codebases slow JS VMs missingt for sane layout like flexbox 1. Got better with npm, we pack, es6 transpilers, typescript/flow and tooling built along the way 2./3. Got solved by finally depricating everything < IE9 (IE in general if you're lucky) and tooling I'd say angular is relatively stable now and decently productive once you get a hang of their patterns, I've been using it for different frontend projects since early betas, written ionic apps for mobile with it - have very few complaints about the framework, some of the stuff didn't always work along the way (like ahead of time compilation, i18n) but recently (5+) I've had 0 issues with the framework and I'm quite productive with it. I think the alternatives will mature as well and things will settle.

dustingetz 8y ago
Native frontend on desktop and mobile have in-memory database and sync out of band. Web browser tab is too resource constrained to run a in-memory database, and less secure as well (you don't have root on your iphone so Facebook can restrict your data access patterns, prevent scrapers, prevent mass-delete of all those old posts, etc)
- rubber_duck 8y ago
  Those things don't remove the sync issues, blocking the UI thread, they just enable a slightly better use experience. And dealing with asynchronous code is not the only issue in writing frontend code, GUI apps can be really complex beasts, managing that complexity effectively requires tools that didn't exist in js world untill recently.
  - dustingetz 8y ago
    They kind of do though, the complexity of data sync can now be dealt with entirely separately from the complexity of the app logic itself (which is not true of, say REST architecture)

michaelchisari 8y ago

Related to this is the idea that people believe front-end software development is easy. In reality, it's one of the most challenging, chaotic and difficult parts of the development chain, especially when talking about web development.

collyw 8y ago
Its difficult but not in a "satisfying to solve" way.