Javascript framework fatigue (article)

blakeyrat

NodeJS also suffers the same problem that C# and Python suffer, in that while the core library is rock solid and nice

Whoa. I haven't used Node.js so I can't question those assertions, but I've used Python and its core libraries are boiled-over shit. Not to mention their idea of "core" is so tiny it doesn't contain anything you'd actually want to do with your program, so even for the most basic shit you have to go to the "community libraries", which even you admit are crud.

@accalia said:

NodeJS shows that problem more than the other two because of NPM and culture which encourages gluing together third party libraries until you have what you want. a Lego(tm) approach to coding if you will. This leads to subpar code but is not the fault of the language or the core library, rather it is how that core library is used as glue between different third party libraries of undetermined quality.

Bad is bad.

Languages that are bad because they encourage writing bad code or constructing applications in bad ways are just as bad as languages that are bad because they're ... just bad. Either way you end up with a shitty application. The end user of it doesn't care why it's shitty.

@RaceProUK said:

It helps that MS provided quite an extensive framework for C# (and .NET in general), meaning there are a lot less gaps to plug.

Yes that is the point.

Look, the guys who get paid for creating the libraries are the guys who are going to do a good job, ok? They have a QA department and everything. Those are the guys you want doing 95% of the work.

The volunteer idiots? They don't do a good job. They write libraries with bugs, they don't bother testing anything, they write the library to handle their own extremely narrow use-case with no thought as to how anybody else would want to use it (I recall here the Twitterizer library for C# which failed to provide any method to get the raw JSON of a status object, even though it's a fluid "schema" that could change any day and frequently does.) You don't want them doing the work, because they do bad work.

Now in the C# ecosystem, the guys paid to do good work with have the QA team and actually spend more than 47 nanoseconds thinking about how generally-applicable their work is? Those guys did something close to 95% of the libraries.

In the Python ecosystem, those guys did... wait, do those guys even exist in the Python ecosystem?

accalia

@cartman82 said:

Standard node.js library is an abomination that's not following its own supposed standards. Case in point: http.listen.

[citation needed]
in what way is that function breaking the nodejs standards?

ah. nevermind. you explain it later.

i still disagree, but at least you explained your point. ;-)

dkf

@blakeyrat said:

Not to mention their idea of "core" is so tiny it doesn't contain anything you'd actually want to do with your program

That's one of these arguments that runs and runs. The more features you put in the core, the harder it is to make releases and fix bugs (unless you happen to have a very large amount of money to support you, which isn't most folks). Relying on putting more into third-party libraries makes that easier — you've decoupled the release cycles — but it does mean that there's more of a chance that the functionality will be in some library of distinctly dodgy quality. You could also sit and wait for everything you need to be made available in some "core" but then you might be sitting and waiting a long time.

In the end, we get a compromise: people try to make a really solid but fairly small "core", and then rely on third-party stuff for other things. There needs to be a way of identifying which of those third party libs are Good Stuff and which ain't, but that's a tricky problem, especially as it changes over time and depends on what exactly people are doing with the libraries…

Those of us who make libraries and frameworks should at least try to make sure they don't have ‘surprising’ interactions with other things.

flabdablet

@blakeyrat said:

the classes in WebAPI2 are all sealed, so if you want to write custom code to get it to handle file uploads well... fuck you!

Sorry, did I just see you complaining that something wasn't open source enough?

blakeyrat

That has nothing to do with open source, it has to do with standard C# extensibility. C# isn't C++... classes aren't just compiled into crap and then you can't touch them, you're supposed to be able to subclass shit and make your own version do what you want. Except for some reason, they then created the "sealed" keyword to prevent you from doing that...

There's absolutely no reason for the auto-hydrator class in WebAPI2 to be marked as "sealed". Open source or not, that was a stupid move on their part because it made their library significantly less useful.

Personally I don't think the "sealed" keyword should exist at all.

Jaime

Sealed usually means "we made a design choice that makes extensibility problematic". Think about what would happen if someone subclassed string and made it no longer immutable.

dkf

@Jaime said:

Think about what would happen if someone subclassed string and made it no longer immutable.

Would that be possible? The fields wouldn't be exposed, and the methods that work with them would be prevented from being overridden. About the only real problem would be that future extensions to string would potentially clash with what people have added in themselves, and that's always possible with an extension mechanism. Or is there some subtlety I'm missing…?

Jaime

Several compiler optimizations (in Java and .Net) are based on the fact that strings are immutable. If you used a custom string derived class that wasn't immutable, then your application would behave unpredictably.

