Hacker News Reader

Comment by vfc1 | Hacker News Reader

I think the whole comparison of imgur with a blank page with an image is a bit silly. It's not just the image, its a whole application with comments,image galeries, video playing ability, and of course a ton of iframes with ads which load a lot of content (more images etc.)

Try to do the same feature set without a Javascript framework and using only plain Javascript or even plain HTML and CSS, and then come and tell us about the results.

Also, a lot of the bloat is probably not under the developers control and is added by non technical marketing departments, which want a tracking pixel for this, a tracking pixel for that etc.

But yes its true its insane and its getting worse, and 4G and HTTP2 will not be a solution for most of us anytime soon.

View on HN

I don't think it's unfair, when 99% of users don't want any of those features. By that logic, any and every possible feature is fair game, and beyond criticism, simply by existing.

But I don't care about any of that. I don't even care if the rest of the app is what keeps the lights on. Everyone* who visits imgur does so following an image link, they want to view that single image, and will not click anywhere else on the page. Optimizing for another use case seems crazy.

*There is set of users who browse imgur or otherwise use imgur as a kind of "web application", I'm disregarding that part of their userbase for the sake of this discussion. It would surprise me a lot to learn they are more than 1% of users .

> But I don't care about any of that

OK, fair enough but then it's a different discussion and a different conclusion.

We can't really blame Javascript frameworks for a particular business that has decided to monetize its user base in a different way, by adding more features that are not widely used by their userbase.

Imgur can't exist in a vacuum, it's a business there is a whole team behind it.

Now we might question that whole business model as well and the whole internet supported by ads thing, but that is a whole different barrel of fish that is in my view not attributable to Javascript frameworks.

> I think the whole comparison of imgur with a blank page with an image is a bit silly. It's not just the image, its a whole application with comments,image galeries, video playing ability, and of course a ton of iframes with ads which load a lot of content (more images etc.)

This is precisely the reason it's a good comparison...

It is not difficult to implement all those features using plain Javascript, in fact I would recommend it as a great learning experience. What is difficult is doing it in way that is maintainable over a long period of time.

The nature of the language is that without iron code discipline Javascript code inevitably turns into a mud-ball.

Apart from the obvious “many-eyes” benefits, frameworks also provide structure that buys extra time before this happens.

> The nature of the language is that without iron code discipline Javascript code inevitably turns into a mud-ball.

Could you outline what you think makes JS more likely to turn into mud-balls compared to other languages?

In my experience, no matter what language you use, or with what pardigm, unless you model and design your software architecture with discipline, you gonna end up with a mud-ball.

Has less to do with the language and more about the process you use to model your domain.

> Could you outline what you think makes JS more likely to turn into mud-balls compared to other languages?

Plain JS is hell to refactor. Between arbitrary autocasting, little tooling and no useful type system, if you don't have a very detailed test suite, you won't find the parts of your code that are broken now. Also, if you do, you now have to reimplement all those tests that did nothing else than to check your call signatures.

Ease of refactoring is a major indicator for a good enterprise language, as constant refactoring is basically the main development process. If your devs are afraid to touch certain pieces of code because nobody knows what the ramifications are, your software is already dying.

That's why TypeScript is taking off so nicely. People crave those static guarantees that JS doesn't have.

When you have reached the stage of mud-ball it is already too late. ;)

With the appropriate amount of skill and discipline, however, this stage can be postponed for longer than the life of the application. Typescript is absolutely not required.

But that's a truism. Good coders write good code. Heureka!

The real gain is to be had in pushing the mudball stage as far into the product's life cycle in absolute terms as possible.

In that sense, nothing is required, but some things help. I argue that TypeScript helps.

If it helps you, great. I’m happy enough with plain JS, thanks. ;)

I've seen exactly the same problems with large TypeScript codebases as the JavaScript codebases have. Refactoring becomes a hassle not because there is types or not, but because there are endless of useless unit tests testing implementation details, because the architecture is highly coupled in the wrong places and because little care was made when the architecture was dynamically created (because "agile" or what ever) without considerations.

