But niches within YouTube can be disrupted. We've seen it with short form (TikTok etc), music (Spotify etc). We see it with specific niches of content creators (nebula etc). It's happened with livestreams.
I'm bad at predicting future, but could imagine niches like "publicly funded content" from e.g. EU public broadcasters moving away (e.g. NPOstart in NL) because of privacy issues or because they legally can't monetize their content anyway. Maybe university lectures? Or sports video? Game reviews by a specialized platform by steam? Video between 4 and 10 minutes? Podcast videos?
So YouTube as a whole will stay, but it can be chipped away at. Some chips may prove in themselves a small, but still good business model.
I agree with this. For example some tech creators are using peertube or similar.
University Lectures now posting in other websites as backup and people that do courses also have them in their website. What I think what will happen it's that YouTube will still be used for discovery to drive the traffic to these other sites until people finally migrate to the smaller ones.
Another main issue is how large (deep and wide) this "supply chain" is in some communities. JavaScript and python notable for their giant reliance on libs.
If I compare a typical Rust project, with a same JavaScript one, JavaScript project itself often has magnitudes more direct dependencies (wide supply chain?). The rust tool will have three or four, the JavaScript over ten, sometimes ten alone to help with just building the typescript in dev. Worsened by the JavaScript dependencies own deps (and theirs, and theirs, all the way down to is_array or left_pad). Easily getting in the hundreds. In rust, that graph will list maybe ten more. Or, with some complex libraries, a total of several tens.
This attitude difference is also clear in Python community. Where the knee-jerk reaction is to add an import, rather than think it through, maybe copy paste a file, and in any case, being very conservative. Do we really need colors in the terminal output? We do? Can we not just create a file with some constants that hold the four ANSI escape codes instead?
I'm trying to argue that there's also an important cultural problem with supply chain attacks to be considered.
> [...] python notable for their giant reliance on libs.
I object. You can get a full-blown web app rolling with Django alone. Here's it's list of external dependencies, including transitive: asgiref, sqlparse, tzdata. (I guess you can also count jQuery, if you're using the _builtin_ admin interface.)
The standard library is slowly swallowing the most important libraries & tools in the ecosystem, such as json or venv. What was once a giant yield-hack to get green threads / async, is now a part of the language. The language itself is conservative in what new features it accepts, 20yro Python code still reads like Python.
Sure, I've worked on a Django codebase with 130 transitive dependencies. But it's 7yro and powers an entire business. A "hello world" app in Express has 150, for Vue it's 550.
> If I compare a typical Rust project, with a same JavaScript one, JavaScript project itself often has magnitudes more direct dependencies (wide supply chain?).
This has more to do with the popularity of a language than anything else, I think. Though the fact that Python and JS are used as "entry level" languages probably encourages some of these "lazy" libraries cough cough left-pad cough cough.
Many of the abstractions and nextjs tools do things that my OS does better, cleaner and more predictable too.
I suppose the overly complicated ENV/.env loading hierarchy is (partly) needed because Windows doesn't (didn't?) have ENV vars. Same for inotify, port detection, thread management: *nix does it well, consistent ish. But when you want an interface or feature that works on both *nix and windows, in the same way, you'll end up with next.js alike piles of reinvented wheels and abstractions (that in the end are always leaking anyway)
Because it's objects, not text. It "scales" a lot better in your brain because in general you need to know a lot less than in bash. No more awkward sed and awk scripts, manipulating objects is a breeze. Awkward syntax at places where you have to create an object from scratch is a fair price.
yeah | it's | so | much | better | with | bash | tr | cut -d' ' -t5 | jq .entry[].text | sed -i s/who/evenknows/g
Anyone who has ever maintained a semi complex set of bash invocations and pipes knows it's a fragile incantation that breaks anytime you look at it funny, or something in your chain produces unexpected output.
Powershell, while absolutely horrible to read and only slightly less horrible to write (hey look, proper auto completion instead of trying to cut on the 4th, wait no sorry 5th, ah fuck it's the 6th there's an invisible space) at least produces consistent and reproductible results.
No, your python script doesn't count, it makes me do a pip install requests. Oh, sorry, pip can't be used like that, gotta run apt instill python3-pip or my whole system breaks.
> because Windows doesn't (didn't?) have ENV vars.
As long as I can remember in my career, Windows had environment variables. So that's at least 25 years. It's both available to view/edit in the GUI and at the prompt.
Damn, I didn't know someone could be so clueless about Windows or operating system history in general. What the hell do they teach in computer science these days
Windows has had envvars since before Linux existed. It also has FindFirstChangeNotification (or ReadDirectoryChangesW if you hate yourself) since before inotify existed, etc.
Windows has pretty much everything you can dream of (although sometimes in the form of complete abominations), it's just that the people employed by Vercel don't give a shit about using native APIs well, and will map everything towards a UNIX-ish way of doing things.
My point was not that windows doesn't have Inotify (or the other stuff) but that it does it different to Unix.
Or, if you insist, that Unix is inconsistent with how windows does it.
Which is what those wrappers and abstractions do: they expose a single api to e.g. detect file changes that works with inotify, readdirectorychanges, etc.
This seems to ignore the possibility of Windows having done them in a UNIX-ish way to begin with, which would be infinitely better than what Microsoft came up with.
Windows had most of these APIs _before_ UNIX ever dreamed them up. You can jerk yourself off about the superiority of io_uring all day long, but it had been in Win32 for 15 years prior, and has kept compatibility throughout. I can't promise that io_uring will still be in the kernel by 2040.
So, yeah, speaking in hindsight is really easy.
PS: no, the UNIX way is also shit, just in a different way.
I've found that listening and asking questions is the key to accepting other people's architectural choices.
Why do they insist on A over B? What trade offs were considered? Why are these trade offs less threatening than other trade offs? What previous failures or difficulties led them to put such weight on this problem over others?
Sometimes it's just ego or stubbornness or routine¹. That can and should be dismissed IMO. Even if through these misguided reasons they choose the "right" architecture, even if the outcome turns out good, that way of working is toxic and bad for any long term project.
More often, there are good, solid reasons behind choices, though. Backed with data or science even. Things I didn't know, or see different, or have data and scientific papers for that "prove" the exact opposite. But it doesn't matter that much, as long as we all understand what we are prioritizing, what the trade offs are and how we mitigate the risks of those trade offs, it's fine.
¹ The worst, IMO, is the "we've always done it like this" trench. An ego can be softened or taken off the team. But unwillingness to learn and change, instilled in team culture is an almost guaranteed recipe for disaster
> please keep in mind F-Droid is a volunteer-run community project.
To, me, that's the worrying part.
Not that it's ran by volunteers. But that all there's left between a full-on "tech monopoly" or hegemony, and a free internet, is small bands of underfunded volunteers.
Opposition to market dominance and monopolies by multibillion multinationals shouldn't just come from a few volunteers. If that's the case, just roll over and give up; the cause is lost. (As I've done, hence my defaitism)
Aside from that: it being "a volunteer ran community" shouldn't be put as an excuse for why it's in trouble/has poor UX/is hard to use/is behind/etc. It should be a killer feature. Something that makes it more resilient/better attuned/easier/earlier adopting/etc.
The EU governments should gradually start switching to open source solutions. New software projects should be open source by default and only closed if there is a real reason for it.
The EU is already home to many OS contributors and companies. I like the Red Hat approach where you are profitable, but with open source solutions.
It's great for governments because you get support, but it's much easier to compete, which reduces prices.
Smaller companies also give more of their money to open source. Bigger companies can always fork it and develop it internally and can therefore pressure devs to do work for less. Smaller companies have to rely on the projects to keep going and doing it all in house would be way too expensive for most.
> I like the Red Hat approach where you are profitable, but with open source solutions.
The Red Hat that was bought by IBM?
I agree with your goals, but the devil is in the methods. If we want governments to support open source, the appropriate method is probably a legislative requirement for an open source license + a requirement to fund the developer.
It seems like every other year I read a story about Munich switching to Linux. It keeps happening so evidently it's not sticking very well. Either there are usability or maintenance problems, or Microsoft's sales and lobbying is too effective.
It's interesting to me how people panicked about the idea that 23AndMe's bankruptcy implies that some unknown, untrusted third-party will have their genetic information, but people are also crowing at the idea that a company that has purchase history on all your smartphone apps (and their permissions, and app data backup) could be compelled by the government to divest that function to some unknown, untrusted third-party.
Is it not a big deal? Or do customers lack the choice?
If Apple had two lines of smartwatches, one for city/work crowd with the WiFi, Bright screen, NFC, powerful processor etc. but with tiny battery life. And another for hike/off-grid/travel/festival crowd without wifi, a slower, blander screen, slower hardware, less features but over a week)weeks on one charge.
It wouldn't fly and/or would be "one more SKU" to support with expensive software development.
They've seriously stuck themselves in a pickle with their WatchOS offering. They can't move away from touch-screen b/c they've committed to "being able to enter a PIN" from the device (so they can offer AND PROTECT on-watch payment capabilities).
They can't move away from touch-screen b/c they've duped all the uber's and door-dash's, and big-bank.com into writing "watch apps" that assume a touch screen.
The Garmin Fenix has the best response to this that I've seen so far, a "pinch-to-activate" touch screen on some of their watches with "enough" buttons (Up, Down, OK, Back, "light"). You can use the watch normally without fear of accidental activations and when you start up the map-type-stuff, it'll either auto-activate a twiddly touchscreen or you can "pinch to activate" (hold two diagonal buttons for 2-3 seconds) and then start messing with it (or are able to turn it off w/o issue).
They can't move away from bright color screens because then people can't have pictures of their kids on their watch, and at that point it's no longer an "Apple" product.
Apple Watch is multi-touch, if you hold two fingers on the face, it announces the time.
Which relates to the cost and battery life of the Apple Watch, it's a mainstream device that many people with varying disabilities can use. It has a full-fledged screen reader in its operating system, in addition to the development costs to support multiple interaction modalities, some will not be achievable with lower-powered, less specialized processors.
People can buy the second option from someone else, like RePebble.
Of course if they want to use it with an Apple phone, it will have artificial limitations[0]. That, rather than adding a product line that doesn't align with most of their market is what Apple should fix.
USB (abc, micro etc) are everywhere. Any house, hotel, office, glove box, has some lying around.
But when I forgot my Fitbit charger, I couldn't get one anywhere. The only option was a large electronics store where I could buy an entire new Fitbit. I didn't shove out €200 just to get hold of a charging cable.
The EU should quickly impose rules on waterproof chargers like they did with USB chargers. It will settle worldwide just as fast as the USB enforced standard.
that's needlessly pedantic. the GP is noting that it's built into node's standard library, which might discourage you from installing a library or copying a table of ansi escapes.
I very much dislike such features in a runtime or app.
The "proper" place to solve this, is in the OS. Where it has been solved, including all the inevitable corner cases, already.
Why reinvent this wheel, adding complexity, bug-surface, maintenance burden and whatnot to your project? What problem dies it solve that hasn't been solved by other people?
For years, I heard it's better to use cron, because the problem was already solved the right way(tm). My experience with cron has been about a dozen difficult fixes in production of cron not running / not with the right permission / errors lost without being logged / ... Changing / upgrading OSes became a problem. I since switched to a small node script with a basic scheduler in it, I had ZERO issues in 7 years. My devs happily add entries in the scheduler without bothering me. We even added consistency checks, asserts, scheduled one time execution tasks, ... and now multi server scheduling.
Deployments that need to configure OSes in a particular way are difficult (the existence of docker, kubernetes, snap are symptoms of this difficulty). It requires a high level of privilege to do so. Upgrades and rollbacks are challenging, if ever done. OSes sometimes don't provide solution when we go beyond one hardware.
If "npm start" can restrain the permissions to what it should be for the given version of the code, I will use it and I'll be happy.
If cron is broken for you, than the logic solution would be to replace it with something that does work for you. But do so at the right place and abstraction. That's hardly ever the runtime or in the app.
Do One Thing (and do it well).
A special domain specific scheduler microservice? One of the many Cron replacements? One of the many "SaaS cron"? Systemd?
This problem has been solved. Corner cases ironed out. Free to use.
Same for ENV var as configurations (as opposed to inventing yet another config solution), file permissions, monitoring, networking, sandboxing, chrooting etc. the amount of broken, insecure or just inefficient DIY versions of stuff handled in an OS I've had to work around is mind boggling. Causing a trice a loss: the time taken to build it. That time not spent on the business domain, and the time to them maintain and debug it for the next fifteen years.
This is a nice idea, but what do you do when the OS tooling is not that good? macOS is a good example, they have OS level sandboxing [0], but the docs are practically nonexistent and the only way to figure it out is to read a bunch of blog posts by people who struggled with it before you. Baking it into Node means that at least theoretically you get the same thing out of the box on every OS.
Except, the OS hasn’t actually solved it. Any program you can run can access arbitrary files of yours and it’s quite difficult to actually control that access even if you want to limit the blast radius of your own software. Seriously - what software works you use? Go write eBPF to act as a mini adhoc hypervisor to enforce difficult to write policies via seLinux? That only even works if you’re the admin of the machine which isn’t necessarily the same person writing the software they want to code defensively.
Also modern software security is really taking a look at strengthening software against supply chain vulnerabilities. That looks less like traditional OS and more like a capabilities model where you start with a set of limited permissions and even within the same address space it’s difficult to obtain a new permission unless your explicitly given a handle to it (arguably that’s how all permissions should work top to bottom).
This is what process' mount namespace is for. Various container implementations use it. With modern Linux you don't even need a third-party container manager, systemd-nspawn comes with the system and should be able to do that.
The problem with the "solutions" s.a. the one in Node.js is that Node.js doesn't get to decide how eg. domain names are resolved. So, it's easy to fool it to allow or to deny access to something the author didn't intend for it.
Historically, we (the computer users) decided that operating system is responsible for domain name resolution. It's possible that today it does that poorly, but, in principle we want the world to be such that OS takes care of DNS, not individual programs. From administrator perspective, it spares the administrator the need to learn the capabilities, the limitations and the syntax of every program that wants to do something like that.
It's actually very similar thing with logs. From administrator perspective, logs should always go to stderr. Programs that try to circumvent this rule and put them in separate files / send them into sockets etc. are a real sore spot of any administrator who'd spent some times doing his/her job.
Same thing with namespacing. Just let Linux do its job. No need for this duplication in individual programs / runtimes.
The part you're overlooking is how easy a vulnerability within the application can escape & do damage. Such vulnerabilities could either be someone hacking the application or a supply chain vulnerability. Namespacing & similar techniques limit the blast radius of a compromised process on the rest of the OS, but do nothing to limit the blast radius of a compromise on the assets accessible by the process. For example, if I have a document editor and want to open documents on my OS, namespacing doesn't help - the document editor traditionally needs the ability to open and list files.
Comprehensive capability protection is needed so that you actually need to have a token to do something privileged even within the process. What that looks like is the OS shows a file dialog and gives the process a descriptor (with a random ID) to that file. Similarly, network I/O would need a privileged descriptor the OS gives the application. Then even if you compromise the process you have to fully compromise the process to find the token to do privileged actions with.
How would you do this in a native fashion? I mean I believe you (chroot jail I think it was?), but not everyone runs on *nix systems, and perhaps more importantly, not all Node developers know or want to know much about the underlying operating system. Which is to their detriment, of course, but a lot of people are "stuck" in their ecosystem. This is arguably even worse in the Java ecosystem, but it's considered a selling point (write once run anywhere on the JVM, etc).
I dunno how GP would do it, but I run a service (web app written in Go) under a specific user and lock-down what that user can read and write on the FS.
Just locally, that seems like a huge pain in the ass... At least you can suggest containers which has an easier interface around it generally speaking.
> What problem does it solve that hasn't been solved by other people?
nothing. Except for "portability" arguments perhaps.
Java has had security managers and access restrictions built in but it never worked very well (and is quite cumbersome to use in practice). And there's been lots of bypasses over the years, and patch work fixes etc.
Tbh, the OS is the only real security you could trust, as it's as low a level as any application would typically go (unless you end up in driver/kernal space, like those anti-virus/anti-cheat/crowdstrike apps).
But platform vendors always want to NIH and make their platform slightly easier and still present the similar level of security.
This is my thought on using dotenv libraries. The app shouldn’t have to load environment variables, only read them. Using a dotenv function/plugin like in omz is far more preferable.
The argument often heard though is 'but windows'. Though if windows lacks env (or Cron, or chroot, etc) the solution would be to either move to an env that does support it, or introduce some tooling only for the windows users.
Not build a complex, hierarchical directory scanner that finds and merges all sorts of .env .env.local and whatnots.
On dev I often do use .ENV files, but use zenv or a loadenv tool or script outside of the projects codebase to then load these files into the env.
In a team setting, it can be extremely helpful to have env/config loading logic built into the repo itself. It does not mean it has be loaded by the application process, but it can be part of the surrounding tooling that is part of your codebase.
Yes, that's indeed the right place, IMO: ephemeral tooling that leverages, or simplifies OS features.
Tooling such as xenv, a tiny bash script, a makefile etc. that devs can then replace with their own if they wish (A windows user may need something different from my zsh built-in). That isn't present at all in prod, or when running in k8s or docker compose locally.
A few years ago, I surfaced a security bug in an integrated .env loader that partly leveraged a lib and partly was DIY/NIH code. A dev built something that would traverse up and down file hierarchies to search for .env.* files and merge them runtime and reload the app if it found a new or changed one. Useful for dev. But on prod, uploading a .env.png would end up in in a temp dir that this homebuilt monstrosity would then pick up. Yes, any internet user could inject most configuration into our production app.
Because a developer built a solution to a problem that was long solved, if only he had researched the problem a bit longer.
We "fixed" it by ripping out thousands of LOCs, a dependency (with dependencies) and putting one line back in the READMe: use an env loader like ....
Turned out that not only was it a security issue, it was an inotify hogger, memory hog, and io bottleneck on boot. We could downsize some production infra afterwards.
Yes, the dev built bad software. But, again, the problem wasn't that quality, but the fact it was considered to be built in the first place.
How would you solve this at the OS level across Linux, macOS and Windows?
I've been trying to figure out a good way to do this for my Python projects for a couple of years now. I don't yet trust any of the solutions I've come up with - they are inconsistent with each other and feel very ironed to me making mistakes due to their inherent complexity and lack of documentation that I trust.
If something is solved at the OS level it probably needs to vary by OS. Just like how an application layer solution to parsing data must vary slightly between nodeJS and java.
For a solution to be truly generic to OS, it's likely better done at the network level. Like by putting your traffic through a proxy that only allows traffic to certain whitelisted / blacklisted destinations.
The proxy thing solved for betroth access but not for filesystem access.
With proxies the challenge becomes how to ensure the untrusted code in the programming language only accesses the network via the proxy. Outside of containers and iptables I haven't seen a way to do that.
I guess my point was that we have different OS's precisely because people want to do things in different ways. So we can't have generic ways to do them.
OS generic filesystem permissions would be like a OS generic UI framework, it's inherently very difficult and ultimately limited.
Separately, I totally sympathise with you that the OS solutions to networking and filesystem permissions are painful to work with. Even though I'm reasonably comfortable with rwx permissions, I'd never allow untrusted code on a machine which also had sensitive files on it. But I think we should fix this by coming up with better OS tooling, not by moving the problem to the app layer.
But you are asking the developer to make these restrictions... Node.js is the user-space program, controlled by developers. Ops shouldn't (need to) deal with it.
> Why reinvent this wheel, adding complexity, bug-surface, maintenance burden and whatnot to your project? What problem dies it solve that hasn't been solved by other people?
Whilst this is (effectively) an Argument From Authority, what makes you assume the Node team haven't considered this? They're famously conservative about implementing anything that adds indirection or layers. And they're very *nix focused.
I am pretty sure they've considered "I could just run this script under a different user"
(I would assume it's there because the Permissions API covers many resources and side effects, some of which would be difficult to reproduce across OSes, but I don't have the original proposal to look at and verify)
OS level checks will inevitably work differently on different OSes and different versions. Having a check like this in the app binary itself means you can have a standard implementation regardless of the OS running the app.
I often hear similar arguments for or against database level security rules. Row level security, for example, is a really powerful feature and in my opinion is worth using when you can. Using RLS doesn't mean you skip checking authorization rules at the API level though, you check on author in your business logic _and_ in the database.
OK, I'll bite. Do you think Node.js implementation is aware of DNS search path? (My guess would be that it's unaware with 90% certainty).
If you don't know what DNS search path is, here's my informal explanation: your application may request to connect to foo.bar.com or to bar.com, and if your /etc/resolv.conf contains "search foo", then these two requests are the same request.
This is an important feature of corporate networks because it allows macro administrative actions, temporary failover solutions etc. But, if a program is configured with Node.js without understanding this feature, none of these operations will be possible.
From my perspective, as someone who has to perform ops / administrative tasks, I would hate it if someone used these Node.js features. They would get in the way and cause problems because they are toys, not a real thing. Application cannot deal with DNS in a non-toy way. It's the task for the system.
Oh I'd be very surprised if Node's implementation would handle such situations.
I also wouldn't really expect it to though, that depends heavily on the environment the app is run in, and if the deployment environment intentionally includes resolv.conf or similar I'd expect the developer(s) to either use a more elegant solution or configure Node to expect those resolutions.
Putting network restrictions in the application layer also causes awkward issues for the org structures of many enterprises.
For example, the problem of "one micro service won't connect to another" was traditionally an ops / environments / SRE problem. But now the app development team has to get involved, just in case someone's used one of these new restrictions. Or those other teams need to learn about node.
This is non consensual devops being forced upon us, where everyone has to learn everything.
My experience with DevOps has been they know a lot about deploying and securing Java, or Kotlin, or Python but they know scant about node js and its tooling and often refuse to learn the ecosystem
This leads to the node js teams to have to learn DevOps anyway because the DevOps teams do a subpar job with it otherwise.
Same with doing frontend builds and such. In other languages I’ve noticed (particularly Java / Kotlin) DevOps teams maintain the build tools and configurations around it for the most part. The same has not been true for the node ecosystem, whether it’s backend or Frontend
How many apps do you think has properly set user and access rights only to what they need? In production? If even that percentage was high, how about developers machines, people that run some node scripts which might import whoever knows what? It is possible to have it running safely, but I doubt it's a high percentage of people. Feature like this can increase that percentage
Wouldn't "simplifying" or even awareness of the existence of such OS features be a much better solution than re-building it in a runtime?
If an existing feature is used too little, then I'm not sure if rebuilding it elsewhere is the proper solution. Unless the existing feature is in a fundamentally wrong place. Which this isn't: the OS is probably the only right place for access permissions.
An obvious solution would be education. Teach people how to use docker mounts right. How to use chroot. How Linux' chmod and chown work. Or provide modern and usable alternatives to those.
Your point about OS caring about this stuff is solid, but saying a solution is education seems a little bit naive. How are you going to teach people? Or who is going to do that? If node runtime makes its use safer by implementing this, that helps a lot of people. To say people need to learn themselves helps noone.
Genuine question, as I've not invested much into understanding this. What features of the OS would enable these kinds of network restrictions? Basic googling/asking AI points me in the direction of things that seem a lot more difficult in general, unless using something like AppArmor, at which point it seems like you're not quite in OS land anymore.
Nope, they don't add. They confuse. From administrator perspective, it sucks when the same conceptual configuration can be performed in many different places using different configuration languages, governed by different upgrade policies, owned by unintended users, logged into unintended places.
Also, I'd bet my monthly salary on that Node.js implementation of this feature doesn't take into account multiple possible corner cases and configurations that are possible on the system level. In particular, I'd be concerned about DNS search path, which I think would be hard to get right in userspace application. Also, what happens with /etc/hosts?
From administrator perspective I don't want applications to add another (broken) level of manipulating of discovery protocol. It usually very time consuming and labor intensive task to figure out why two applications which are meant to connect aren't. If you keep randomly adding more variables to this problem, you are guaranteed to have a bad time.
Oh, so we are launching attacks on personality now? Well. To start with: you aren't an admin at all, and you don't even understand the work admins do. Why are you getting into an argument that is clearly above your abilities?
And, a side note: you also don't understand English all that well. "Confusion" is present in any situation that needs analysis. What's different is the degree to which it's present. Increasing confusion makes analysis more costly in terms of resources and potential for error. The "solution" offered by Node.js offers to increase confusion, but offers nothing in return. I.e. it creates waste. Or, put differently, is useless, and, by extension, harmful, because you cannot take resources and do nothing and still be neutral: if you waste resources while produce nothing of value, you limit resources to other actors who could potentially make a better use of them.
It's similar to the refrain "they shouldn't add that feature to language X, people should just use language Y instead" ("just" when said by software developers is normally a red flag IME)
Not necessarily, in selinux for example you would configure a domain for the "main process" which can transition into a lower permission domain for "app" code.
It certainly did. It was the OG of "no-code" or "low-code".
But like no-code or low-code, the niche in which it's useful to a business is limited. I commonly say that if software (esp FLOSS) serves even only one person well, it's a success. By that criteria, it was massively successfull.
But 27 years later, we are still mostly writing "html" (or jxl, or whatever todays frontendframework has come up with) by "hand". Or writing code that churns out this HTML for us. And not dragging around stuff in Dreamweaver.
Some figma-export will serve niches, some of which I probably cannot imagine even. Prototyping, one-offs, cousin-erik-building-james-craft-brewery-site, etc. But even combined with generative- or transformative AI, it won't serve as the source for UI "code".
If by “people” you mean “developers”, then yes you’re right. But I don’t think anyone else ever really cared.
The problem with Dreamweaver is that you still needed a developer to upload and run the site. And back then, you couldn’t run single page applications (web stacks hadn’t evolved that far yet), so still needed developers to write the backend.
Thus there wasn’t a huge amount to gain in using Dreamweaver for the professional world.
AI has changed that in that it doesn’t have the same limitations as Dreamweaver. However, like yourself, I don’t think we’ll see AI replace developers. Or at least the current crop of LLMs still have a long way to go before they can be used without developer oversight.
Edit: also worth noting that Flash was everywhere back then too. So many web designers opted for Flash instead.
I actually do see developers being replaced by AI. But only certain roles and only after it solves the issues that e.g. Dreamweaver did not solve.
Building stuff from scratch is easy. AI can do it, dreamweaver could, that sweatshop worker on fiverr, newest junior hire, etc.
Maintaining legacy isn't. AI isn't there yet: at most it can replace existing with new, but it cannot "understand" context, history, The Reason Why Kevin Built This Weird Unintelligable Abstraction, or how the three different ways of validating an email are actually a business requirement.
Let alone building stuff that withstands the decay of real constraints and time.
I've been around long enough (30+ years software dev/engineer) to have seen this decay over and over and to know what works and what doesn't (It's a people issue, hardly a technical one).
I've never seen AI, that sweatshop worker on fiverr, newest junior hire, or any low- or no-code tool, amongst which Dreamweaver, churn out something that's easy to change, maintainable for months, years, decades.
There's software that gets a few hours a year of attention and keeps running, securely, performant. That can be picked up, changed or added to and deployed in hours. And there's software that will explode the moment you even glance at the files, let alone anyone fixing, updating, or g*d forbid, adding features to.
AI generated stuff almost exclusively falls in the last category. And we don't have anything AI around yet that can do this fixing, updating, adding features for us.
So currently it successfully replaces many of the code monkeys, fiverr-freelancers and junior devs churning out forever-greenfield-projects. But little else.
Sure, but I’ve seen plenty of senior co-workers deliver a pile of dynamite in Java and get a bonus for it, abandoning it to some other poor sod who will have to fix and maintain it. Managers who reward that behavior will probably be the ones who try to AI Everything, and it’ll probably work for just long enough to make all the devs redundant.
Yea. To be clear. With "senior" I did not mean "developers with over 16 months of experience" but developers that have failed spectacularly, several times, learned from that, and now strive to avoid these, and related mistakes.
A junior can never be that, due to lack of the experience. But too many long-term developers haven't failed, or haven't learned from these mistakes.
For example, about five years ago, I worked a few months with a 40+ years-of-experience software developer, who worked almost his entire life on one single product (in C++ and Java) in one company, solo. I was asked to assess if/how it was possible to get new people for this project because he was retiring.
Part of the code was marvelous and a true beauty. Other parts were horrors or inintelligable mess. He truly did not like Java (at first) so a giant part of the java codebase was there to make it look-and-feel somewhat like his (also non-standard) C++.
Ironically, the nice parts were those that were hardly touched or changed - infrastructure, boilerplate, etc. But the worst parts were those that needed frequent changes due to business demands or the ever changing outside world. He honestly never realized that there were patterns and systems (by now), to keep software manageable under real-world-demands and changes. That turned also to be the saving of this project: he loved "DDD" and "Design Patterns" (both he heard about, but never dove into), and implemented some core ideas in this project before handing it over: anti-corruption-layers, ports-adapters, dependency-injection, testing.
But niches within YouTube can be disrupted. We've seen it with short form (TikTok etc), music (Spotify etc). We see it with specific niches of content creators (nebula etc). It's happened with livestreams.
I'm bad at predicting future, but could imagine niches like "publicly funded content" from e.g. EU public broadcasters moving away (e.g. NPOstart in NL) because of privacy issues or because they legally can't monetize their content anyway. Maybe university lectures? Or sports video? Game reviews by a specialized platform by steam? Video between 4 and 10 minutes? Podcast videos?
So YouTube as a whole will stay, but it can be chipped away at. Some chips may prove in themselves a small, but still good business model.
reply