Embedding scripts directly from 3rd party CDN! What could go wrong?
-
Or, why I absolutely hate frontend developers with all my might.
I'm thinking of doing some programming in Rust, and I wonder if it can do GUI by now? Then I remember there was this website that was set up specifically to track the progress of the community effort to make that true! How was it called... Oh, here it is!
You may not realize it at first but the website is completely broken. The bottom of the home page is supposed to show a list, but instead there's never ending "loading". So let's do what any sensible person would do and see what the console has to say!
These two messages tell us a very interesting story. Namely:
- The first one means the Vue library loaded correctly.
- The second one means the Vue library did not load correctly.
If you've ever worked with frontend, you should already know what it means. For those among us who are a bit on the slow side, and those who somehow managed to completely avoid any contact with the shitshow that the JS ecosystem is, here's quick explanation. As everyone knows, JS sucks, and JS frameworks suck even more. Even JS developers know that JS frameworks suck - that's why they invent a new one every other weekend. One of the newer frameworks is Vue, which is basically React but "better". (In case you don't know, React is basically Angular but "better".) When JS devs feel particularly lazy, they skip over the step where you come up with a new name and instead take an existing framework. rewrite everything from scratch taking extra care to make sure nothing is backwards compatible, and just bump the version number. Hopefully the major. That was the case with Vue, on two separate occasions.
So there's the old Vue 1.0, there's the somewhat less old Vue 2.0, and there's the Vue 3.0 that's nothing like the old 2.0 even in its most basic functionality. After all, what would be the point of making a new version if it was even the tiniest bit the same as the previous one?
Okay so let's go back to the website. Where does it get its library from? Let's look at teh codez:
cdn.jsdelivr.com. Yes, yes. This is exactly what you think (you read the thread title, right?). It's basically an NPM mirror but set up in such a way that webdevs who are too lazy or incompetent to copy the library files to target directory, can instead link directly to this random website beyond their control and it will serve an unknown version of an unknown library that's named similarly to the one they use in the development environment. After all, it's not like they already have a place on their own server where they can put JS scripts because they're making a motherfucking web app that's itself made of JS scripts for fuck's sake.What happened next is an absolute surprise that nobody could possibly predict in advance because nothing like that has ever happened before haha who am I kidding. The utter fucking moron I mean the developer, being an utt I mean a developer, didn't specify framework version when making a website, which worked completely fine for the five hours he spent making that website. But a year later, another u... developer who was in charge of that public CDN went all "ooh shiny!" over the new major version of Vue, pushed it to the main repo and made it the new default so millions of other... developers can start basking in its glory immediately. Lo and behold, nothing works anymore.
</rant>
-
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
can instead link directly to this random website beyond their control and it will serve an unknown version of an unknown library that's named similarly to the one they use in the development environment.
And the thing is, you can actually pin the version retrieved with some extra shit in the URL! I.e.:
https://cdn.jsdelivr.net/npm/vue@2.6.12/dist/vue.min.jsBut it's too hard to read the front page that talks about that...
-
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
After all, it's not like they already have a place on their own server where they can put JS scripts because they're making a motherfucking web app that's itself made of JS scripts for fuck's sake.
Well, there used to be an upside to using a central CDN: If the script was already in the cache, the site would load a bit faster.
Now that browsers are starting to implement separate browser caches to avoid privacy leaks, that advantage will be gone very soon. (AFAIK already is in Safari and Firefox, soon will be in Chrome.)
-
@dfdub said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
After all, it's not like they already have a place on their own server where they can put JS scripts because they're making a motherfucking web app that's itself made of JS scripts for fuck's sake.
Well, there used to be an upside to using a central CDN: If the script was already in the cache, the site would load a bit faster.
There used to be an upside to using dynamic linking for desktop apps too.
-
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
You may not realize it at first but the web
siteis completely broken.
Current approaches to building GUIs in Rust include interfacing with Electron and building GUIs with HTML (or a framework on top of it)
I just threw up in my mouth a little bit.
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
There used to be an upside to using dynamic linking for desktop apps too.
The solution to that is correct semantic versioning, on Windows by SXS, on Linux by using package managers that handled this since the dawn of time. The alternative is that every app now comes as a snap/docker/whatever-the-fuck container duplicating 100MB of OS functionality for a 100KB app, and security patches (not feature updates) having to be downstreamed for every single little thing. For large applications that might be a sane approach, but not for everything. I don't really think I like this brave new world.
-
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
I'm thinking of doing some programming in Rust
Seems best avoided
-
@topspin said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
The solution to that is correct semantic versioning
@topspin said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
I don't really think I like this brave new world.
Bro we've been doing the "ship every single DLL used by the application alongside the executable" in C++ world since forever. Except for system libraries, which you NEVER ship by yourself because then you can't talk to the system, relying on any library being installed correctly and in correct version by external forces has always been nothing but unnecessary pain. I have personally experienced several times being unable to run some Linux app because the
glibpackage was updated to a new minor version and now the app crashes on startup. And before you ask - yes, both the apps and theglibcame from the same repository and were both up to date.
-
@loopback0 said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
I'm thinking of doing some programming in Rust
Seems best avoided
Maybe, but I heard the new reverse engineered Flash Player would be on Rust. Sounds cool to me.
-
@cheong cool, as in the polar opposite of hot?
-
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
the
glibpackage
-
@dkf yes, yes there is. But it's not like it was my choice. Other than ignoring the very existence of Linux whatsoever, that is... Which becomes more tempting with each day.
-
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
Other than ignoring the very existence of
LinuxGTK and everything that starts with a g whatsoever, that is... Which becomes more tempting with each day.I hate that stuff, but I think I've mentioned that before.
-
@topspin said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
I hate that stuff, but I think I've mentioned that before.
That sounds like something I would say. On every topic.
Edit: except Rust. Rust is still awesome. Still can't into GUI, though, but I wouldn't want to use anything that isn't WPF anyway.
-
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
I'm thinking of doing some programming in Rust, and I wonder if it can do GUI by now?
As I understand it, the problem is that GUIs are a natural case for frameworks and callbacks and so on, and that's stuff that Rust's preferred lifetime management and type specialization rules don't handle well. I don't exactly grasp why it's such a big issue but having looked at pages on callbacks in Rust, the complexity they invoke is a worrying thing and not what you really want when doing something as complicated as a GUI. And GUIs really do sit best as frameworks and are very heavily callback-driven; without that you very quickly end up bogged down in the quicksand of message routing. Also, GUI entities can spontaneously delete themselves (often due to the user).
-
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
@cheong cool, as in the polar opposite of hot?
Cool as in "this sounds like rocket science to me".
-
@dkf these are the technical aspects, but an even bigger factor is that a good GUI framework is a mega-shitton load of work. Every single element has hundreds of little quirks that you have to get all right or else it'll feel like shit to use. Resizing, right-to-left text, screen reader support, keyboard controls, etc. etc. It's basically impossible to do all that without corporate backing, and I don't think any corporation will back effort to create a Qt competitor in foreseeable future, especially since everything is done on the web now.
It's also one of the handful of cases where classic class-based inheritance actually makes more sense than alternatives - the ability to selectively override tiny parts of the element's behavior while keeping the other 99% intact is a must-have. This is unlike anything you'll ever see in back-end type of code. Everything that makes Rust so great at back-end stuff is in direct opposition to what's needed for GUI.
-
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
Still can't into GUI, though, but I wouldn't want to use anything that isn't WPF anyway.
That's not really available on other platforms, though, other than maybe some half-baked Mono hacks?
-
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
(In case you don't know, React is basically Angular but "better".)
When JS devs feel particularly lazy, they skip over the step where you come up with a new name and instead take an existing framework. rewrite everything from scratch taking extra care to make sure nothing is backwards compatible, and just bump the version number.
-
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
Bro we've been doing the "ship every single DLL used by the application alongside the executable" in C++ world since forever.
A while ago I uninstalled G-Hub after confirming that the older Logitech Gaming Software was approximately 746871238x better, and it threw up an error about some dll (msvc runtime, I forget the details) being busted. Luckily, I had 150 other copies of the same DLL hanging out in every application folder on the computer that I could copy over the broken one in order to let the uninstaller run.
-
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
Bro we've been doing the "ship every single DLL used by the application alongside the executable" in C++ world since forever.
To be fair, I just checked again and indeed on Windows I'm doing exactly the same. On linux I just add dependencies to the rpm though.
-
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
It's also one of the handful of cases where classic class-based inheritance actually makes more sense than alternatives
Scripting the binding between most events (repaint and resize events excepted) and the changes to the model works even better; lets you have most tweaks without needing subclassing at all. That's also very much not the Rust way of doing things: the script might do something unexpected!!!
-
@topspin said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
Still can't into GUI, though, but I wouldn't want to use anything that isn't WPF anyway.
That's not really available on other platforms, though, other than maybe some half-baked Mono hacks?
Thankfully I don't use other platforms either!
-
@dkf said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
It's also one of the handful of cases where classic class-based inheritance actually makes more sense than alternatives
Scripting the binding between most events (repaint and resize events excepted) and the changes to the model works even better; lets you have most tweaks without needing subclassing at all.
Most. That implies sometimes it's not enough. And it isn't. Sometimes what you want is just sliiiiightly different behavior of some basic fundamental functionality of a control, and your choices are either subclassing or making a brand new control basically from scratch. BTDT.
-
@Gąska google recommends linking directly to their CDN, if I understand this correctly:
Hosted Libraries | Google for Developers
Get a list of the libraries included in this Google-hosted content distribution network for popular, open source JavaScript libraries.
but this one has the versions in the URL
-
@sockpuppet7 said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
@Gąska google recommends linking directly to their CDN, if I understand this correctly:
Of course they do. Have you ever seen Google shying away from getting even more control over other people and organizations?
-
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
@sockpuppet7 said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
@Gąska google recommends linking directly to their CDN, if I understand this correctly:
Of course they do. Have you ever seen Google shying away from getting even more control over other people and organizations?
Google also recommends pages use their AMP hosting and their search results no longer actually link to the page directly, so for every reddit hit I get a broken AMP redirect.
-
@sockpuppet7 said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
google recommends linking directly to their CDN, if I understand this correctly
They do at least
encourageforce it to be linked to a specific version, and looking at that page they host quite a few versions of them.
-
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
Most. That implies sometimes it's not enough. And it isn't.
But it happens a lot less than you seem to think. If you make, say, a button that is too different from how buttons are expected to look, users won't understand it as a button and will find the GUIs containing it hard to use.
-
@dkf something something flat design
-
@HardwareGeek said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
@dkf something something flat design
something something that ship has sailed.
-
@topspin said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
@HardwareGeek said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
@dkf something something flat design
something something that ship
has sailedsank in the entrance to the harbor and has been obstructing navigation ever since.
-
@dkf said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
Most. That implies sometimes it's not enough. And it isn't.
But it happens a lot less than you seem to think.
You seem to think I seem to think it happens much more often than I actually think how often it happens.
Yes, for every 500 visual components I add to my windows across all projects, only like 1 or 2 has behavior so weird that I need to subclass. But in those 1 or 2 cases, damn, if I weren't able to subclass and hand-tune the fine details, I'd be totally screwed. It's not about what you do everyday - it's about what you're able to do in times of need. For example, you don't need precise control over struct padding 99.99% of the time, but if C++ didn't allow that, there goes half the reason why would anybody ever use C++ for anything in this day and age.
-
@Gąska I think that it's useful to have a general drawing surface as part of the basic component set., especially if it includes the logic so that you don't just hand off the actual drawing part (you say what to draw, of course) but also the routing of incoming messages so the component acts as a hypergraphics surface. That makes doing weird custom controls much easier.
-
@dkf that too. But when it's just tiiiny bit different from what already exists, it saves incredible amounts of work to simply subclass. I've had a very good real life problem like that recently. Consider WrapPanel - it's a layout element that arranges its child controls in rows, left to right, such that when a window resizes and there's not enough space anymore, overflowing elements get automatically moved to rows further down.
I wanted to do that except I wanted the non-first rows to have a bit of left indent. Nothing in the standard library that could do that, and none of the popular 3rd party libraries have it either. So I had only two options to choose from:
- Rewrite the entire WrapPanel implementation from scratch. And I mean THE ENTIRE IMPLEMENTATION.
- Make a subclass and override just one small function out of dozens.
-
@Gąska seems to be a good case for OOP. It can get problematic with such large hierarchies when you overwrite something in a way the original author didn't design for. Less likely with well designed interfaces (which I assume WPF has) than with random monkey patching all over the place like it happens in some languages/frameworks.
-
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
@dkf said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
Most. That implies sometimes it's not enough. And it isn't.
But it happens a lot less than you seem to think.
You seem to think I seem to think it happens much more often than I actually think how often it happens.
Yes, for every 500 visual components I add to my windows across all projects, only like 1 or 2 has behavior so weird that I need to subclass. But in those 1 or 2 cases, damn, if I weren't able to subclass and hand-tune the fine details, I'd be totally screwed. It's not about what you do everyday - it's about what you're able to do in times of need. For example, you don't need precise control over struct padding 99.99% of the time, but if C++ didn't allow that, there goes half the reason why would anybody ever use C++ for anything in this day and age.
The "Windows Procedure" thing doesn't seem much different than subclassing, and it's a plain C solution
-
@sockpuppet7 yes. And?
-
@Gąska I'm saying the alternative to OOP isn't rewriting the modified component from scratch
-
@sockpuppet7 by showing an OOP design? Sounds like OOP really is the only option.
-
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
Consider WrapPanel
I'd forgotten that some GUI toolkits put their layout algorithms in their components.
-
@dkf then substitute layouting for anything else. Dunno, video thumbnails in treeview or whatever. The point is, sometimes you find yourself wanting 99% of what some control does already and only change the last 1% - and subclassing is the only design pattern that lets you do that without the original developer being clairvoyant and knowing exactly every single future use case everybody would ever have.
-
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
subclassing is the only design pattern that lets you do that
And that's the part of your statement that I dispute. It really isn't the only choice, except in an “if all you've got is a hammer, everything looks like a nail” sense.
-
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
@sockpuppet7 by showing an OOP design? Sounds like OOP really is the only option.
The thing that the Win32 windowing API calls "subclassing" is more like monkeypatching, because you modify a specific window's window procedure to change the behaviour.
-
@dkf said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
subclassing is the only design pattern that lets you do that
And that's the part of your statement that I dispute. It really isn't the only choice, except in an “if all you've got is a hammer, everything looks like a nail” sense.
Everyone just disputes, but nobody has provided even one example. Trust me, I'd love to know how to do it another way. It's just that as far as I can see, there is no other way for this one specific rarely used thing.
-
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
@sockpuppet7 by showing an OOP design? Sounds like OOP really is the only option.
whatever, you can do that with rust
-
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
subclassing is the only design pattern that lets you do that without the original developer being clairvoyant and knowing exactly every single future use case everybody would ever have
They don't have to be clairvoyant exactly. They just can't be lazy and hardcode everything.
-
@sockpuppet7 said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
@sockpuppet7 by showing an OOP design? Sounds like OOP really is the only option.
whatever, you can do that with rust
No you can't. Not without a hefty amount of unsafe code anyway - i.e. abandoning the entire reason why you would want to use Rust in the first place. WinAPI's window procedure model is completely incompatible with Rust's ownership model.
-
@Zenith said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
subclassing is the only design pattern that lets you do that without the original developer being clairvoyant and knowing exactly every single future use case everybody would ever have
They don't have to be clairvoyant exactly. They just can't be lazy and hardcode everything.
There is a very thin line between "hardcoded too much" and "made things so configurable that even the simplest things require ungodly amounts of boilerplate". Seen both many times, in all kinds of libraries for all kinds of purposes - and I almost never see the golden middle where everything that needs to be configurable is configurable and things that don't have to aren't.
-
@Gąska As I recall, you do alot with WPF, whereas I use Windows Forms. I have to read through the .NET reference when fixing those controls and they are full of ghost properties and magic numbers. When I fix them, I have to reintroduce tons of features that should be standard.
-
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
@Zenith said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
@Gąska said in Embedding scripts directly from 3rd party CDN! What could go wrong?:
subclassing is the only design pattern that lets you do that without the original developer being clairvoyant and knowing exactly every single future use case everybody would ever have
They don't have to be clairvoyant exactly. They just can't be lazy and hardcode everything.
There is a very thin line between "hardcoded too much" and "made things so configurable that even the simplest things require ungodly amounts of boilerplate". Seen both many times, in all kinds of libraries for all kinds of purposes - and I almost never see the golden middle where everything that needs to be configurable is configurable and things that don't have to aren't.
Everyone will need different things to be configurable, so almost everything would need to be configurable to cover what everyone wants. Give everything opinionated defaults, and let people that want to fiddle the bits deal with the reams of boilerplate when going off the reservation.
This will make everything a lot more complex, and there will be a minefield of bugs when doing odd stuff, because software. But the golden middle of just the right stuff configurable is a mirage and can't happen if it's going to be used by more than a single project.
Are we GUI yet?
