6 ms·

> developing became more and more inefficient Anecdotally I find the opposite to be true. I've been writing frontend code for over a decade, but I've never mov

by switz 6y ago

> developing became more and more inefficient Anecdotally I find the opposite to be true. I've been writing frontend code for over a decade, but I've never moved faster and wrote less buggy code than now. Is that because I've become a better developer? Sure, a little bit. But by and large, I don't believe that ultimately is the reason. I think it's the maturity in the technology. My growth as a programmer is hardly linear and the past 5 years have not matched the growth I achieved in my first 5. Frontend tooling has never been better than it is today. What I believe, is that the bar to build web applications has been lowered, and there are more programmers than today than ever before. You have people who are not experts in frontend development and javascript trying to build complex UIs and applications. So you take this person who doesn't have the requisite experience and put them to work on a paradigm with a lot of depth (frontend) using frameworks that are really simple and easy to get started with, but compound problems as they are misused. Another factor is that since SPAs are stateful, complexity mounts aggressively. Instead of a refresh on a stateless page every few seconds, one page causes bugs that rear their head for the duration of the session. These inexperienced people are put in charge of designing codebases that don't scale and become spaghetti. But when designed properly, these problems are largely negated. I'm not advocating that SPAs are the solution to all problems. I think there's gross overuse of SPAs across the industry, but that is not an indictment of SPAs themselves. That is someone choosing the wrong technology to solve the active problem. With respect to angular (1, I never touched 2) specifically, I always found it extremely overengineered, poorly designed, with terrible APIs. But that's a problem with that specific framework and says nothing at all about SPAs at all.

