4 ms·

You don't need one, but if you don't eventually adopt one, you'll end up writing one.

takno 11y ago
Sure, you may well end up writing one, but it's likely to be a fraction of the size. My current entire app is running at half the size of jquery, which is getting me awesomely quick page loads even on poor mobile connections. The dev time was longer, but not crazily longer, and the surface area for testing is somewhat smaller
- Touche 11y ago
  In reality JavaScript size means very little when a single image might be 500k.
  - Svenskunganka 11y ago
    Unfortunately I have to disagree. The JavaScript Engine still have to parse and interpret the code. This can take a bit of time, especially on mobile devices.
    - openasocket 11y ago
      Parse time shouldn't be very long at all, especially compared to network latency. How long does it take for large (~100-150kb minified) to be parsed and interpreted? I'd be surprised if it's more than 100ms
      - Walkman 11y ago
        100ms is noticeable. It's already slow if you reach that.
        WalterSear 11y ago
        It's barely above the threshold for detectable live feedback latency, from a musical instrument or sight/sound correlation. As a user veiwing a page with plenty of other latency, it's inconsequential, particularly since you can execute your js while image assets are still incoming.
    - deleted 11y ago
      [deleted]
  - tomc1985 11y ago
    Did you not see that headline about how the average page now is the size of a Doom install?
    - TheCoelacanth 11y ago
      Mainly because an average page has much higher resolution graphics than Doom.
      - tomc1985 11y ago
        Six years ago I was regularly mining merchant pages containing 1mb+ of HTML. Nowadays that seems to be par for course.
  - coldtea 11y ago
    Maybe, but in terms of understanding the code and having total control over it, it means a lot. (And I don't buy the large teams can't adopt a self-grown code in the first place. If they're any good, they can. If they're not, then even their React and Angular skills will be bad). Besides you know all your business logic code? That will be custom too, anyway,and they'll have to adopt it...
  - takno 11y ago
    My total image payload is 30k. Obviously getting there is more challenging for other sites, but at the end of the day if your page is >1mb I'm probably not going to wait for it to load
    - coldtea 11y ago
      >but at the end of the day if your page is >1mb I'm probably not going to wait for it to load Average size for the most popular sites has actually grown to ~ 2.5-3MB. And since they're the most popular, it shows that people DO wait just fine for them to load.
      - elmigranto 11y ago
        Switch "most popular" to "your site" and it will probably change user's desire to wait for it.
        coldtea 11y ago
        Yeah, that's true. Also what I left out in my argument is that while popular already, they still might get increased in traffic if they were lighter.
        elmigranto 11y ago
        What's more relevant at Facebook's scale is dollars saved per kilobyte shrinked. Because majority of its users will tolerate almost anything at this point, including apps that crash randomly to measure loyalty.
  - netghost 11y ago
    It's not so much the time over the wire to download, but the time to parse and run all that JS. If you open up your web dev tools, I think you'll see the impact from a 50k gzipped JS file is probably greater than a 500k image, for one thing the site can probably function without the image loaded, but your page will not be user responsive until that JS has finished executing.
  - danieltillett 11y ago
    You shouldn't be serving 500k images to mobile users.
  - rimantas 11y ago
    Then you are doing images wrong.
- s0uthPaw88 11y ago
  Can you post a link to your app? Would love to see an example of a frameworkless web app.
- threatofrain 11y ago
  There are cases where some companies have the business justification to work on writing their own frameworks, like with Facebook. They can use up human resources to really focus on latency at the cost of other metrics. Other companies juggle their priorities differently, and would probably not want to focus their efforts on replacing React, which has a small API, constantly-updated documentation, a team that responds to issues, and widespread attention and thus lots of discourse. I also think the React layer abstracts away complexity, trading total lines of code for cognitive easiness. Some teams have the business justification for doing things their way -- but I think most don't.
- elmigranto 11y ago
  I'm not sure how the size of your app can possibly say anything about applicability or quality of jQuery.
CloudYeller 11y ago
Yep. If you're getting paid to maintain even 10-20 UI's, frameworks help preserve your sanity. At least you'll know what to expect from the boilerplate and what are the general capabilities of dozens of apps, just by learning 1 framework. And the more popular the framework, the easier it is to hire new developers to work on your apps.
tomc1985 11y ago
I guess that's why we have so many! bah dum bum chh
formula_ninguna 11y ago
That's funny. But at least you might not need the whole framework, just a part of it. And that part you'll end up writing youself. Why not? You'll understand javascript better. Most developers aren't able to write a single line without a framework.
Silhouette 11y ago
So people keep telling me, but I've been building this stuff for a couple of decades now, including maintaining certain projects for at least as long as most of the modern JS frameworks have existed, and I'm still waiting. The only way these generalisations about everything becoming a framework hold is if you conveniently define framework to mean something like "having any sort of systematic or uniform software architecture".