Having good and smarter tests helps more for ease of refactoring than having everything mapped to types. But I might just have seen bad examples of TypeScript codebases.

Probably this is a side-effect of translating JS unit-testing techniques without adequate thought and reflection. I am sometimes amazed at the extent of trivial tests that do no more than double-check the compiler that I see from web developers that move up the stack.

When I talk about shitty unit tests, I mean regardless of language (bad unit tests seems as prevalent in JavaScript, as TypeScript, as Ruby, as Python, Rust, Go and the list goes on)

It probably does apply to all languages, but I prefer to speak from experience, which in my case is mostly JS. Architecture and the related abstraction is definitely the hardest thing about programming in my experience, and what really separates good programmers from the bad.

Loose types, pass by reference, near-limitless mutability, scoping rules (without “use strict” to save the day) and asynchronous nature of the things it is used for are some of the things that come to mind with JS.

All of these are actually very powerful features that make it into the language I love, but care is definitely needed. ;)

Yeah, I really wouldn’t link it in any way to the language. It’s just mostly more obvious when it’s in JavaScript, because that’s associated with the user agent having to fetch the code and run it from scratch every time, and as a user you can more easily inspect where the time is going, compared with an app or backend processes, which are both much more opaque to the user.

It’s more about architecture and discipline, and far, far more about simply caring about performance. (And larger teams make it much harder to care about performance.)

For personal background in my firm agreement with capableweb, I work primarily in JavaScript professionally, tend to use Rust privately, and have used a variety of other languages and worked with both good and bad code bases (mostly good); and I care very much about performance.

Don’t get me wrong, I actually love Javascript. I have written code in quite a few languages but JS is the one I am most productive and happy in by far (within the area of network services and web apps that I work in). It has also been very profitable. :)

But the language has such a low threshold that it allows for incredible productivity while writing shitty code. But by the time you realise just what you have done (or someone else realised when they have to work on your codebase) its too late and it’s time for a rewrite.

What makes JS special is how accessible it is and just how much mess you can make before reality bites. That said, I will take a Javascript mud-ball over an enterprise Java one any time! ;)

> Loose types, pass by reference, near-limitless mutability

This sounds like almost every programming language which is not a functional one actually (it even fits C!).

It is true that C is capable of those thing by virtue of being capable of everything, including writing a functional Javascript engine. But you have a choice. You can have strict typing in C, you can pass structs by value and most C programs work in a synchronous manner. (I actually mentored a good C programmer to teach him JS for working on our team and asynchronous code was the thing he had most difficulty wrapping his brain around.)

With Javascript you cannot have strict types and you cannot pass objects by value and asynchronous programming is the norm.

C is also a lot less forgiving so it takes more skill to even be able to create a mud-ball of a reasonable size. ;)

In my limited experience, functional programming languages just move a significant amount of difficulty up-front to the code. Perhaps it makes for less difficulty in architecture - I never suck around for long enough to find out. The difficulty threshold is enough to keep out lesser programmers, which certainly helps code quality. The price is that far fewer people use the language.

> pass by reference

I'm not quite sure why so many people think JS is pass by reference.

Everything in JS is passed by value. In fact, unlike some other languages (Swift, C++, etc), the only thing you _can_ do is pass by value. That some of those values are actually references doesn't really have anything to do with evaluation strategy.

Simple types are by value, objects are only by reference - feel free to verify in your friendly local debug console.

More than that, assignment of an object is also only by reference which is super useful and great potential for spaghetti code at the same time.

How it is implemented under the hood I could not care less because it is not exposed to me as a programmer (unlike in C).

no - I believe the parent comment is right it's passed by the value of a reference as seen here from the console

var changeref = function(ref) { ref = {}}

var changeable = {prop: "something"}

changeref(changeable);

changeable; Object { prop: "something" }

var changeprop = function(ref) {ref.prop = "anything"}

changeprop(changeable);

changeable; Object { prop: "anything" }

the use of changeref does not turn ref into an empty object, because you passed the value of the reference, but the use of changeprop did change the property of the object because you are changing the prop on the reference.

