4 ms·

Every time I've noticed I'm on a page using Angular or React the experience feels terrible. Like there are 100 different unnecessary things going on in the back

by Kequc 10y ago

Every time I've noticed I'm on a page using Angular or React the experience feels terrible. Like there are 100 different unnecessary things going on in the background. Though to be fair these are only the times I've noticed I'm on a page using one. Every time I've tried to pick up and learn Angular or React or etc, I've gotten the impression that it is wildly over engineered and ultimately just bloat. Like if I tried to do something with it, there would be 100 different unnecessary things going on in the background. I've been happily and successfully building javascript heavy apps for the client side which work very well and are quite functional without the need for a giant framework. I never feel this way about the server, on the server frameworks seem elegant. Why is it as soon as I move client side I'm overcome with the feeling it is over engineered? My theory is that none of these things are even necessary there.

ux-app 10y ago
Have you worked on projects with large teams? I'm guessing the benefits become more apparent then.
- Kequc 10y ago
  Hmm, not client side I haven't. Wouldn't it be easier to draft a set of design principles for the project? What I mean is if you really need a single page application, and usually you don't, that can be accomplished easily with turbolinks. If you really need to build DOM elements on the fly, that can be done really easily with raw JavaScript, which is fairly powerful on its own these days. I just don't see it.
  - qud 10y ago
    Completely agree (read this after posting my comment above). Having rules about structure & organisation rather than frameworks that would have their own rules seems much more pragmatic.
  - Shengbo 10y ago
    Give this article[1] a chance if you have the time. [1]: http://jlongster.com/Removing-User-Interface-Complexity,-or-Why-React-is-Awesome http://jlongster.com/Removing-User-Interface-Complexity,-or-...
  - ux-app 10y ago
    > Wouldn't it be easier to draft a set of design principles for the project? Isn't this what a framework gives you out of the box? Hiring should become easier if you can simply hire another Angular dev to join your large team. I'm assuming that your in-house design principles won't be as thoroughly battle tested as something like Angular or React is which has received tens of thousands if not millions of man hours of testing and refinement over the years. I'm not really advocating for or against, since I've never used a large framework like this in a team environment, but there must be benefits. Lots of smart people aren't using it because they are dummies that can't do better.
    - Kequc 10y ago
      puts on tinfoil hat I think the companies that are doing it are fighting over the space the same way operating systems do. Android, iOS, Windows. Potentially apps could start being developed for Angular and React and so on, in the future which are tied to licensing contracts for users. All the smaller frameworks are people trying out a few things, none of them corporate or free are really necessary.
  - JoelBennett 10y ago
    I suppose in a sense, it's easier to enforce policies through a library than it is to tell a dev "do this" or "don't do that'". I'm not a front-end developer either (so my JavaScript experience is a bit limited), but with the back-end code that I work on with my team, enforcing policies can be a bit tricky. It's pretty easy for things to slip through in a pull request that are against policy, and it's kind of hard to automatically check for policy violations. When forcing someone to use an API, at least you can somewhat guarantee that the API follows the policy.
olavgg 10y ago
I have the same experience. If it is already sluggish on a desktop browser, it has to be terrible on a phone.
qud 10y ago
Wow I never thought I'll see someone else with my same concern. I really hate using too much third-party code (to the point that I need a generator just to start), and I like knowing what each and every file in my project is for/does. I would really appreciate it if you'd share the application structure you use when building a client side MVC with vanilla JS/Jquery. I know there wouldn't be a single structure to rule them all, but I think if developers start sharing structures that work regardless of frameworks used, it would be much better than sharing frameworks that are very complex and get replaced every year.
- Kequc 10y ago
  I create a separate file for each concern, and I dump them into the same directory together. If the files list become significantly long I separate them into subfolders of more general concerns. For example a folder for everything to do with "recording" functionality. Views are very simple. There is generally a class instance which is using a DOM element somewhere. So I store a reference to that element on the instance. Then I have a simple object containing references to all of the important elements within it. I have a function which generates the element if it hasn't been created yet and adds it to the page. Now I can change whatever I want to about the element or any important elements within it. I use classes like "is-hidden." Sometimes I'll decouple the UI from it's functionality. In which case I usually implement a simple eventer system on the underlying code which the UI connects to for status updates. Bingo bango. I haven't run into a circumstance yet where any one file was longer than maybe 200-300 lines total. It's simple to read, it does anything I want. I have never needed to construct anything client side that warranted laying it out like a server implementation. But maybe that's my issue, I'm thinking too small and other people have a better idea of what the future of the web looks like than me. I still prefer having control.