takno 11y ago

Sure, you may well end up writing one, but it's likely to be a fraction of the size. My current entire app is running at half the size of jquery, which is getting me awesomely quick page loads even on poor mobile connections. The dev time was longer, but not crazily longer, and the surface area for testing is somewhat smaller

Touche 11y ago
In reality JavaScript size means very little when a single image might be 500k.
- Svenskunganka 11y ago
  Unfortunately I have to disagree. The JavaScript Engine still have to parse and interpret the code. This can take a bit of time, especially on mobile devices.
  - openasocket 11y ago
    Parse time shouldn't be very long at all, especially compared to network latency. How long does it take for large (~100-150kb minified) to be parsed and interpreted? I'd be surprised if it's more than 100ms
    - Walkman 11y ago
      100ms is noticeable. It's already slow if you reach that.
      - WalterSear 11y ago
        It's barely above the threshold for detectable live feedback latency, from a musical instrument or sight/sound correlation. As a user veiwing a page with plenty of other latency, it's inconsequential, particularly since you can execute your js while image assets are still incoming.
  - deleted 11y ago
    [deleted]
- tomc1985 11y ago
  Did you not see that headline about how the average page now is the size of a Doom install?
  - TheCoelacanth 11y ago
    Mainly because an average page has much higher resolution graphics than Doom.
    - tomc1985 11y ago
      Six years ago I was regularly mining merchant pages containing 1mb+ of HTML. Nowadays that seems to be par for course.
- coldtea 11y ago
  Maybe, but in terms of understanding the code and having total control over it, it means a lot. (And I don't buy the large teams can't adopt a self-grown code in the first place. If they're any good, they can. If they're not, then even their React and Angular skills will be bad). Besides you know all your business logic code? That will be custom too, anyway,and they'll have to adopt it...
- takno 11y ago
  My total image payload is 30k. Obviously getting there is more challenging for other sites, but at the end of the day if your page is >1mb I'm probably not going to wait for it to load
  - coldtea 11y ago
    >but at the end of the day if your page is >1mb I'm probably not going to wait for it to load Average size for the most popular sites has actually grown to ~ 2.5-3MB. And since they're the most popular, it shows that people DO wait just fine for them to load.
    - elmigranto 11y ago
      Switch "most popular" to "your site" and it will probably change user's desire to wait for it.
      - coldtea 11y ago
        Yeah, that's true. Also what I left out in my argument is that while popular already, they still might get increased in traffic if they were lighter.
        elmigranto 11y ago
        What's more relevant at Facebook's scale is dollars saved per kilobyte shrinked. Because majority of its users will tolerate almost anything at this point, including apps that crash randomly to measure loyalty.
- netghost 11y ago
  It's not so much the time over the wire to download, but the time to parse and run all that JS. If you open up your web dev tools, I think you'll see the impact from a 50k gzipped JS file is probably greater than a 500k image, for one thing the site can probably function without the image loaded, but your page will not be user responsive until that JS has finished executing.
- danieltillett 11y ago
  You shouldn't be serving 500k images to mobile users.
- rimantas 11y ago
  Then you are doing images wrong.
s0uthPaw88 11y ago
Can you post a link to your app? Would love to see an example of a frameworkless web app.
threatofrain 11y ago
There are cases where some companies have the business justification to work on writing their own frameworks, like with Facebook. They can use up human resources to really focus on latency at the cost of other metrics. Other companies juggle their priorities differently, and would probably not want to focus their efforts on replacing React, which has a small API, constantly-updated documentation, a team that responds to issues, and widespread attention and thus lots of discourse. I also think the React layer abstracts away complexity, trading total lines of code for cognitive easiness. Some teams have the business justification for doing things their way -- but I think most don't.
elmigranto 11y ago
I'm not sure how the size of your app can possibly say anything about applicability or quality of jQuery.

CloudYeller 11y ago

Yep. If you're getting paid to maintain even 10-20 UI's, frameworks help preserve your sanity. At least you'll know what to expect from the boilerplate and what are the general capabilities of dozens of apps, just by learning 1 framework. And the more popular the framework, the easier it is to hire new developers to work on your apps.

tomc1985 11y ago

I guess that's why we have so many! bah dum bum chh

formula_ninguna 11y ago

That's funny. But at least you might not need the whole framework, just a part of it. And that part you'll end up writing youself. Why not? You'll understand javascript better. Most developers aren't able to write a single line without a framework.

Silhouette 11y ago

So people keep telling me, but I've been building this stuff for a couple of decades now, including maintaining certain projects for at least as long as most of the modern JS frameworks have existed, and I'm still waiting. The only way these generalisations about everything becoming a framework hold is if you conveniently define framework to mean something like "having any sort of systematic or uniform software architecture".