Your post is very naive. In the UK, some universities are so dependent now on foreign students paying high fees to break even, that it has been widely reported in the media. And in a few EU countries, polytechnics have been upgraded to university status (at least in their English-language names) in order to attract fee-paying students from the developing world. Finnish polytechnics, for example, run whole marketing campaigns in the Indian Subcontinent in order to get people to come and pay those sweet, sweet foreign-student fees.
Are Polytechnics not considered universities in Europe? RPI (Rensalear Polytechnic Institute) or CalPoly (California Polytechnic Institute) for example in the US are just normal universities, usually with more of a technical, engineering focused. But they are essentially the same "level" as a university.
In Finland, the institutions that now call themselves “Universities of Applied Science” in English for marketing reasons, are still known in Finnish as ammatikorkeakoulu “tertiary professional-training institutions” and this is a rung below actual universities (yliopisto) in terms of both quality of education and social prestige.
It's surprising because so many countries have taken billions from international students, mostly from one country, and is now blaming the the students for having parted with their money.
British universities do the same marketing. Seen it there.
The problem in the UK has been ridiculous the expansion of universities. if we shut at least half of them down, reduced some of the others in size, there would be a lot more money for the rest.
AI teaching is the opposite of what the best universities do, which is things like small group tutorials on top of face to face lectures.
They often get donations in return for naming buildings after people. They can name other things after people instead - organisations with the university.
The original article is about a UK university. Cashflow and revenue generation is a very important topic for UK universities. They have copied the approaches of US universities, and in many cases have created overseas campuses when they have some name recognition. See https://en.wikipedia.org/wiki/International_branch_campus for examples.
Plenty of US colleges and universities are primarily about education and/or research, even today. Far from all, to be sure—and some are primarily about connections and the school name (primarily Ivies), rather than any of the above.
None of which exist without making sure the organization isa bout sufficient cashflow from government, students, and industry.
I shouldn't say it so simply, it might result in attempts to convolute it to distract from the fact that bureaucracies serve to maintain revenue/income and grow it.
There's a big difference between "the organization needs to maintain a sufficient cashflow" and "the organization is primarily concerned with its financial status, at the expense of its putative mission".
TIL about UBlock on IOS. Is it good? I've just switched to IOS and have been trying the free version of 1Blocker but it wasn't removing stuff like pop ups.
I feel like everyone has the wrong idea about web components. Perhaps it's in the name. There's no "WebComponent" class on the window object, but there is an HTMLElement you can extend and a `window.customElement` registry for tagName invocation, a thing called a shadow root, and so forth. Those are all things that I am glad exist. If I thought of them grouped together as "Web Components" and compared that to components in frontend JavaScript frameworks then yeah, I guess I'd be disappointed. Otherwise, the people who say they "don't use" web components are being as unreasonable as it would be to say to not use the `<video>` element because it doesn't support all the things that `<canvas>` does with some 3rd party library for compositing.
Custom elements are awesome for small things that don't need to appear in an SSR context (assuming you're using shadow DOMs). No, they don't support composable stylesheets, whatever those even are, but seriously, who really needs them? If what you are doing is complicated enough that the browser's native APIs are too obtuse then yeah go for something like React or Svelte. No matter what, there's going to be something that someone's JavaScript library is going to do better than the browser. I'd use uncommon browser and language features if they made sense for a task.
The `<template>` and `<slot>` elements are really dopey and hard to understand. That's where something like React or Svelte comes in. Nobody would use either of those libraries if they didn't have better templating than the browser.
> I feel like everyone has the wrong idea about web components.
What is the idea behind Web Components? Does anyone have an idea of what they are, should be, and where they are going? They've been around for 10 years now. Google has poured literally millions of dollars into trying to make them happen.
If people still "have the wrong idea about web components", it's a testament to their failure.
> Otherwise, the people who say they "don't use" web components are being as unreasonable as it would be to say to not use the `<video>` element because it doesn't support all the things that `<canvas>` does with some 3rd party library for compositing.
Well, no. People who say "don't use web components" are very much aware about the fact that web components:
- at the core are 4 different standards. One of them is already fully deprecated (HTML Imports). The other one already has a deprecated and removed version (Custom Elements v0)
- introduced so many problems by simply existing that Google (primarily Google) has been pumping out literally thousands of pages of new specs just to fix the problems that web components created.
- have an API that is both too high level and too low level to be usable.
It's too low level and too verbose, so after several years of promoting them as "the be all end all components for the web" the narrative shifted to "it's just an API for library authors, you're not supposed to use them by hand". It's unusable at any significant scale. Google's own AMP has switched to using Preact to author their components because they couldn't bear it anymore.
It's too high level, so in the 10 years of its existence there are hardly any libs and frameworks that have adopted Web Components as the foundation. And even the new ones tend to skip Web Components. Well, most libs and frameworks can compile to Web Components, and can consume Web Components. But hardly any framework actually uses them as a foundation.
Well, I've linked to the dozens of problems that they introduce, so no wonder.
- "Custom elements are awesome for small things that don't need to appear in an SSR context"
that don't need an SSR context, that don't need a11y, that don't need to split SVGs, that don't need...
Too many "don't needs" for a tech that has seen millions of dollars poured into it, and 10 years of development. After all that it's still "it's awesome for small things". Only for small things.
Meanwhile, w3c has unveiled its own design system here: https://design-system.w3.org It uses SASS and it uses a third-party library to, quote, "enhance a <select> into and accessible auto-complete via JavaScript."
Imagine if millions of dollars and countless man-hours poured into Web Components were instead directed to make CSS better, to enhance the crappy built-in controls etc.? Oh, you'd have a better web, and not an "awesome for small things with dozens of problems".
> No matter what, there's going to be something that someone's JavaScript library is going to do better than the browser.
Ah yes. I remember someone calling jQuery "the disappearing framework". Because its eventual goal is to be fully replaced by browser APIs.
It looks like Web Components' motto is "there's always someone doing stuff better in Javascript, so why bother, let's be crap".
> Nobody would use either of those libraries if they didn't have better templating than the browser.
Nope. People are using them not because of templating alone.
> If people still "have the wrong idea about web components", it's a testament to their failure.
In a way, that's exactly my point. I don't get the need to view the related technologies as "web components". It's a branding error made to look niche features sound like something more than they actually are.
> It's unusable at any significant scale.
It's a fallacy to denigrate anything on the basis of scale, because not everything has to be at "scale". That doesn't have to be the job of web APIs. These tools exist to render things on web pages; they weren't intended to satisfy the needs of Google and their wannabes, as much as Google themselves believe otherwise (in seeing themselves as the arbiters of the web).
> Google's own AMP has switched to using Preact to author their components because they couldn't bear it anymore.
This seems like speculation. People switch projects to their framework of choice for any number of reasons, many of them not necessarily being objective. Preact is way cooler than custom elements, so of course there will be a bias towards using it no matter how useful or not useful custom elements are.
> Too many "don't needs" for a tech that has seen millions of dollars poured into it, and 10 years of development. After all that it's still "it's awesome for small things". Only for small things.
Again, not necessarily anyone's problem. Lifecycle hooks, templates, and shadow DOMs are missing features in a system where nodes can be inserted dynamically. Are they critical? No. Do they "scale"? Maybe not, but that's really not an argument against them being in existence. Frankly, I don't care if someone mistakenly thought they were a multi-million dollar idea.
> Well, I've linked to the dozens of problems that they introduce, so no wonder.
All of those arguments come from the premise that separate APIs are supposed to form something coherent. For one, I don't know how Chrome-only features are somehow supposed to be the fault of web components.
Custom elements are as inaccessible by default as non-semantic HTML elements. The use of ARIA attributes is pretty common for elements that are not custom.
If SSR is a problem then don't use shadow DOMs. If that's irreconcilable then use React or something that can scope CSS. Otherwise, a custom element can receive a role like anything else no matter what context it's rendered in.
> Nope. People are using them not because of templating alone.
That's not what I said. Templating isn't all that React and Vue do, but it's a make or break feature. Few would care about component lifecycle, reactivity, and other features if they had to verbosely hook into elements using regular JavaScript syntax. In particular, nobody would use Vue and especially Svelte if they had no templating. These "frameworks" are primarily templating libraries. React would have never taken off if there wasn't JSX.
> It looks like Web Components' motto is "there's always someone doing stuff better in Javascript, so why bother, let's be crap".
What exactly is the argument against that? HTML is crap, and for good reason. Browsers could have essentially become something along the lines of Adobe Flash, but instead they chose to be adequate for rendering pages. (some notable exceptions notwithstanding) Likewise, whatever "web components" are supposed to be, they add a few niche features to an existing system. Expecting bureaucratic web consortia to be wanting or able to compete with the likes of React is a path to disappointment.
> It's a fallacy to denigrate anything on the basis of scale, because not everything has to be at "scale".
Scale is "anything beyond the simplest of components".
> That doesn't have to be the job of web APIs. These tools exist to render things on web pages
Yes, that is exactly the job of Web APIs, and they are horrible even at rendering things on web pages. You'd have to search really far and really wide to find APIs that are as slow and as inefficient at putting pixels on screen like Web APIs.
But even beyond that, web components are a horrendously bad, overly verbose API that is unsuitable for, you guessed it, scale. Write a few of them by hand, and off you are looking for a framework or library.
> > Google's own AMP has switched to using Preact to author their components because they couldn't bear it anymore.
The main issue was that handling attribute/children mutation got too complex when implemented manually instead of relying on diffing.
--- end quote ---
This is what I mean when I'm talking about scale.
> Again, not necessarily anyone's problem.
It is, ultimately, the problem of the people who will be using this tech.
> All of those arguments come from the premise that separate APIs are supposed to form something coherent.
No. All those arguments come from the fact that Web Components break all those things, are broken for all those things, and keep breaking a lot of other things despite everything that's poured into them.
And you can't just hand waive and dismiss all concerns with "who cares".
You have your project and someone brings a Web Component into it? Oops, your project can no longer be SSR'ed.
You have your project and someone brings a custom field into it implemented with Shadow DOM? Ooops, suddently your project has an inaccessible field.
And so on, and so on.
> The use of ARIA attributes is pretty common for elements that are not custom.
ARIA attributes do not cross shadow dom boundary. Web Components will break accessibility instantly just by virtue of existing (if they use shadow DOM).
> If SSR is a problem then don't use shadow DOMs.
Ah yes. "You're holding it wrong". That's the problem with web components: they break in so many common scenarios, that any other tech would be laughed out of the room. And yet, here we are, with people valiantly defending them.
> What exactly is the argument against that? HTML is crap, and for good reason.
HTML is crap, so let's add even more crap to it and be content with this crap?
> Likewise, whatever "web components" are supposed to be, they add a few niche features to an existing system.
That's the problem. The only features they add are "some niche features". The cost of developing, supporting and integrating these features has far surpassed any potential usefulness of these features. And their primary use case, still, is "yeah, maybe as some small dumb components if you don't use shadow dom, if you don't care about SSR, if you don't care about <a dozen other things that developers do care about>".
So what exactly is the idea of web component that everyone misunderstands?
reply