It wouldn't be possible because the designers of these languages knew that the optimizations they made would require string to be sealed, so they sealed it. If blakeyrat got his wish and sealed was abolished, either the optimizations would have to be removed or the compiler would be broken.

@dkf said:

About the only real problem would be that future extensions to string would potentially clash with what people have added in themselves

string x = "Hello";
string y = "Hello";

At this point, the compiler is allowed to only store one object. If you could mutate the contents of a string, then...

y.Append(" World");

could affect both x and y.

dkf

@Jaime said:

If blakeyrat got his wish and sealed was abolished, either the optimizations would have to be removed or the compiler would be broken.

My point is that if there's no way for the added methods to actually mutate the string, the contract isn't broken. I'm pretty sure that C# prevents overriding of methods by default anyway (that would otherwise definitely permit mischief), and that all that's required therefore is to make sure that the state is stored in fields that are solidly private, which they should be anyway. The subclass won't have privileged access, and the compiler will be able to optimise as it chooses.

I think there's something else more subtle to it.

Jaime

@dkf said:

My point is that if there's no way for the added methods to actually mutate the string, the contract isn't broken.

Yes it is. If you do nothing other than add another property, you will be screwed if the compiler combines two instances that it thinks are the same. Also, modifying a string discards the current instance and creates a new one. So, if you perform any string operations on your string subclass, all of your custom properties will be reset.

Also, if you code funky constructors, the compiler might not even be able to create an instance from a string literal.

dkf

That's what I was talking about by “more subtle”. String subclasses would be getting lost fairly easily because the fixed superclass methods wouldn't know anything about them. The constructors wouldn't be an issue though; you can't change the string class itself, just define subclasses of it.

Frankly, there's not much point in subclassing string.

Subclassing class, now that is interesting!

boomzilla

@blakeyrat said:

GOD FORBID you just take what I type at face value.

There's no way I wasn't 'd 3 days ago, but CITE YOUR SHIT.

boomzilla

@blakeyrat said:

I honestly don't think the math for using ~~frameworks~~high level programming languages ever adds-up. Because the first instant you hit a snag (and you always hit a snag), you've lost whatever time savings you gained by choosing the ~~framework~~high level language in the first place.

ITFY

boomzilla

@Yamikuronue said:

My favorite is Twee. It's like, "I thought about using a framework, but the ones I looked at were so twee I gave up."

@FrostCat, please call your office.

Eh...pretty sure he's used that word more than anyone else around here...

boomzilla

@dkf said:

In the end, we get a compromise:

This isn't in his lexicon.

Bort

@boomzilla said:

@blakeyrat said:
I honestly don't think the math for using the .Net Framework ever adds-up. Because the first instant you hit a snag (and you always hit a snag), you've lost whatever time savings you gained by choosing the .Net Framework in the first place.

ITFY

BTITFYCTHFY

dkf

@boomzilla said:

This isn't in his lexicon.

I know, but he'd save himself a whole load of time and effort if he did. (Also known as looking at the whole cost function, not just one little aspect of it.)

Buddy

@blakeyrat said:

Personally I don't think the "sealed" keyword should exist at all.

Ok, to be able to properly criticize you for this I'd need to know why you want to subclass stuff in the first place. If its to get at the object's protected members, surely you can see why that's bad—how much more bug testing that would mean for them. If it's because you want to pass your own object in where they're expecting their own concrete type, your issue isn't with the sealed keyword at all—it's with the use of a concrete type as a parameter, instead of an interface.

cartman82

http://www.foreverscape.com/art/2016/byte-me-javascript-fatigue/

Javascript fatigue fatigue fatigue. We've reached full circle with this fatigue crap.

RaceProUK

Write. Better. Code.

That's all you need to take away from that article

NedFodder

I was gonna choose

DON'T FRIGGIN ADD "F" to GOD DAMN 2.6 anymore.

cartman82

@RaceProUK said:

Write. Better. Code.

@NedFodder said:

DON'T FRIGGIN ADD "F" to GOD DAMN 2.6 anymore.

That rant has a lot of great rantlets like that.

DogsB

Not enough fucks and I still can't remember what SOLID means. I did for interviews but then starting writing code again and forgot there were principles. :(

He's has a point. At the end of the day : DO YOUR FUCKING JOB! With a bit of luck you'll end up somewhere where you get to experience the joy I felt today at the prospect of writing unit tests with a refactor and expansion on the horizon.

dkf

go back to being scrum master and get me some coffee

Yamikuronue

Write. Better. Code.

This guy won me over :D

Yamikuronue

It's like, languages that allow shitty code isn't something new. You know how the industry has always dealt with this problem? By not hiring people who write shitty code. Somehow webdevs think they're above that, that anyone can sit down with the right tools and work at Google. Fucking learn to code.