Nextgrid 6y ago
> Frontend tooling has never been better than it is today. What's the library or design pattern to consume a REST API in React or any of the mainstream front-end frameworks? The only thing I'm aware of is Ember Data but Ember is apparently not cool anymore, and I couldn't find a suitable replacement. I'm asking because in all the projects I've been involved with, consuming the backend API always felt like a mess with lots of reinventing the wheel (poorly) and duplication of code. I can't believe in 2020 there's not some kind of library I can call that will give me my backend resources as JSON and transparently handle all the caching, pagination, error handling (translate error responses to exceptions), etc and people have to do all this by hand when calling something like Axios. In contrast, Django REST Framework handles all that boilerplate for me and allows me to jump right into writing the business logic. It's insane that ~30 lines of code with DRF (https://www.django-rest-framework.org/#example https://www.django-rest-framework.org/#example) gives me a way to expose RESTful endpoints for a database model to the web with authentication, pagination, validation, filtering, etc in a reusable way (these are just Python classes after all) but the modern front-end doesn't have the client equivalent of this.
- jeremyjh 6y ago
  The graphql frameworks - like Apollo - give you that. I haven't used it. For basic caching the state management frameworks work pretty well, but it is a lot of layers when you add Redux or Vuex to your stack. It works well for us though and I find it much easier to reason about than the old jquery spaghetti code style.
- catlifeonmars 6y ago
  I hear you. I find myself needing to reinvent the wheel far too often to traverse the boundary between the client and server. I also feel that it shouldn’t be this hard. Apollo client and relay solve this problem for GraphQL APIs (quite nicely IMO). What’s missing is an Apollo client for non-GraphQL APIs.
- Merad 6y ago
  > I'm asking because in all the projects I've been involved with, consuming the backend API always felt like a mess with lots of reinventing the wheel (poorly) and duplication of code. I can't believe in 2020 there's not some kind of library I can call that will give me my backend resources as JSON and transparently handle all the caching, pagination, error handling (translate error responses to exceptions), etc and people have to do all this by hand when calling something like Axios. If you look at 20 REST API's you'll probably see 30 different patterns for pagination, search/sort, error responses, etc. There have been a couple attempts to standardize REST such as OData but I think it's safe to say that they haven't been very successful. It's kind of challenging to build standard reusable front end tools when everyone builds back ends differently.
  - Nextgrid 6y ago
    Ember has somewhat solved that problem though. You have the concept of data adapters which would be clients for your API (you can make a custom one if extending the existing ones isn't an option) and the rest of the application just interacts with the equivalent of database models without ever having to worry about fetching the data. You could swap the data adapter without having to change the rest of the code. We seem to have lost this with the move to React though, and even the hodgepodge of libraries doesn't provide a comparable replacement.
save_ferris 6y ago
> These inexperienced people are put in charge of designing codebases that don't scale and become spaghetti. I think this is one area where front end tooling can be painful for the average dev. The bar to writing idiomatic JS for a given framework can get pretty high quickly, especially when you look at some of the really popular tools out there (i.e. redux). Front end work has become so much harder to grok because the patterns around things like state management still have a lot of warts. The terminology of redux drives me crazy because it’s really difficult to explain things like reducers.
- pwdisswordfish4 6y ago
  What most people have in mind as "idiomatic JS" isn't that. It's usually meant to refer to some patterns that appeared and started getting popular around 8 years ago. And often, code written in this not-idiomatic way works _against_ the language and/or the underpinnings of the Web in general. It's just that the circles promoting the pseudo-idioms have outsized and seemingly inescapable influence.
  - rlt 6y ago
    This is very vague. Can you give some examples?
    - pwdisswordfish4 6y ago
      The question asking for clarification is itself vague. Examples of which part? Look at JS that's written for serious applications today, identify the stuff that you'd label as "idiomatic", and then look at code that was written 10 years ago for serious applications, and see if it matches what your conception of "idiomatic JS" is. Good references for the way JS was written for high-quality applications without the negative influence of the new idioms (because they didn't exist yet): the JS implementing Firefox and the JS implementing the Safari Web Inspector. Examples of how "idiomatic JS" is often written by people who are working against the language instead of with it: - insistence on overusing triple equals despite the problems that come with it - similarly, the lengths people go to to treat null and undefined as if they're synonymous - config parameter hacks and hacks to approximate multiple return values - `require`, NodeJS modules, and every bundler (a la webpack) written, ever - `let self = this` and all the effort people go through not to understand `this` in general (and on that note, not strictly pure JS, but notice how often the `self` hack is used for DOM event handlers because people refuse to understand the DOM EventListener interface) - every time people end up with bloated GC graphs with thousands of unique objects, because they're creating bespoke methods tightly coupled via closure to the objects that they're meant for because lol what are prototypes These "idioms" essentially all follow the same "maturation" period: 1. A problem is encountered by someone who doesn't have a solid foundation 2. They cross-check notes with other people in the same boat, and the problem is deemed to have occurred because of a problem in the language 3. A pattern is adopted that "solves" this "problem" 4. Now you have N problems People think of this stuff as "idiomatic JS" because pretty much any package that ends up on NPM is written this way, since they're all created by people who were at the time trying to write code like someone else who was trying to write code like the NodeJS influencers who are considered heroes within that particular cultural bubble, so it ends up being monkey-see-monkey-do almost all the way down.
rawoke083600 6y ago
I definitely agree you, F.E Tools has gotten a lot more mature and we have a lot further to go as well. I'm primarily a backend developer and I think in general backend developers makes for "poor fronted devs". I'm talking about those "occasional" times the backend-dev needs to do some f.e dev work. Just because they don't know the tech as well, best practises and spend as much time with it as a dedicated F.E Dev. jQuery code written by the "occasional front-end dev" is kinda horrific in many cases. Now please internet hear me. I'm not saying you can't write bad code in a JS-Framework. I'm saying it's usually less often and less bad - especially for non-dedicated f.e devs Like crossing a street, just looking left and right won't guarantee you to be safe in your crossing, but it damn near makes it less probable. If you are a shop with mostly backend-devs and don't want to invest in a F.E dev, you definitely should look into a js-framework. *Svelte is always good start very small and bare bones.
- ratww 6y ago
  > If you are a shop with mostly backend-devs and don't want to invest in a F.E dev, you definitely should look into a js-framework. That matches in my experience. I worked in a shop with only backend developers and the frontend was an absolute buggy mess of jQuery on top of bootstrap. After migrating most of it to Vue I taught it to the team and all the experienced-but-frontend-shy developers started producing great frontend code by themselves.
- rendall 6y ago
  > Svelte is always good start very small and bare bones I second this The barrier to entry is lower than for React, and the results are great
bryanrasmussen 6y ago
>What I believe, is that the bar to build web applications has been lowered, Yes, the bar to build web applications has been lowered. We can all build something on the level of GMail now. The ability to build websites has been crippled, because you are often forced to build the sites using the tools suited to applications. As you and both the parent comment seem to agree on.
LoSboccacc 6y ago
> Frontend tooling has never been better than it is today. eh. Swing in its golden age run circle around what we have now. Granted it's old tech now that we settled for in-browser delivery, but still: - look and feels could do theming you can only dream of with css variables/scss - serialize and restore gui states partially or whole, including listeners - value binding systems vue can only dream of - native scrollers everywhere you could style and listen to without the rendered complaining about passive handlers. - layout that didn't threw a fit about forced reflows - unhappy with the standard layouts? build your own one as needed - debug everything, including the actual render call that put an image where it is - works the same in all supported os browsers are an insufferable environment to work within compared to that, css is powerful and all but you get a system you can only work by inference, and were everything interferes with everything else by default, which works great to style a document and is a tragedy in an app with many reusable nested components.
- doctor_eval 6y ago
  Not to be mean, but I worked with Swing for ten years and it was absolute crap. Constantly dealing with resizing “collapsars”, GBLs, poor visual compatibility with the host OS, a fragile threading model and piles and piles of unfixed bugs and glitches was a nightmare. It might have worked if you had a specific end user environment but it was a PITA for anything else, and deployment was even harder. There are a few things I definitely miss from my 20 years as a Java dev, but the half assed and under funded Swing UI is not among them. Give me HTML+CSS+JS any time.
  - LoSboccacc 6y ago
    well we're talking about the tooling, but point taken, swing wasn't perfect (totally grid bag 2007 short https://www.youtube.com/watch?v=UuLaxbFKAcc https://www.youtube.com/watch?v=UuLaxbFKAcc ) but it's not like it was that worse than flex bugs ( https://codepen.io/sandrosc/pen/YWQAQO https://codepen.io/sandrosc/pen/YWQAQO still does render differently in chrome than firefox - which one is wrong is immaterial)
  - thu2111 6y ago
kochthesecond 6y ago
Yeah, there is some overuse of SPAs I agree, but havent anyone in this thread worked in older java monoliths with JSP or even good old Struts framework?? THEN you can see what inefficient development looks like.

by switz 6y ago

Nextgrid 6y ago

> Frontend tooling has never been better than it is today. What's the library or design pattern to consume a REST API in React or any of the mainstream front-end frameworks? The only thing I'm aware of is Ember Data but Ember is apparently not cool anymore, and I couldn't find a suitable replacement. I'm asking because in all the projects I've been involved with, consuming the backend API always felt like a mess with lots of reinventing the wheel (poorly) and duplication of code. I can't believe in 2020 there's not some kind of library I can call that will give me my backend resources as JSON and transparently handle all the caching, pagination, error handling (translate error responses to exceptions), etc and people have to do all this by hand when calling something like Axios. In contrast, Django REST Framework handles all that boilerplate for me and allows me to jump right into writing the business logic. It's insane that ~30 lines of code with DRF (https://www.django-rest-framework.org/#example https://www.django-rest-framework.org/#example) gives me a way to expose RESTful endpoints for a database model to the web with authentication, pagination, validation, filtering, etc in a reusable way (these are just Python classes after all) but the modern front-end doesn't have the client equivalent of this.

jeremyjh 6y ago
The graphql frameworks - like Apollo - give you that. I haven't used it. For basic caching the state management frameworks work pretty well, but it is a lot of layers when you add Redux or Vuex to your stack. It works well for us though and I find it much easier to reason about than the old jquery spaghetti code style.
catlifeonmars 6y ago
I hear you. I find myself needing to reinvent the wheel far too often to traverse the boundary between the client and server. I also feel that it shouldn’t be this hard. Apollo client and relay solve this problem for GraphQL APIs (quite nicely IMO). What’s missing is an Apollo client for non-GraphQL APIs.
Merad 6y ago
> I'm asking because in all the projects I've been involved with, consuming the backend API always felt like a mess with lots of reinventing the wheel (poorly) and duplication of code. I can't believe in 2020 there's not some kind of library I can call that will give me my backend resources as JSON and transparently handle all the caching, pagination, error handling (translate error responses to exceptions), etc and people have to do all this by hand when calling something like Axios. If you look at 20 REST API's you'll probably see 30 different patterns for pagination, search/sort, error responses, etc. There have been a couple attempts to standardize REST such as OData but I think it's safe to say that they haven't been very successful. It's kind of challenging to build standard reusable front end tools when everyone builds back ends differently.
- Nextgrid 6y ago
  Ember has somewhat solved that problem though. You have the concept of data adapters which would be clients for your API (you can make a custom one if extending the existing ones isn't an option) and the rest of the application just interacts with the equivalent of database models without ever having to worry about fetching the data. You could swap the data adapter without having to change the rest of the code. We seem to have lost this with the move to React though, and even the hodgepodge of libraries doesn't provide a comparable replacement.

save_ferris 6y ago

> These inexperienced people are put in charge of designing codebases that don't scale and become spaghetti. I think this is one area where front end tooling can be painful for the average dev. The bar to writing idiomatic JS for a given framework can get pretty high quickly, especially when you look at some of the really popular tools out there (i.e. redux). Front end work has become so much harder to grok because the patterns around things like state management still have a lot of warts. The terminology of redux drives me crazy because it’s really difficult to explain things like reducers.

pwdisswordfish4 6y ago
What most people have in mind as "idiomatic JS" isn't that. It's usually meant to refer to some patterns that appeared and started getting popular around 8 years ago. And often, code written in this not-idiomatic way works _against_ the language and/or the underpinnings of the Web in general. It's just that the circles promoting the pseudo-idioms have outsized and seemingly inescapable influence.
- rlt 6y ago
  This is very vague. Can you give some examples?
  - pwdisswordfish4 6y ago
    The question asking for clarification is itself vague. Examples of which part? Look at JS that's written for serious applications today, identify the stuff that you'd label as "idiomatic", and then look at code that was written 10 years ago for serious applications, and see if it matches what your conception of "idiomatic JS" is. Good references for the way JS was written for high-quality applications without the negative influence of the new idioms (because they didn't exist yet): the JS implementing Firefox and the JS implementing the Safari Web Inspector. Examples of how "idiomatic JS" is often written by people who are working against the language instead of with it: - insistence on overusing triple equals despite the problems that come with it - similarly, the lengths people go to to treat null and undefined as if they're synonymous - config parameter hacks and hacks to approximate multiple return values - `require`, NodeJS modules, and every bundler (a la webpack) written, ever - `let self = this` and all the effort people go through not to understand `this` in general (and on that note, not strictly pure JS, but notice how often the `self` hack is used for DOM event handlers because people refuse to understand the DOM EventListener interface) - every time people end up with bloated GC graphs with thousands of unique objects, because they're creating bespoke methods tightly coupled via closure to the objects that they're meant for because lol what are prototypes These "idioms" essentially all follow the same "maturation" period: 1. A problem is encountered by someone who doesn't have a solid foundation 2. They cross-check notes with other people in the same boat, and the problem is deemed to have occurred because of a problem in the language 3. A pattern is adopted that "solves" this "problem" 4. Now you have N problems People think of this stuff as "idiomatic JS" because pretty much any package that ends up on NPM is written this way, since they're all created by people who were at the time trying to write code like someone else who was trying to write code like the NodeJS influencers who are considered heroes within that particular cultural bubble, so it ends up being monkey-see-monkey-do almost all the way down.

rawoke083600 6y ago

I definitely agree you, F.E Tools has gotten a lot more mature and we have a lot further to go as well. I'm primarily a backend developer and I think in general backend developers makes for "poor fronted devs". I'm talking about those "occasional" times the backend-dev needs to do some f.e dev work. Just because they don't know the tech as well, best practises and spend as much time with it as a dedicated F.E Dev. jQuery code written by the "occasional front-end dev" is kinda horrific in many cases. Now please internet hear me. I'm not saying you can't write bad code in a JS-Framework. I'm saying it's usually less often and less bad - especially for non-dedicated f.e devs Like crossing a street, just looking left and right won't guarantee you to be safe in your crossing, but it damn near makes it less probable. If you are a shop with mostly backend-devs and don't want to invest in a F.E dev, you definitely should look into a js-framework. *Svelte is always good start very small and bare bones.

ratww 6y ago
> If you are a shop with mostly backend-devs and don't want to invest in a F.E dev, you definitely should look into a js-framework. That matches in my experience. I worked in a shop with only backend developers and the frontend was an absolute buggy mess of jQuery on top of bootstrap. After migrating most of it to Vue I taught it to the team and all the experienced-but-frontend-shy developers started producing great frontend code by themselves.
rendall 6y ago
> Svelte is always good start very small and bare bones I second this The barrier to entry is lower than for React, and the results are great

bryanrasmussen 6y ago

>What I believe, is that the bar to build web applications has been lowered, Yes, the bar to build web applications has been lowered. We can all build something on the level of GMail now. The ability to build websites has been crippled, because you are often forced to build the sites using the tools suited to applications. As you and both the parent comment seem to agree on.

LoSboccacc 6y ago

> Frontend tooling has never been better than it is today. eh. Swing in its golden age run circle around what we have now. Granted it's old tech now that we settled for in-browser delivery, but still: - look and feels could do theming you can only dream of with css variables/scss - serialize and restore gui states partially or whole, including listeners - value binding systems vue can only dream of - native scrollers everywhere you could style and listen to without the rendered complaining about passive handlers. - layout that didn't threw a fit about forced reflows - unhappy with the standard layouts? build your own one as needed - debug everything, including the actual render call that put an image where it is - works the same in all supported os browsers are an insufferable environment to work within compared to that, css is powerful and all but you get a system you can only work by inference, and were everything interferes with everything else by default, which works great to style a document and is a tragedy in an app with many reusable nested components.

doctor_eval 6y ago
Not to be mean, but I worked with Swing for ten years and it was absolute crap. Constantly dealing with resizing “collapsars”, GBLs, poor visual compatibility with the host OS, a fragile threading model and piles and piles of unfixed bugs and glitches was a nightmare. It might have worked if you had a specific end user environment but it was a PITA for anything else, and deployment was even harder. There are a few things I definitely miss from my 20 years as a Java dev, but the half assed and under funded Swing UI is not among them. Give me HTML+CSS+JS any time.
- LoSboccacc 6y ago
  well we're talking about the tooling, but point taken, swing wasn't perfect (totally grid bag 2007 short https://www.youtube.com/watch?v=UuLaxbFKAcc https://www.youtube.com/watch?v=UuLaxbFKAcc ) but it's not like it was that worse than flex bugs ( https://codepen.io/sandrosc/pen/YWQAQO https://codepen.io/sandrosc/pen/YWQAQO still does render differently in chrome than firefox - which one is wrong is immaterial)
- thu2111 6y ago

kochthesecond 6y ago

Yeah, there is some overuse of SPAs I agree, but havent anyone in this thread worked in older java monoliths with JSP or even good old Struts framework?? THEN you can see what inefficient development looks like.