Typescript. Why?!?

[Steven Ventimiglia]

Everyone is jumping on the bandwagon, and it makes zero sense to me.  It just seems like more of the same "I don't want to learn to do it correctly, so I'll have something do it for me" mentality.

Why the route of dealing with compiling JavaScript, when you can just skip right to Go?  It's very similar to Typescript, is a few notches above Node.js (imo), and is super-fast.  Typescript is infamous for horrible compilation times, and seems to outright kill production time by necessarily doing just that with every save.

It seems to me that we're just adding unnecessary processes to fundamental approaches.  And, that currently applies to the World, not just code.  It's freakin' depressing.

[Jason Knight]

Go compiles, it's not interpreted so you don't have that realtime result thing some people jones for. Go can't run client-side in a browser whilst typescript can once "compiled" to normal everyday JavaScript. I can to a varying degree see the appeal of using the same language server-side and client-side in a variety of projects.

Typescript is basically to JavaScript/ECMAScript as SCSS is to CSS.

That said, I too have problems with typescript. I SHOULD like it, as I'm a fan of languages that have strict typecasting... but it takes it to pedantic levels that become more annoyance than usefulness, and typically ends up making me write more code that I would without it, that the pre-processor then vomits up even more code for on deployment.

Add in that it is basically an unnecessary extra step, and I just don't get the appeal. Much like LESS/SASS/SCSS it strikes me as the type of thing that if you "need it" or even just find benefit from using it, there is something horrifyingly and dreadfully wrong with either how you're writing your code, or with what it is you're trying to do in the first place.

It has that same reek of trying to shoe-horn concepts from other languages into JavaScript without understanding the language in the first place. Much like some of the newer ECMAScript changes that take a mess and just make it messier.

Admittedly one of my complaints about Go, TypeScript, and much of the newest ECMAScript changes -- a lot of unnecessary changes that just feel like taking ideas from other languages and forcing them into it, with zero concern for code clarity or even the most basic understanding of the differences between compiled and interpreted languages... or in the case of TypeScript and the ECMAScript, a base understanding of how JS is supposed to be used.

That and how painfully cryptic many of these languages get due to "wah wah, eye dunz wunna types". It's one of the things that made me reject "Go" as I find the syntax, function library, and general code construction to be agonizingly obtuse, flipping the bird at code clarity and easily digested logic. Much like "rust" it feels like someone looked at C++ and went "oh this is way too simple to maintain the illusion of programming being difficult. What can we do to make this even harder to understand and work with?"

Just little stupid shit like case sensitivity determining export feels to me like it's DESIGNED to make developers make mistakes; how dare we expect anyone to use a word like "export", or to divide a file into "interface" and "implementation" using FULL WORDS for clarity. To be fair, even just having "func" instead of "function" makes it harder to read. I wanted that level of cryptic shortcuts I'd just use vanilla C.

Vanilla C? Sounds like a powdered drink mix... or a late '80's rapper.

But what do I know? I consider Ada to be the pinnacle of programming language design, and would rather hand assemble 8k of Z80 machine language than try to debug 100 lines of C.

As I've said for two decades or so, I've never been convinced this was a joke:
https://www.gnu.org/fun/jokes/unix-hoax.html

[Steven Ventimiglia]

I enjoy SCSS for a personal reason; I'm forcing myself to improve the code it outputs through personal projects, so that I can teach others how to use it correctly.  Fundamentals are important, and if you can use a new approach to introduce the proper structure established by the parent language that it will be pre-processed into, then I find it a nice way to "give and take".  For instance, my current default.css is a f**ckin' mess.  However, I take refactoring seriously - and enjoy it quite a bit - so it's kind of like building a puzzle by making sure every piece is where it needs to go.. and, "wait... wtf is this doing here?"