anonymous234

It's the same problem that happens every time someone makes a tool to make programming easier, from C++ (e.g. Linus Torvalds said C is better because it "keeps the noobs away") to Javascript frameworks.

The new tool allows bad/novice programmers to code stuff they couldn't before, and expert programmers to write lazier code. But that "lazy code" is worse than what we had before, so people claim the new framework is making things worse.

The fallacy is that just because something allows bad code to be written, doesn't mean it has to result in bad code. A good programmer putting as many hours in the new tool as he did with the old fashioned tool will create something much more awesome than what was possible before*. The real problem is that you lack a way to incentivize good code, other than artificially increasing difficulty.

* Might not be strictly true for all tools. Some really do limit what you can do. But they are rare.

dkf

@anonymous234 said:

Some really do limit what you can do.

All tools limit you somewhat. Sometimes that is a good thing, as it lets you do more in different (and more important) directions.

Jaime

@anonymous234 said:

The fallacy is that just because something allows bad code to be written, doesn't mean it has to result in bad code.

Not a fallacy, a correlation. Languages that don't allow bad code have no bad code written in them. Languages that allow bad code will have some bad code, which is more than none. Obviously, this is an extreme case, but in real life, the more bad code you allow, the more you get.

Remember; correlation doesn't imply causation. No one is saying the javascript causes bad code, it just attracts it.

dkf

@Jaime said:

Languages that don't allow bad code have no bad code written in them.

To be fair, they usually have no code written in them at all.

Jaime

@anonymous234 said:

The new tool allows bad/novice programmers to code stuff they couldn't before, and expert programmers to write lazier code. But that "lazy code" is worse than what we had before, so people claim the new framework is making things worse.

Microsoft's solution to this problem has been to follow the mantra of "Design the system so the easiest code to write is the correct code to write".

powerlord

@DogsB said:

Not enough fucks and I still can't remember what SOLID means

Stack Overflow Likes Is Dumb?

Filed under: Yes I know that should be Are not Is

powerlord

@Yamikuronue said:

Fucking learn to code.

You're assuming I actually get to code.

One of my tasks for today is literally "make icons that when clicked send multiple semi-colon separated commands to a Java applet."

Side note 1: I have no art skills, so fuck knows why I'm assigned to this part and not one of the 3 graphic designers who work in our department.

Side note 2: Said applet is a written by one of our contractors and getting rid of it is not an option.

blakeyrat

@powerlord said:

Side note 1: I have no art skills, so fuck knows why I'm assigned to this part and not one of the 3 graphic designers who work in our department.

Delegate.

@powerlord said:

Side note 2: Said applet is a written by one of our contractors and getting rid of it is not an option.

Homicide.

Dragnslcr

@powerlord said:

Side note 1: I have no art skills, so fuck knows why I'm assigned to this part and not one of the 3 graphic designers who work in our department.

Colored squares, maybe with a letter in the middle. If someone doesn't like them, tell them that if they want high quality icons, maybe they should ask the professional graphics artists to do the icons instead.

RaceProUK

@Dragnslcr said:

Colored squares, maybe with a letter in the middle

And if you're doing that, why make the images yourself when you can let Discourse do it?

Yamikuronue

@Jaime said:

"Design the system so the easiest code to write is the correct code to write".

This is the correct decision from a language design perspective, but how many of these ranters are actually designing Javascript? The tool is out there, they have to deal with it.

Jaime

It goes for API and framework design too, not just languages. The ADO.Net design was very heavily influenced by the fact that almost nobody used the optional scalability features of ADO. So, Microsoft made them included by default and you had to do work arounds to build less scalable code.

Vaire

Does jQuery have its uses? You bet? JavaScript? Of course. AJAX, naturally.
What about Angular, Ember, React, MuugleFu & Dinosauzer? (I may have made some of those up, I challenge your hipster cred to tell me which!)
Nope, hard nope.

SPAs can die in a fire, as can legoing together a bunch of APIs that sit on top of JS, calling it an application, and walking away.

RaceProUK

@Vaire said:

MuugleFu

@Vaire said:

Dinosauzer

Are the made-up ones.

And I don't have any hipster cred, so I don't care if I'm wrong

Vaire

You're no fun. I knew I should have worked harder on those names =_=
Ah well, c'est la vie.

RaceProUK

TBH, it wouldn't surprise me if they were real packages; after all, there's packages such as gulp, grunt, yo, mocha, chai, buttercup, chalk, q, cheerio, through, morgan, etc.

And yes, those are all real NodeJS modules