3 ms·

Even if you wanna be cynical, this is a really boring and overplayed take in my opinion. Most frameworks are indeed kind of bloated for running useless hello wo

by jchw 4y ago

Even if you wanna be cynical, this is a really boring and overplayed take in my opinion. Most frameworks are indeed kind of bloated for running useless hello world demos. Most C compilers give you some kilobytes of code that isn’t necessary for hello world either, even worse for other respected and modern languages like Rust and Go. It can be forgiven if you consider that most of these things are not tuned for optimal hello world.

jonobird1 4y ago
This comment is the overplayed take that because a lot are heavy frameworks, that this should be acceptable. As soon as something is classified as a framework, it seems ok to be >200kb. If you take Tailwind CSS for example, when correctly using their CLI tool, it only includes the size of the css classes actually used, keeping it to a minimum, when compared to people just doing a standard import of the entire library. I like this mentality because it's offering the ability to be very lightweight, or as large as the 'framework' it offers. NextJS offers this as part of their build process, but not sure how big their assets are with it for a simple usecase.
- jchw 4y ago
  The word framework doesn't really actually mean anything. People have a feel for it, but there is no concrete "this is a framework, not a library." However, I think that for most people, the criteria isn't actually related to how large the software is, but rather the feeling of using it. When you use a non-framework library, it feels like using a wrench or a drill; it's a tool. When you use a framework, it feels like you're writing code inside it, not using it. Frameworks can be small. The term "microframework" exists for this exact reason. Semantics aside, the existence of things with different philosophies doesn't immediately invalidate everything that doesn't give you the same tradeoffs. For one thing, Tailwind deals with declarative CSS output, not imperative modular code. I'm not saying that makes it stupid or anything, but it's very apples and oranges. There are very few JS libraries or frameworks that can offer starting-from-zero KiB JS; maybe Svelte comes close? Ironically, if we're talking about client side bundles, it seems as though Fresh actually does start with 0 KiB, as it does not default to shipping JS code to the client at all. This doesn't feel like a rational discussion at all. It feels like it's just necessary to come up with a cynical take because there's a new JavaScript thing. In a few weeks there could be some Rust FRP webassembly UI thing that has a 1.2 MiB hello world and hardly anyone will care.
deleted 4y ago
[deleted]
imiric 4y ago
Is this satire? I honestly can't tell, but it made me laugh. If not, why in the world would a hello-world demo need optimization? By definition it's supposed to be the simplest thing you can build to showcase the features of what you're using. If the simplest project has the properties GP mentions, then it's not a good demo.
- jchw 4y ago
  - imiric 4y ago
    The difference is that it doesn't take 600ms for a Rust binary to render "Hello world!" to stdout. In the context of CLI apps, binary size is irrelevant to the functionality of the demo. In the context of web apps, bundle size and speed _does_ matter, so 108KiB and 600ms are very relevant data points. Besides, I'm pretty sure that in this framework's case the final bundle can also be trivially stripped, but would that also reduce the render time? It's difficult to tell, and maybe those things should be mentioned in the demo. (Sidenote: I haven't confirmed whether what 0des posted is true or not; I'm just going by the fact that you're defending it.)
    - jchw 4y ago
      I know this comparison isn’t exact, but I didn’t attempt to engage with the supposed latency measure. That kind of measurements are really variable and hard to pin down. You’d need percentiles to make even an uneducated judgement, not a single random sample. Still… a 100KiB bundle is not that bad of a starting point. It objectively isn’t, if you measure it up to other popular frameworks.

by jchw 4y ago

jonobird1 4y ago

This comment is the overplayed take that because a lot are heavy frameworks, that this should be acceptable. As soon as something is classified as a framework, it seems ok to be >200kb. If you take Tailwind CSS for example, when correctly using their CLI tool, it only includes the size of the css classes actually used, keeping it to a minimum, when compared to people just doing a standard import of the entire library. I like this mentality because it's offering the ability to be very lightweight, or as large as the 'framework' it offers. NextJS offers this as part of their build process, but not sure how big their assets are with it for a simple usecase.

jchw 4y ago
The word framework doesn't really actually mean anything. People have a feel for it, but there is no concrete "this is a framework, not a library." However, I think that for most people, the criteria isn't actually related to how large the software is, but rather the feeling of using it. When you use a non-framework library, it feels like using a wrench or a drill; it's a tool. When you use a framework, it feels like you're writing code inside it, not using it. Frameworks can be small. The term "microframework" exists for this exact reason. Semantics aside, the existence of things with different philosophies doesn't immediately invalidate everything that doesn't give you the same tradeoffs. For one thing, Tailwind deals with declarative CSS output, not imperative modular code. I'm not saying that makes it stupid or anything, but it's very apples and oranges. There are very few JS libraries or frameworks that can offer starting-from-zero KiB JS; maybe Svelte comes close? Ironically, if we're talking about client side bundles, it seems as though Fresh actually does start with 0 KiB, as it does not default to shipping JS code to the client at all. This doesn't feel like a rational discussion at all. It feels like it's just necessary to come up with a cynical take because there's a new JavaScript thing. In a few weeks there could be some Rust FRP webassembly UI thing that has a 1.2 MiB hello world and hardly anyone will care.

deleted 4y ago

[deleted]

imiric 4y ago

Is this satire? I honestly can't tell, but it made me laugh. If not, why in the world would a hello-world demo need optimization? By definition it's supposed to be the simplest thing you can build to showcase the features of what you're using. If the simplest project has the properties GP mentions, then it's not a good demo.

jchw 4y ago
- imiric 4y ago
  The difference is that it doesn't take 600ms for a Rust binary to render "Hello world!" to stdout. In the context of CLI apps, binary size is irrelevant to the functionality of the demo. In the context of web apps, bundle size and speed _does_ matter, so 108KiB and 600ms are very relevant data points. Besides, I'm pretty sure that in this framework's case the final bundle can also be trivially stripped, but would that also reduce the render time? It's difficult to tell, and maybe those things should be mentioned in the demo. (Sidenote: I haven't confirmed whether what 0des posted is true or not; I'm just going by the fact that you're defending it.)
  - jchw 4y ago
    I know this comparison isn’t exact, but I didn’t attempt to engage with the supposed latency measure. That kind of measurements are really variable and hard to pin down. You’d need percentiles to make even an uneducated judgement, not a single random sample. Still… a 100KiB bundle is not that bad of a starting point. It objectively isn’t, if you measure it up to other popular frameworks.