The first thing I ever built out with Go is a website.  It took less than three seconds to compile, and got really great speed checks on a cheap-ass server.  It also feels like Node.js, but has a few things I feel it's improved upon - such as `go get [repository]`.  Being one of the few languages that, when compiled and run,  can use multiple processors in tandem...  it's one of the fastest out there.  Node.js is supposedly second (when not hindered by bloat), and PHP 7 is ranked third.  I also use BrowserSync as a dev tool, and time it to about three seconds per refresh, as opposed to one second.  As I worked on my Go-based website, there was zero difference between that and using Browsersync for static HTML - which was one of the most impressive things to me.  I also like the fact that NO ONE can futz with the code place at an endpoint, which is a huge fault for CMSes like WordMess.  People love going straight into the server and changing code, but there ain't no page to pull up with a delivery system like Go.

As for ES6, I do have to agree with the move from the previous way it handled variables.  I feel `let` and `const` are great additions - however, more often than not, I stick to `function` as opposed to fat arrows.  It seems more obvious to me as I review my own work, but that could be a sign of age. 

[Jason Knight]

I enjoy SCSS for a personal reason

For me it's just another train wreck laundry list of how NOT to use CSS, and I see zero benefits to wasting time on an extra step given how LITTLE it provides.

Like a LOT of things I see out there, the only way one could perceive benefits from using it is if they are already deploying two to ten times the code needed through faulty methodology or ideology. If you have a giant bloated train wreck of incompetence, I could see it helping... but if you just wrote it (what I consider) correctly in the first huffing place, you wouldn't need it... it too just wastes time, adds complexity, and provides no real tangible benefits for anything I do or could conceive doing.

It peddles some heavy duty kool aid.

But again, I still say 90%+ of websites have any business with more than 48k of CSS in one file per media target FOR AN ENTIRE SITE or 64k of scripting for the template (so not counting social media plugins, adverts, etc) in two files... Which is why when I see half a megabyte of CSS spanning a dozen files, with no media="" on their LINK or STYLE in the markup, I KNOW I'm looking at another monument to the 3i of web development.

Ignorance, incompetence, and ineptitude.

Particularly when what created these massive bloated wrecks are touted as "easier" or "better for collaboration" -- since in most every case that's someone just talking out their backside.

[Steven Ventimiglia]

I agree to a certain extent, but that was a bit of a misquote.

I enjoy it, because I'm looking at it from a reverse engineering perspective to find a solution that can be explained in way that would be understood.  If you try to push someone back into something they feel is antiquated, without explaining why the approach that's being used by them is inadequate, you'll never earn their trust.

"You shouldn't show up at a gun show without knowing how to hold one."

Dealing with new developers all of the time, I need to be armed with the ability to show them examples of how to write DRY and effective CSS correctly.  We build stylesheets using SCSS, and then I review with them the CSS file it produces.  At that point, I have a more respected and authorative stance when showing them how it would have been much cleaner and much more organized if they weren't relying on what seems to them to be a magical solution.

If you enter the playground finger-pointing, that's all you'll be doing; with zero results and a bunch of kids who now hate the way you look, walk and talk.

[Jason Knight]

If you try to push someone back into something they feel is antiquated, without explaining why the approach that's being used by them is inadequate, you'll never earn their trust.

Thing is your "facts" are just going to piss them off even more. You can laundry list full explanations and itemized accounts of every damned thing these dipshit systems do wrong, and all it does is entrench them more... hence why I gave up on that approach over a decade ago. It doesn't work, you can't play nice with these douchebags. All it amounts to is appeasement -- ask 1930's Europe how well appeasement works.

Thanks to propaganda, exploitation of mental failings, bald faced lies held up as the greatest truths ever, and a general gullibility amongst the rank and file, FACTS just piss people off no matter how you sugar coat it. They are so convinced that these fat, bloated, hard to use, time wasting systems are somehow magically easier, simpler, faster, or better, that NO amount of facts can change their minds. You're fighting cognitive dissonance, and the ONLY documented way of breaking out of that cycle of derp is trauma. It's like slapping a hysterical person, you MIGHT wake them up.

Sitting around playing paddy-cakes whilst hoping they might listen? They're just gonna stick their heads in the sands like ostrich at BEST, utterly lose their shit at worst screaming "Wah wah, is not"

I know, I've seen it for over a decade straight now! No matter how nicely we put it, they're gonna derp -- so it's well past time to put down the party favors, soothing syrup, and call these people out on their ignorance, lame excuses, and BALD FACED LIES!