DoubleGlazing 10y ago
I have to agree with this. There is just so much unnecessary stuff going on in modern webpages. All too often I see relatively simple webpages with jQuery/Angular/React/Bootstrap/Telerik and numerous other libraries references in the header. I started web development in the 90s where small size and high speed were key. I try to do the same now. I'll only use jQuery where possible, but if I do use a framework/library it will be to prototype something or to get something completed as I am under time constraints. If I get a chance I'll port it all over to plain JavaScript. Modern webpages are just too big.

by Kequc 10y ago

ux-app 10y ago

Have you worked on projects with large teams? I'm guessing the benefits become more apparent then.

Kequc 10y ago
Hmm, not client side I haven't. Wouldn't it be easier to draft a set of design principles for the project? What I mean is if you really need a single page application, and usually you don't, that can be accomplished easily with turbolinks. If you really need to build DOM elements on the fly, that can be done really easily with raw JavaScript, which is fairly powerful on its own these days. I just don't see it.
- qud 10y ago
  Completely agree (read this after posting my comment above). Having rules about structure & organisation rather than frameworks that would have their own rules seems much more pragmatic.
- Shengbo 10y ago
  Give this article[1] a chance if you have the time. [1]: http://jlongster.com/Removing-User-Interface-Complexity,-or-Why-React-is-Awesome http://jlongster.com/Removing-User-Interface-Complexity,-or-...
- ux-app 10y ago
  > Wouldn't it be easier to draft a set of design principles for the project? Isn't this what a framework gives you out of the box? Hiring should become easier if you can simply hire another Angular dev to join your large team. I'm assuming that your in-house design principles won't be as thoroughly battle tested as something like Angular or React is which has received tens of thousands if not millions of man hours of testing and refinement over the years. I'm not really advocating for or against, since I've never used a large framework like this in a team environment, but there must be benefits. Lots of smart people aren't using it because they are dummies that can't do better.
  - Kequc 10y ago
    puts on tinfoil hat I think the companies that are doing it are fighting over the space the same way operating systems do. Android, iOS, Windows. Potentially apps could start being developed for Angular and React and so on, in the future which are tied to licensing contracts for users. All the smaller frameworks are people trying out a few things, none of them corporate or free are really necessary.
- JoelBennett 10y ago
  I suppose in a sense, it's easier to enforce policies through a library than it is to tell a dev "do this" or "don't do that'". I'm not a front-end developer either (so my JavaScript experience is a bit limited), but with the back-end code that I work on with my team, enforcing policies can be a bit tricky. It's pretty easy for things to slip through in a pull request that are against policy, and it's kind of hard to automatically check for policy violations. When forcing someone to use an API, at least you can somewhat guarantee that the API follows the policy.

olavgg 10y ago

I have the same experience. If it is already sluggish on a desktop browser, it has to be terrible on a phone.

qud 10y ago

Wow I never thought I'll see someone else with my same concern. I really hate using too much third-party code (to the point that I need a generator just to start), and I like knowing what each and every file in my project is for/does. I would really appreciate it if you'd share the application structure you use when building a client side MVC with vanilla JS/Jquery. I know there wouldn't be a single structure to rule them all, but I think if developers start sharing structures that work regardless of frameworks used, it would be much better than sharing frameworks that are very complex and get replaced every year.

Kequc 10y ago
I create a separate file for each concern, and I dump them into the same directory together. If the files list become significantly long I separate them into subfolders of more general concerns. For example a folder for everything to do with "recording" functionality. Views are very simple. There is generally a class instance which is using a DOM element somewhere. So I store a reference to that element on the instance. Then I have a simple object containing references to all of the important elements within it. I have a function which generates the element if it hasn't been created yet and adds it to the page. Now I can change whatever I want to about the element or any important elements within it. I use classes like "is-hidden." Sometimes I'll decouple the UI from it's functionality. In which case I usually implement a simple eventer system on the underlying code which the UI connects to for status updates. Bingo bango. I haven't run into a circumstance yet where any one file was longer than maybe 200-300 lines total. It's simple to read, it does anything I want. I have never needed to construct anything client side that warranted laying it out like a server implementation. But maybe that's my issue, I'm thinking too small and other people have a better idea of what the future of the web looks like than me. I still prefer having control.

DoubleGlazing 10y ago

I have to agree with this. There is just so much unnecessary stuff going on in modern webpages. All too often I see relatively simple webpages with jQuery/Angular/React/Bootstrap/Telerik and numerous other libraries references in the header. I started web development in the 90s where small size and high speed were key. I try to do the same now. I'll only use jQuery where possible, but if I do use a framework/library it will be to prototype something or to get something completed as I am under time constraints. If I get a chance I'll port it all over to plain JavaScript. Modern webpages are just too big.