6 ms·

These types of posts are popping up more and more these days. I like to call them "JavaScript luddite" posts: posts that worship single-digit kb apps with zero

These types of posts are popping up more and more these days. I like to call them "JavaScript luddite" posts: posts that worship single-digit kb apps with zero dependencies as universally good ideas. This type of thinking is going to hold back frontend web development as a whole unless we address it. Disclaimer: I am on the React team. "API first" -- just layer your API on top of whatever you're using to implement it. Abstraction is an important part of what we do as SW engineers. This post describes a particularly leaky abstraction, which is easily fixed. "Small size" -- cry me a river. Yes, byte size is important but it's not more important than code reuse and all the benefits that come with it (security, dev speed, support etc). By the way, the Retina image on the blog post was 46kb over the wire which is bigger than all the JS in his app. The lesson to be learned here is that if add a single image you've pretty much blown away any JS savings you would have had. Another thing: usually multiple server round-trips matter more than bytes down the wire. "Full control" -- this is a legit reason. Some of the bullet points are indicative of the state of client-side JS tooling though which are fixable. "Special needs" -- moot's engineering challenges were not unique, they just didn't like the trendy frameworks. This is totally OK, but not a good reason to tell everyone that code reuse is bad. "Technology lock-in" -- somewhat of a legit reason, but more of a commentary on monolithic architectures than anything else.

twerquie 13y ago
Comparing images and javascript in terms of payload size is apples and oranges. Images do not block the rendering of a page, are trivial to decode and display, and do not have long execution paths for the duration of their life.
- tomkin 13y ago
  If your argument is "byte size", images matter. There's no getting away from that. This Marco Polo, Columbus-esc view of "rediscovering the basics" is on ego, not efficiency. You're not discovering new territory by rebuilding the wheel, passing it off as "efficiency". Bandwidth costs would be the only point I could possibly side with - but as mentioned, you add a JPG or any resource for that matter, and the benefits are gone. If you are going to go about the busy work of rebuilding the wheel, ask yourself, is there a single user's life you are improving? If you have sacrificed the user experience at all - to save 10kb - then you've disserviced them, while patting yourself on the back needlessly. 10k barely changed my experience on a 14.4-33.6kb modem, so I am unsure of how to make the argument today.
  - twerquie 13y ago
    I think you completely missed my point. "Byte size" in javascript is an analogue for slow app execution (page rendering and code paths), not slow downloading or bandwidth costs. Also, I'm not suggesting we "re-invent the wheel" or code everything from scratch. I'm an advocate for composing your app from small modules. Modern js is incredibly good at this.
bchjam 13y ago
I recently built a little library for generating slopegraphs in SVG. I could have used d3 and maybe saved a little bit of code but for something straight forward and purposeful like this I think the no dependencies thing works well. I have also worked on projects that tried to build a framework for everything on their own. Good learning experience but not the best for code stability or predictable dev cycles.
kllrnohj 13y ago
> "Small size" -- cry me a river. Yes, byte size is important but it's not more important than code reuse and all the benefits that come with it I would disagree with this within reason. Code reuse affects YOU the developer. Byte size, however, affects your USERS. Things that impact your users are far more important than things that affect your development zen. Obviously the two are not entirely independent and a balance must be reached, but the user is the important person here, not the developer.
- bad_user 13y ago
  Code reuse or the lack thereof also affects the users, because there is more potential for bugs. Reinventing the wheel may be warranted, the end result may actually be more stable depending on who works on that wheel reinvention, but lets not kid ourselves - every line of code written increases the potential for bugs and there's nothing that affects the user experience more than a broken app. Besides, bytes count is important, but it's only a problem because people aren't using tree-shaking optimizers, like Google Closure. E.g. when importing a library like JQuery, you're paying for a lot of crap in it that you don't need. A smart tree-shaker is able to detect unused branches and eliminate everything you don't use. And it's a solvable problem. Google Closure in "advanced" optimizations mode is amazing. Unfortunately the popular libraries are not written for Closure's advanced optimizations and thus are incompatible. This is where compilers can help us. ClojureScript for example compiles to Google Closure optimized Javascript. There's also a fork of an older version of TypeScript that does the same thing. Google's Dart does tree shaking too. Maybe we'll also see EcmaScript 6 compilers that will do it too. We don't need to sacrifice code reuse because of bytes count. I mean, sure, if you don't find a library that matches your architectural needs, wheel reinvention is fine. But optimizing for bytes count is a stupid reason to do it and we only feel the need for it because our tool-chains are primitive.
  - peterhunt 13y ago
    +1 We ensure that React is advanced mode compatible and people routinely get pissed at me because I'm a stickler for bytes. But that's because React is a shared core library where it's our job to be small and fast. When you're building an app, the trade-offs and priorities are different.
