I am missing one important argument in this discussion:
CSS only design is an important piece of a future web with reduced security and privacy threads.
The (interesting) model of allowing remote code execution per default was a beautiful, but naive vision. We have to make big advances in technology, politics and society to make this model work in a way that does not make internet users victims by default. We are not there yet. Reality is: the crooks destroyed that vision and are advantaged by the current situation, while all internet users are being trapped in their first moment of browser usage without their consent or knowledge.
For many use cases, (e.g. government websites, banking, anything where you type in your name) css-only design should become a requirement by law to protect the user until we figured out how to write secure software that respects user privacy and how to form governments that will respect their citizens (possibly will take longer). Until then browser vendors should implement more and better possibilities for CSS that help to avoid JavaScript whenever possible.
I very much like JS animations and stuff happening in the browser window, also there are some edge cases where JS brings some important advancements to a UI, but we have to face that privacy and security are much more important issues than having a nice UI and we have to change the current situation, as we, as programmers, are responsible for it.
The "remote-execution-by-default" experiment has failed, we need to change that, and CSS is a great way to go on with a web that might be less problematic for everyone, but still offers very nice usage experiences.
Browsers/webapps have only become this crazily successful because they allow seamless delivery of applications to run locally. I haven't seen anything to build "code-less" apps that can implement the complex features people want and isn't a complete nightmare to build and maintain. Until then everything you're talking about is just a pipe dream.
You can still make the apps you're talking about with html+css and enforce js=off in your user browsers, but there is a reason no one wants to do that these days.
And unless I'm not mistaken, there have been plenty of exploitable bugs in the core rendering engines that involve only html/css, so your utopian world STILL depends on a secure sandbox.
> Browsers/webapps have only become this crazily successful because they allow seamless delivery of applications to run locally.
I'm going to heavily disagree with you. There were plenty of sites that were successful without using heavy JS. Most webapps I see can run easily without JS, they just choose not to. Yes, there are exceptions, but they are exceptions.
"The core features people want" aren't JS-pop-ups, and slow browsers. They want sites that work quickly, are easy to understand, and work on mobile just as well as on a desktop. I would argue that JS makes all of those aspects worse.
> They want sites that work quickly, are easy to understand, and work on mobile just as well as on a desktop.
Not quite: users want to achieve specific tasks as quickly and easily as possible. Certainly "work quickly" and "work on mobile" are two huge pillars of that for many (probably the majority of) tasks, but for many applications you have to make significant trade-offs in functionality under the constraints of a static site.
Anything built on the web is competing with something that already is or can be built natively. Native applications don't have to concern themselves with this sort of limitation on interactivity as a trade-off for latency, which is an advantage. On the other hand, the web has the (huge) advantages of open discoverability and no-install distribution. It makes sense for both platforms to be working to fill in their gaps while trying to minimize the trade-offs.
It's clear that slow startup due to big chunks of js (and media) on load has become a big problem, and people are working on that, perhaps without much to show for it yet, but it isn't obvious to me that ceding the territory of interactive applications back to native implementations would be the better way forward.
And it's not clear to me that fixing a broken system is worth the time, when we have a working system standing by idly. I don't know of anyone who is asking for more interactiveness for most of the web, but I do know that non-js works, and works well. It may not be as "interactive", but I view that as a good thing.
Of course, this is all in context of a typical webpage. There are exceptions to this.
The open web is my platform of choice, and the technology is finally there. Progressive Web Apps[1] offer the features of native but are instantly-available, without downloading or installing. So yes, I very much want that as a developer.
I don't see how that image proves your point. Shitty designs are shitty if they are in a web-app, or mobile-app.
OK, fine. I'll concede devs want more interactiveness. I have yet to see evidence that users want more interactiveness. I think that points to the arrogance of devs "who totally know better than the user".
Users want positive experiences, and devs want to build those positive experiences. Look at some of the most popular websites out there: Youtube, Spotify, Amazon, Reddit - they're built on interaction. You're not just reading a post on reddit, you're upvoting it and influencing the front page.
This had traditionally happened through POST/GET requests and having all the logic server-side. Yes it's possible to build interaction without Javascript, but it's not a great effect. Imagine if you had to wait for a page load every time you voted on a post on reddit.
Now extend that to modern webapps. Take Google's Voice Memos demo[1]. It loads instantly. It supports any device. You can even add it to your homescreen and you won't be able to tell it from a native app. Everything about it just works. Why would a user not want such an experience?
Javascript interaction is the natural evolution of the web. If it wasn't JS it would have been something else. This growth has been driven by users, devs, and browser vendors alike. There's nothing "arrogant" about it.
That's funny, I just replied to you arguing the opposite. People in tech are the only ones I ever hear complaining about rich web apps. YMMV I suppose!
> I don't know of anyone who is asking for more interactiveness for most of the web
I don't know of anyone, besides programmers, who doesn't like the current interactive-web-app web more than the decade-ago full-page-load web. They don't like ads and popups and things being slow either, but they love Gmail and AirBnB and Facebook and on and on. We should solve the problems without throwing away all the good stuff.
> but there is a reason no one wants to do that these days
The reason is, that JS is enabled by default, nothing else.
If users had the possibility to actively decide before any remote code will execute on their computer, how many would like to enable it?
We are just one default checkbox setting away from what you call "utopia" here - a word that should be used for much bigger things.
Of utopic naivity in deed is the expectation that such powerful features will not be misused - delivering browsers with code execution enabled by default will be looked at as one of the most funny things of the first internet in a few
decades.
Web application development paradigms that enforce JavaScript usage as an absolute necessity are examples of "naive utopian deadends". It is totally anti-avantgarde and anti-progressive, we should not waste so many young talents on that.
I'll be the first to lament the spread of javascript, SPAs, and the huge hit to accessibility that the web has taken over the years.
None of that changes that js adds incredible power to what webpages can do and there is zero chance of rolling back browser-delivered applications at this point.
I also don't understand why you think html+css doesn't have the same fundamental 'code execution' flaw - you're accepting unseen input from a remote source and feeding it into an execution engine which will have exploits - whether that's css or html or js or xml or *.
Back to your question though: yes, 98% of web users want remote code execution on because they want spotify, facebook, and youtube to work. They would be upset if they even had to manually go in and enable it. And I'm not even sure you could make a quality version of those sites without js.
Apart from other points sibling comments have made - the current Web is very much a mush of "trust one site" leads to running code from three, four different domains via CORS and whatnot. My favorite alerts in noscript are people running js from bare cloudfare and s3 domains (do you trust all js publicly available on s3?) (and other cdns) - and also the "secure" amazon stuff like the hn search-box: some random AWS/cloudfront subdomains, a third-party service (algolia) and its accompanying domain for static resources.
It might be convenient and powerful - but secure? With our current huge (in code and complexity) browsers? With the series of bugs in font rendering, image libraries etc?
[ed: autocorrect. Apologies for seemingly calling algolia "third-rate" for a while there!]
"remote-execution-by-default": web browsers execute code that was loaded from an untrusted source somewhere on the internet. Every (ok, most) browsers by default allow any website you visit to execute JavaScript code in your browser.
"same origin" is about the source of that code, only of minor relevance here as long as no working signed code distribution mechanism and infrastructure exists - why not, btw, after all these years?
For communications and general information transmission we do not need remote code execution.
Yes, browsers try to do that in a "safe way" - the "sandboxing" approach has been exercised for many years now, mostly without success. Maybe Qubes OS can be a successful approach to this problem, but we still have too many non-technical problems to solve, as reality shows, so enough time to do more research. Until then: css only should be the default.
CSS gives us a very good way to stop going on with that inacceptable defaults while we fix the first version of the internet.
> the "sandboxing" approach has been exercised for many years now, mostly without success.
My impression is that Javascript has basically been the most successful sandbox ever deployed on a large scale. All vulnerabilities I've seen that escape the sandbox are due to things like Flash.
Does anybody know of any "JS-only" exploits that have happened?
> What do you exactly mean with "remote-execution-by-default"? As far as I know, all browsers have strict "same-origin" policies by default.
Even with the same-origin policy, the default behaviour of a web browser is to execute code it downloads from a remote site (i.e., remote to your computer); as it turns out, this is an utter disaster for security and privacy, turning what is a relatively securable platform (HTML+CSS) into a nightmare.
It is not, today, possible to be secure and private while allowing JavaScript. That's a problem.
Have you seen the whole presentation or just the first minutes? In the beginning he is showing some edge cases of css only usage, but then he actually demos some really good examples. The slides are here:
Interesting! Would you please like to post some links to actual privilege escalation code for a stock Ubuntu 16.04 - thank you very much for your attention!
This looks great, thank you for open sourcing this!
I would like to ask two things:
How do you think about the velocity.js code regarding performance optimization?
What would be the best way to coordinate multiple (potentially dependent) animations? I am thinking about a kind of dispatcher or switchboard logic - it would be great to see an advanced example right from the author.
Congrats on the release! You said Anime is equal or better than other JS libraries in terms of performance - were you including GSAP? In my tests, GSAP was significantly faster under stress: http://greensock.com/js/speed.html. Am I missing something? Do you have a test that shows otherwise? I don't mean that to detract from your hard work at all. Clearly you put a lot of effort into this, and I know how hard it is to pack in features and keep performance up and file size down. I applaud the file size achievement.
No I didn't, and you're right, GSAP perf looks amazing under your stress test! But I think it's a little bit unfair to compare performance on one test case. Anime was designed to offer more control on a single animation (like specific timings and easings by properties / elements) to avoid running multiple RAF at the same time (which is exactly what your test does), and keep the compact as possible.
Having 300 dom elements changing their top/left properties wasn't really my goal when I started working on Anime.
Hm, I don't recall seeing multiple RAFs in that demo. GSAP is all driven by a single one. And yes, I totally agree that nobody should place too much weight on just one performance test. I always advocate people doing their own tests which is why I was wondering if you had one that showed anime matching/exceeding GSAP's speed. No big deal, though. Just curious. Congrats again!
You can think of it either as map for setTimeout, or a way to turn sequences into a player object that accepts your own function to perform each point in the sequence.
thanks, this looks like a good start.
I would like to add "watchers" and "signals" that could trigger sequences. But I do not want to reinvent things, sure there must be something already out there (I am just an occasional user of js animations for gui elements, so I have no clue about the js animation universe).
Hmm, cool! The way I might go about that using Barrel would be to have many sequences in many players, can hook up your signals to call play() (or pause/rewind/stop, as needed) on the right player.
Also, Barrel has no built-in story for animations or anything HTML specific. But you can include tweening information in the events that make up the sequence, as long as your "doer" function knows how to perform them.
"Enterprise" is a code word for "we have knowledge inhouse and can do anything" and not "the products we buy restrict us to the limitations set by the company we made ourselves depend on". Free and universal thinking, however, is not found very often in companies, so not every company will grow into an "enterprise".
I would like to ask you to please establish a new standard of NOT expecting all kind of config files in a project root directory - this is an annoying pestilence that has to stop and the Jenkins team could really help with that.
Please instead establish any kind of directory that is expected where all that project and tooling related meta files are kept, I would like to suggest a top level folder called "config" - but I really do not care, how this is called, as long as that top level config file annoyance will disappear forever.
I believe it might be acceptable to expect exactly one optional top level config file that might be called "configrc" that would contain only the path of that actual config path if this is not in a default place.
Well my original plan was that the default build instructions would be in a README.md file in the root of the source control as a verbatim block in the highest level heading containing the word "build"
If you needed any additional configuration for Jenkins specific instructions then that would be in a folder called ".jenkins"
Sadly, people did not embrace that project type... perhaps because it was given the nerdy name "literate" by a colleague of mine (who's name rhymes with Nichale Meale)
now with extendended network support one question gets even more important: how do you do rollbacks with ansible? There is no default mechanism or policy that seems to help with that, so I have to hand-roll my rollbacks?
The simple answer is: you don't, you "roll forward."
In the event you deploy some code, a DB migration, a server configuration change, etc, and your solution fails after the fact, you move forward, not backwards. Let me explain further.
If you deploy v1.0 of your application and it works, great! If you then deploy v1.1 and it falls over, you find out why, apply a fix, test it locally (Vagrant?), deploy it to a testing environment and perform automated tests (Selenium, jMeter, ...), and once it's working there, you deploy it to production. This is called a hot fix, and it will now be working as intended (unless something else is horribly off the mark in which case you have other issues.)
The key to this example is the local and remote/network-based testing environment(s.) In my opinion, it's very much a realistic goal for ALL organisations of ALL sizes to operate local development environments using Vagrant and VirtualBox; a testing environment that spreads out the whole solution over multiple boxes (for testing networking code and configuration, among many other things); a staging environment for running performance tests (staging should match production bit-for-bit, cpu-for-cpu, ram-for-ram, ...) using jMeter or your choice of tooling; and finally a production environment to serve clients. This is the absolute minimum all organisations should be aiming for, and it doesn't even have to be fully automated using CI and/or CD.
Also tests, such as unit tests, systems tests, integration tests, usability and performance tests, and so on, are also critical to preventing the need to roll back and instead, implementing a roll forward policy.
Curious if "roll forward only" could create situations where a failed version change could place the system of interest in a non-functional state until the problem was diagnosed, the code revised, and an update released. If that's possible, I would have concerns about the infrastructure meeting the core needs of the business such as providing value to cutomers.
Your systems is already down, rolling back is the same thing, if not more effort than rolling forward. At least that's what I've always found.
Another option is to have customers point at stage after it has been upgraded and if it all goes horribly wrong, a load balancer change should be enough to point people back at the older production environment.
All this being said, problems in production shouldn't be a thing with configuration management, infrastructure as code (Terraform), and tests, not to mention three environments (development,test, stage - at minimum) to work your way through before pushing to production.
> All this being said, problems in production shouldn't be a thing with configuration management, infrastructure as code (Terraform), and tests, not to mention three environments (development,test, stage - at minimum) to work your way through before pushing to production.
You'll still have problems, you've just automated them now. Those tools and approaches are great, but do they really prevent all production issues to the point where they "shouldn't be a thing"?
Taking a snapshot of a system before making a change and rolling back to that snapshot would be faster. In any case, a strong policy of only pushing changes to production that have been properly tested in staging will protect you the most.
Why not just roll back while you're testing the fix? No need to be suffering unnecessary downtime while you hunt, fix, test, package, stage, and deploy the hotfix. Rolling back takes you to a version that has already passed all stages.
John Wilkes of Google talks about this problem with Jeff Meyerson [1] and how it relates to the choice to use or not use containers. The spoiler is that container management tooling allows separation of infrastructure builds from deployment: a configuration problem when building a container happens on the build server instead of while a script is running on machine in production. His argument is that when a container deployment to production fails, the state of the machine is readily known (new bad container) versus an more complex state when a scripted build fails part way to completion.
And a container management tool can facilitate handling a failed distribution automatically via rollback to a previously deployed working container.
Revert your playbooks and roles to the version of your last good deployment, and redeploy. With good version control, role version management and idempotent library modules, this should be functionally equivalent to a rollback.
There are plenty of caveats to the above (like the fact that the yum module won't downgrade [1], and you'll need reversible DB migrations) but that's basically the procedure.
This isn't quite accurate. It won't uninstall or remove things that a previous version put into place, unless you explicitly remove them before installing them as part of your playbooks/roles.
Exactly. This whole "declare your environment" thing with Ansible doesn't work.
I've completely mixed experiences with Ansible. Yes, it's easy to get started, but it's certainly annoying having to create playbooks for removing stuff to get a clean state.
To be frank, my experience with configuration management has been a mix between "YES! THIS IS WHAT WE NEED!" and "...but it still doesn't adhere to immutable states." That's been true with Chef, Puppet, and Ansible, for me. I haven't experimented with other techs.
Depends how you write your playbooks/roles. You can write a role that will both add and remove depending on the value of a variable in your inventory. Then tweak the inventory and re-run.
IMO, the use case for rollbacks with Ansible (or Chef/Puppet etc) are done through redeploying prior releases not through trying to remove/replace software on an instance. Same with if you are rolling out a server configuration update (like a certificate), if you need to roll it back you send out the prior configuration.
Hand-roll them like a fine cuban cigar. Jokes aside, I would not inherently trust an automatic rollback even if Ansible did support it. You must always provision for worst case failures.
Wow, that is a cool website, they have all the internet on their webpage and one can search for things, great startup idea!
I spent hours browsing their results, and still have many more pages to go. Thank you very much for that, I was so bored and now I have something to spend my time with, I feel much better now!
CSS only design is an important piece of a future web with reduced security and privacy threads.
The (interesting) model of allowing remote code execution per default was a beautiful, but naive vision. We have to make big advances in technology, politics and society to make this model work in a way that does not make internet users victims by default. We are not there yet. Reality is: the crooks destroyed that vision and are advantaged by the current situation, while all internet users are being trapped in their first moment of browser usage without their consent or knowledge.
For many use cases, (e.g. government websites, banking, anything where you type in your name) css-only design should become a requirement by law to protect the user until we figured out how to write secure software that respects user privacy and how to form governments that will respect their citizens (possibly will take longer). Until then browser vendors should implement more and better possibilities for CSS that help to avoid JavaScript whenever possible.
I very much like JS animations and stuff happening in the browser window, also there are some edge cases where JS brings some important advancements to a UI, but we have to face that privacy and security are much more important issues than having a nice UI and we have to change the current situation, as we, as programmers, are responsible for it.
The "remote-execution-by-default" experiment has failed, we need to change that, and CSS is a great way to go on with a web that might be less problematic for everyone, but still offers very nice usage experiences.