at least this is my understanding of how it works. Interestingly enough I totally blew a simple programming test on the phone recently because I forgot about this (well my whole mind went blank and I couldn't do anything so even if I had remembered this it wouldn't have been enough - it was lucky I remembered my name)

on edit: console used, Firefox developer.

Yes, precisely. In a language that supported call by reference, your `changeref` function would actually cause `changeable` to point to an empty object/map (assuming, of course, it had been passed by reference).

This is what I am talking about:

    > function mutate (o) { o.foo = 'bar'; }
    > const o = { foo: 'foo' };
    > o
    { foo: 'foo' }
    > mutate(o);
    > o
    { foo: 'bar' }

I am probably not using terminology correctly, but it is not important as far as Javascript is concerned, since the language does not allow for anything else. What is important is that you can mutate objects you pass into functions and this is useful and dangerous at the same time.

yes, essentially that is the same as my changeprop function so I do understand that - however what the parent comment was arguing about was the actual terminology and wondering why no one ever uses it correctly.

As I noted in another comment I don't think people use the terminology correctly because explaining to people the difference makes explaining an already complicated thing more complicated, and also it makes communication less elegant if more precise. I certainly never say Objects are passed by value of a reference, I just say they are passed by reference and if someone wants to take the time to correct me I would probably say "yes, sorry I was imprecise"

OK, after a bit more reading I now understand the difference, thank you for your patience.

But it remains true that in Javascript you can not pass an object by value, because the language does not permit creating copies of objects. You can only ever pass a reference to an object (which is indeed only ever done by value) so the usefulness of arguing about the distinction is questionable at best.

Again, everything in JS is passed by value - it's not even debatable. Variables pointing to JS objects and arrays are passed by value the same as variables pointing to strings or numbers. The value of the variable is always copied. However, JS objects and arrays are reference types, so the value that is copied is simply a reference to the same data.

I can't really relate, but I do understand that the distinction between evaluation strategy and reference/value types might be a bit difficult for programmers who've never actually had to deal with either concept to grasp, though.

Well probably because so many tutorials and books say it is pass by reference in order to clarify a hard to understand point for novices - thereby eliding an even harder to understand point.

If it takes ages to load the core content, who’s still left on the site for that other stuff? In his comparison it took 40 seconds to load the image, I’d have closed the tab after 10 and none of that other stuff would matter.

Note that the vanilla 37k image took 2.4 seconds. Most people aren't on a 128 kilobit ISDN line. And there's a good chance you have much of the static content cached.

Anyone can easily build an image-serving website. What's hard is to build an image-serving website that pays for itself. I wouldn't be so quick to judge.

Sure. But he did say this was the mobile site, where you may have connectivity issues or low bandwidth. At home, I would never notice. Hell, I usually have good connectivity on my phone too, BUT often when I’m on the train, I have sketchy speeds and during these times, I do notice slow/overly bloated sites or web apps.

> Anyone can easily build an image-serving website. What's hard is to build an image-serving website that pays for itself. I wouldn't be so quick to judge.

That’s very true, but again, you don’t need a bloated slow (comparatively speaking) app to serve advertisement. If the total time had been 10s (ie 7.5 for adverts etc, 2.5 for content), he probably would have thought eh slow but whatever

I actively avoid clicking imgur wherever I can because I know it fails to load half the time.

I hope the people who still stick around on imgur for the community are enjoying the web application because it's clear people who just want to see an image after following a link aren't considered as their audience anymore.

It's totally doable with vanilla JS. You'll just likely end up with a mess or your own framework and all the associated costs.

A good web developer: 1. Finds a way to make the code serve the main purpose of the page/experience _first_ and bring in the extras after the main thing is settled while disturbing the main thing as little as possible. 2. Uses the same mindset to protect the page/experience from marketing/analytics/whoever. You want more pixels? Sure. I'm not telling you that they will only fire at +3s ContentLoaded, but you're probably not asking, either.

Thats out of the scope, you can still target and only load the image. Its all about technical design.

Reply on news.ycombinator.com