Because they're going to act like you're taking a dump in their cornflakes the moment you bring facts that contradict the lies they truly believe like cut-rate cultists; and playing nice isn't convincing anybody. Oh, THEY get to play dirty and control the narrative, but I'm supposed to just sit here turning cheeks? BULLSHIT!

[John_Betong]

@Jason Knight,

There are many types of individuals and each requires a different learning technique. Treating all like donkeys and three techniques spring to mind; carrot, stick or a Jenny.

The best management technique is suggestion hoping the individual thinks of what you are trying to implant... and then congratulate the individual on their brilliance.

Beware that many rebel with incorrect approaches... resulting in being reported or banned

[Steven Ventimiglia]

Ah, now i understand Typescript a bit more than I did.  Thanks for the explanation.

I've seen the benefits in being able to concatenate, minify, and uglify files.  These days, I'm using Gulp to do all of the things I used to use software like Prepros and Codekit for.  It's also pretty fast, considering that I Browsersync and in that second or two that it takes to reload the browsers on all devices, Gulp has already done it's job. I enjoy things like that, because it lets me experiment a bit more than usual with things like Babel which will transpile the code for backward compatibility.

Having said that... I look at Typescript as a branded version of the same thing, much like the ridiculous amount of JS frameworks that pop up every second of every day.  Almost as if no one can code JavaScript correctly, and they refuse to understand anyone else's approach, so they create their own custom (and broken) framework and try to push that on everyone.  Angular and React are great examples of that.  Angular JS 1.x is an even better example of why I stay away from them, for the most part.

With SCSS, however - even though you aren't forced to nest your CSS like a schmuck, or use crap like `@expand` - I do see a big advantage in using things like `@mixin` for creating reusable property sets that can then be included with different values - and especially `@import` for creating my CSS with the overall structure of modular components.  Most folks often make the mistake of just lumping it all together, but if you're looking at optimizing delivery of those styles, you can then have multiple CSS files compiled by simply editing a partial.

So, syntatical lazyness isn't important to me.  However, it's really nice to make a single change in one place, and have those changes applied auto-magically to several stylesheets that will be used when they need to be; so I'm not linking to more than one per page and slowing down the performance by cherry picking several files for no reason as if I'm connecting to a remote CDN.

[Jason Knight]

I do see a big advantage in using things like `@mixin` for creating reusable property sets that can then be included with different values

which to me just means not knowing how to use selectors. I have a value I want shared across multiple selectors, I put the selectors together and declare the property/value. I don't need some stupid "mixin" for that.

and especially `@import` for creating my CSS with the overall structure of modular components.

Something I also would never have since that's multiple CSS files per media target, a violation of good practices and pissing on caching models.

Most folks often make the mistake of just lumping it all together, but if you're looking at optimizing delivery of those styles, you can then have multiple CSS files compiled by simply editing a partial.

Whereas to me having multiple CSS files in the first place -- at least per media target... assuming one HAS media targets --is an epic /FAIL/ at web development.

If you have enough CSS for any of that to be "useful" you've just got too damned much CSS!

So, syntatical lazyness isn't important to me.  However, it's really nice to make a single change in one place, and have those changes applied auto-magically to several stylesheets that will be used when they need to be

Which is to say... never, because there's no reason to have more than one stylesheet (per media target), at least not for one's own style.

It means missing pre-caching, making editing harder...

... and don't even get me STARTED about trying to debug other people's SCSS BS since the document inspector has no huffing clue what/where in your SCSS trash anything is.

But again, I've NEVER seen a website -- even retaining whatever appearance it has that actually belongs on a website -- that warrants more than 48k in one file per media target. .. and it's why when I see people with half a megabyte spread out over 12 files (not counting things like social plugins) I wonder just what the **** they think they're doing.

As I've said thousands of times the past decade, maybe if people stopped vomiting up four times the markup, ten times the CSS, and 50 times the JavaScript needed to deliver content to users, they wouldn't have these types of "problems" or be so easily suckered in by the 100% grade A farm fresh BULLSHIT that are frameworks and pre-processors.

Every argument in favor of them holds water like a steel sieve. That's the best kind... of sieve... I hear...