coldtea 13y ago
>These types of posts are popping up more and more these days. I like to call them "JavaScript luddite" posts: posts that worship single-digit kb apps with zero dependencies as universally good ideas. So something like "the UNIX way". And that's wrong because? >Abstraction is an important part of what we do as SW engineers. Which is why we should be able to handle it and craft it properly, and not outsource it to some ready-made one-size-fits-all framework. There are other outlets for code reuse, and they are called libraries. >"Small size" -- cry me a river. Yes, byte size is important but it's not more important than code reuse and all the benefits that come with it (security, dev speed, support etc). Code reuse? Ever heard of libraries? In fact adopting a framework makes pretty sure that it will be hard to reuse both best-of-breed third party libraries (because frameworks favor their built-in stuff) and it also makes it pretty sure that your code will not be reusable outside of it, e.g when you move to a better framework. E.g. all those Ember objects will be tied to Embder, and the logic will be tied to Ember logic of doing things. >By the way, the Retina image on the blog post was 46kb over the wire which is bigger than all the JS in his app. Beside the point, for one his app is not his blog, and second, a one-page style app can function while some image is loading, but not while the main JS files are. >"Special needs" -- moot's engineering challenges were not unique, they just didn't like the trendy frameworks. Moots might not have been, but your startups better be, else you're doing commodity work churning out stuff. In which case, yes, use a framework.
gambler 13y ago
"Small size" -- cry me a river. Yes, byte size is important but it's not more important than code reuse and all the benefits that come with it Code reuse and security depend on developer's skill. You can have both in a home-brew microframework or have neither while using something more popular. Code size, on the other hand, is something you cannot get rid of, once you commit to a certain solution. By the way, the Retina image on the blog post was 46kb over the wire which is bigger than all the JS in his app. This wouldn't be true if he had more JavaScript in his app. The argument doesn't make any sense. I sense zero respect for people on slow internet connections from you. Yes, it is a real problem. Yes, modern framework-rich development makes the problem worse.
ddebernardy 13y ago
You hould get your hands on a 1st-gen iPad and browse using only that for a few weeks, to get a feel of how clunky js frameworks slow the web down.
sreyaNotfilc 13y ago
"By the way, the Retina image on the blog post was 46kb over the wire which is bigger than all the JS in his app." Boom Baby! Sorry, I just love how you picked up on that. Yeah, lets complain about size of our code, but hey look at my pretty high-res image! "The lady doth protest too much, me thinks". Anyway, at the end of the day its about creating an experience that gets the job done (and ultimately get more $$$ in your pocket). Many of the problems I see (here and in the office) are debates on which framework is the best for this and that. Though those are good debates to have, one shouldn't sacrifice the end goal for the "proper" software solution. Jobs said it best here... http://www.youtube.com/watch?v=FF-tKLISfPE http://www.youtube.com/watch?v=FF-tKLISfPE

twerquie 13y ago

Comparing images and javascript in terms of payload size is apples and oranges. Images do not block the rendering of a page, are trivial to decode and display, and do not have long execution paths for the duration of their life.

tomkin 13y ago
If your argument is "byte size", images matter. There's no getting away from that. This Marco Polo, Columbus-esc view of "rediscovering the basics" is on ego, not efficiency. You're not discovering new territory by rebuilding the wheel, passing it off as "efficiency". Bandwidth costs would be the only point I could possibly side with - but as mentioned, you add a JPG or any resource for that matter, and the benefits are gone. If you are going to go about the busy work of rebuilding the wheel, ask yourself, is there a single user's life you are improving? If you have sacrificed the user experience at all - to save 10kb - then you've disserviced them, while patting yourself on the back needlessly. 10k barely changed my experience on a 14.4-33.6kb modem, so I am unsure of how to make the argument today.
- twerquie 13y ago
  I think you completely missed my point. "Byte size" in javascript is an analogue for slow app execution (page rendering and code paths), not slow downloading or bandwidth costs. Also, I'm not suggesting we "re-invent the wheel" or code everything from scratch. I'm an advocate for composing your app from small modules. Modern js is incredibly good at this.

bchjam 13y ago

I recently built a little library for generating slopegraphs in SVG. I could have used d3 and maybe saved a little bit of code but for something straight forward and purposeful like this I think the no dependencies thing works well. I have also worked on projects that tried to build a framework for everything on their own. Good learning experience but not the best for code stability or predictable dev cycles.

kllrnohj 13y ago

