> My contrary opinion is that the actually important feature of the web is the URL, and the important feature of the browser is that it provides a sandboxed platform for running untrusted code without a builtin "walled garden moral police".
Flash tried to do this 15-20 years ago. Flash was basically "here's a canvas, do whatever you want within reason". It had its use cases back then but the general web vastly preferred good old HTML and eventually CSS and JS.
There's a lot of value in having constraints, especially when those constraints (HTML) are specifically designed for displaying documents.
Flash had several problems that should have been addressed differently. Among others:
- it was owned and controlled by a single company and thus a target for other companies instead of other companies helping to improve it
- that single company was unable or unwilling to fix security holes in the sandbox and browser makers eventually got fed up with that
- while there were some ways to interact with the underlying browser environment, ultimately a Flash instance lived in its own little bubble, creating usability problems
Putting the HTML+CSS layout engine into a separate module doesn't mean that it wouldn't remain the standard way of doing document-layouts on the web, it would just mean that higher-level solutions wouldn't need to use hacks and workarounds to map their concepts to HTML+CSS (same way as Javascript had to be used as a less-than-perfect compile target before WASM because it was the only option to run code in a browser).
Those were all problems but none of them had any real bearing on the general population avoiding it for general sites.
The thing is, most people don't want a blank canvas to go nuts with for the general use case. It's too complicated. Suddenly you need to learn entire SDKs and pull in many dependencies just to render text on the screen.
The reason HTML and the web was so well accepted back in the day was all you had to learn were a few HTML tags, a couple of properties and then drop it onto a Geocities site and you were good to go. It was something you can do and see real progress on in 10 minutes with very little background knowledge.
Compare that to now where if you wanted to be a "trendy front-end dev" you would probably reach for Vue / React + Webpack* and go SPA style for all of the sites you make because you learned something and now you want to apply it everywhere. Meanwhile to serve a document such as a blog post, you just went from having 15 HTML tags in a single HTML file and some CSS to pulling megabytes of Javascript sprawled across hundreds of dependencies and now you have build tools, an entire runtime environment (Node) and are using APIs that don't exactly match up with HTML exactly, and then your entire site isn't even crawlable by search engines unless you introduce even more complexity to do server side rendering and before you know it, you're dealing with something that's even more complicated than Flash was back in the day.
* I personally use Webpack to handle my assets too, but I don't write SPAs for sites that are document based (which tbh are most sites).
> Are you kidding me? Flash was an absurdly popular platform. Careers were launched on Newgrounds!
I'm not saying it wasn't popular, but what do you think the percent spread was between sites that were fully driven by Flash vs not Flash?
I don't have the stats in front of me, but I would guess it was probably 2% Flash vs 98% non-Flash. Now, a lot of sites had sprinkles of Flash but very few sites in the grand scheme of things were solely rendered with Flash. Part of the 2% were sites like 2advanced studios.
> very few sites in the grand scheme of things were solely rendered with Flash
...yeah, because that's not what Flash was about. Flash was an application platform (ok, so more like an Animation platform) first and foremost. Why would anyone run their whole site in flash? It wasn't the right tool for that job.
> Flash was an application platform (ok, so more like an Animation platform) first and foremost. Why would anyone run their whole site in flash? It wasn't the right tool for that job.
And this is exactly what I'm trying to say.
Back in the day you would very likely reach for Flash if you wanted to build an FTP client that ran in a browser. Totally reasonable use case because that's a highly interactive app that doesn't really follow the request / response style of a document style page. But you likely wouldn't reach for Flash to build some type of site that presented data in a document style (pretty much the general use case of what a website outputs).
But if you fast forward to today's technology, some front end developers are bringing in the complexity of creating SPA style applications that are primarily rendered with JS for everything -- even document style websites like a personal blog and the original comment I replied to is hinting they want to remove constraints from browsers to give us more of a FFA style of doing whatever we want to render pages. I was just saying that model didn't really take off for the general use case with Flash decades ago.
Fortunately we still live in a time where web developers can choose what they want to do, but browsers shouldn't change the concept of being something that renders HTML that is optionally combined with other things like CSS, fonts, JS and images.
but most sites had some flash on their site. just like the previous person said: flash was never intended to replace the website entirely - flash was intended to supplement it. and that need went away with html5/css3, which is why it was deprecated as the insecure behemoth it was.
Yet people did this all the time (2advanced, HomestarRunner, etc) because the web as an application (a product) was served particularly well by an application platform.
But for every 2advanced studios there were tens of thousands of people not using Flash as their entire site.
If people really wanted a no constraints platform to build any UI they want with a blank slate then web development as we know it today would be a completely different environment.
Instead, 20 years later, we're still trucking along with HTML as being the primary focus, and everything else can be loaded as needed.
You can build some pretty amazing things today with a combination of HTML, CSS, JS, fonts and websockets. But at the same time, if you don't need an application and just want to serve a HN style site, you can render HTML with a bit of CSS and everything works well. To me, that's one hell of a success story.
> the general population avoiding it for general sites
I'm not sure that happened. My friends and I got on MSN Messenger and shared flash sites all the time. Kongregate and similar gaming sites were part of it, but so was YouTube, and so were greeting card sites, ESPN, various other news sites and many, many others.
At least from my POV, maybe a few people hanging out places like here didn't like flash, but the general population had no problems with it until Steve Jobs did his best to kill it. Even then, people not on iPods/Pads/Phones didn't seem to have any problems with it. AFIK, the fast majority of people still installed it years later.
JS didn't suplanted it from day to night. It was Steve Jobs who killed Flash, not letting Adobe from conquer their new iOS platform. They tried it so hard, even on Android back then, but they failed to deliver something solid. Eventually, both Google and Apple released their SDKs to develop apps, way more solid and faster than running a Adobe Flash player layer on top of the OS. This article shows the jump on technologies, from the CSS perspective http://minid.net/2019/04/07/the-css-utilitarian-methodology/
I don't think so. Flash was strong in three scenarios: corporate websites, games and advertising. The agency I worked for made 95% of its revenue from Flash work, and most of the agencies in Barcelona, Madrid did the same.
The case against Flash was (apart from the horrible security issues) mostly about stacked libraries, including Adobe's own UI library. You could code applications with remarkable performance and small footprint using the pure Flash Player target (neither Flash nor Flex, but pure AS3).
Regarding integration, some text elements featured basic HTML capabilities. Nothing terrific, but you could extend on this. (And, of course, XML parsing, but this is another story.) Also, later Flash Player applications (Air) featured a full-fledged WebKit element for rendering web views. That said, it was good thing that Flash had eventually to go, and, at times, the state of the web today is pretty reminding of this.
The general web loved Flash for cases where you needed an application rather than a document. It wasn't appropriate for everything, and it was unfortunately very difficult to mix Flash with general HTML, but in many ways it was better than today's web for both creators and end users.
For the user, flash applets where super easy to block in general and to whitelist on pages where you wanted to use that particular flash application. Basically the same was true with Java. And for a certain extend JavaScript -- until the ugly DHTML menus arised and websites stopped to be usable without JavaScript.
Nowadays there are only two options: Either you block JavaScript --- and percieve a 1995's web view, in general --- or you let it run on your browser, having tons of programs running which you probably don't want (ads, tracking, that particular application that replaces flash).
The 1995 view is superior. It loads fast, doesn't hog CPU, never does anything unexpected, and has limited tracking capacity. I cringe whenever I browse without NoScript. If your pages can't render in my sandbox I just go somewhere more sensible.
It's superior only until you want to do something that does actually need JS - sometimes "go somewhere more sensible" isn't an option when you actually need to do something specific (e.g. buy an Amtrak ticket).
Flash tried to do this 15-20 years ago. Flash was basically "here's a canvas, do whatever you want within reason". It had its use cases back then but the general web vastly preferred good old HTML and eventually CSS and JS.
There's a lot of value in having constraints, especially when those constraints (HTML) are specifically designed for displaying documents.