> "Small size" -- cry me a river. Yes, byte size is important but it's not more important than code reuse and all the benefits that come with it I would disagree with this within reason. Code reuse affects YOU the developer. Byte size, however, affects your USERS. Things that impact your users are far more important than things that affect your development zen. Obviously the two are not entirely independent and a balance must be reached, but the user is the important person here, not the developer.

bad_user 13y ago
Code reuse or the lack thereof also affects the users, because there is more potential for bugs. Reinventing the wheel may be warranted, the end result may actually be more stable depending on who works on that wheel reinvention, but lets not kid ourselves - every line of code written increases the potential for bugs and there's nothing that affects the user experience more than a broken app. Besides, bytes count is important, but it's only a problem because people aren't using tree-shaking optimizers, like Google Closure. E.g. when importing a library like JQuery, you're paying for a lot of crap in it that you don't need. A smart tree-shaker is able to detect unused branches and eliminate everything you don't use. And it's a solvable problem. Google Closure in "advanced" optimizations mode is amazing. Unfortunately the popular libraries are not written for Closure's advanced optimizations and thus are incompatible. This is where compilers can help us. ClojureScript for example compiles to Google Closure optimized Javascript. There's also a fork of an older version of TypeScript that does the same thing. Google's Dart does tree shaking too. Maybe we'll also see EcmaScript 6 compilers that will do it too. We don't need to sacrifice code reuse because of bytes count. I mean, sure, if you don't find a library that matches your architectural needs, wheel reinvention is fine. But optimizing for bytes count is a stupid reason to do it and we only feel the need for it because our tool-chains are primitive.
- peterhunt 13y ago
  +1 We ensure that React is advanced mode compatible and people routinely get pissed at me because I'm a stickler for bytes. But that's because React is a shared core library where it's our job to be small and fast. When you're building an app, the trade-offs and priorities are different.

coldtea 13y ago

>These types of posts are popping up more and more these days. I like to call them "JavaScript luddite" posts: posts that worship single-digit kb apps with zero dependencies as universally good ideas. So something like "the UNIX way". And that's wrong because? >Abstraction is an important part of what we do as SW engineers. Which is why we should be able to handle it and craft it properly, and not outsource it to some ready-made one-size-fits-all framework. There are other outlets for code reuse, and they are called libraries. >"Small size" -- cry me a river. Yes, byte size is important but it's not more important than code reuse and all the benefits that come with it (security, dev speed, support etc). Code reuse? Ever heard of libraries? In fact adopting a framework makes pretty sure that it will be hard to reuse both best-of-breed third party libraries (because frameworks favor their built-in stuff) and it also makes it pretty sure that your code will not be reusable outside of it, e.g when you move to a better framework. E.g. all those Ember objects will be tied to Embder, and the logic will be tied to Ember logic of doing things. >By the way, the Retina image on the blog post was 46kb over the wire which is bigger than all the JS in his app. Beside the point, for one his app is not his blog, and second, a one-page style app can function while some image is loading, but not while the main JS files are. >"Special needs" -- moot's engineering challenges were not unique, they just didn't like the trendy frameworks. Moots might not have been, but your startups better be, else you're doing commodity work churning out stuff. In which case, yes, use a framework.

gambler 13y ago

"Small size" -- cry me a river. Yes, byte size is important but it's not more important than code reuse and all the benefits that come with it Code reuse and security depend on developer's skill. You can have both in a home-brew microframework or have neither while using something more popular. Code size, on the other hand, is something you cannot get rid of, once you commit to a certain solution. By the way, the Retina image on the blog post was 46kb over the wire which is bigger than all the JS in his app. This wouldn't be true if he had more JavaScript in his app. The argument doesn't make any sense. I sense zero respect for people on slow internet connections from you. Yes, it is a real problem. Yes, modern framework-rich development makes the problem worse.

ddebernardy 13y ago

You hould get your hands on a 1st-gen iPad and browse using only that for a few weeks, to get a feel of how clunky js frameworks slow the web down.

sreyaNotfilc 13y ago

"By the way, the Retina image on the blog post was 46kb over the wire which is bigger than all the JS in his app." Boom Baby! Sorry, I just love how you picked up on that. Yeah, lets complain about size of our code, but hey look at my pretty high-res image! "The lady doth protest too much, me thinks". Anyway, at the end of the day its about creating an experience that gets the job done (and ultimately get more $$$ in your pocket). Many of the problems I see (here and in the office) are debates on which framework is the best for this and that. Though those are good debates to have, one shouldn't sacrifice the end goal for the "proper" software solution. Jobs said it best here... http://www.youtube.com/watch?v=FF-tKLISfPE http://www.youtube.com/watch?v=FF-tKLISfPE