The current year in Long Now parlance would be 02022.
755 karma · joined October 23, 2015
The current year in Long Now parlance would be 02022.
Buttondown seems like a complete departure from the typical growth-hacked, venture-backed, over-engineered "products" in the SAAS space and I'm here for it.
Human behavior and cognition is driven by biological and cultural processes, which are the result of millions of years of evolution and billions of arbitrarily complicated proteins all interacting on one another. Is a computer going to emulate every part of that?
Despite what we think about our minds being rational, autonomous, operating according to a set of coherent principles, etc., I'm not sure that's really the case at the end of the day.
React has more mind-share and there are libraries for every feature imaginable, basically. But there is (or at least has been, historically) a lot of churn and fragmentation that is not suitable for all projects.
Angular and Ember sit at the other end of the spectrum – maybe you have all features nicely integrated but it can be hard to adapt such a big tool into a small, legacy, or otherwise non-standard project.
I think Vue occupies a nice middle ground here. There is a limited number of official libraries that more or less evolve together and cover most of what you need. But it's still totally feasible to just use the core runtime and call it a day if you don't need routing, state management, etc.
The story changes in the 20th century of course – governments racked up huge debts from world wars and related crises but instead of paying them down gradually over a long time (as England did after the Napoleonic wars in the previous century), they inflated their way out ("euthanizing" much of the idle rentier class in the process).
Historical economics is pretty fascinating – studying the past in this way really makes it clear how exceptional of a time we are living in now.
For people with resources, good support networks, etc. the occasional screw will (hopefully) be something easy to recover from. But for someone without those things it can be the start of a long downward spiral of compounding problems.
Everyone is responsible for their bad choices but not everyone suffers the same consequences from them.
Even so, an effect that can be demonstrated with tabletop equipment in a lab seems more intuitively real to me than something that requires a giant particle accelerator...
100 or 200 years ago a more or less average person could set up cutting-edge scientific experiments with basic equipment and patient observation – this was the modus operandi of Michael Faraday[1] for example. Sadly it seems like those days are mostly behind us now.
I'm not familiar with Garret, but Rovelli's book contains a great discussion of the "quantum eraser" experiment in that blog post, where quantum interference causes a split laser beam to recombine in different ways whether or not a detector is present. This is something you can observe with tabletop equipment apparently, a pretty visceral demonstration that quantum phenomena are a real part of our world.
Rovelli is a proponent of what he calls the "relational interpretation" of QM, which basically states that particles only have properties when they interact with other systems (and may be better thought of as events than persistent objects). Entanglement is a general phenomenon that describes the relationship between two interacting systems and a third which hasn't interacted yet. Put another way, something can be real in relation to A but not to B. However, the correlation that entanglement guarantees ensures that previously isolated systems will see the same things if they do eventually intersect.
It's different from QBism because there is no special privileging of human observers; all physical systems exist in direct interaction with some systems, are in superpositions in relation to others, etc.
[1]: https://bookshop.org/books/helgoland-making-sense-of-the-qua...
Most JS frameworks consider the SPA use-case to be the "happy path". There are a few outliers like the Stimulus family or Alpine (which I don't think existed at the time of the RFC) that expect to be sprinkled in to server-rendered HTML, but scaling these tools to full-blown apps may prove difficult.
I think Vue can operate in between these two use-cases better than some of the alternatives. Being able to compile templates at runtime is also a useful feature in a legacy environment, where you can't just transpile all the things ahead of time. You have to ship some extra code for this, but it's nothing compared to the cost of shipping (and running) all of Babel, which you'd need to compile JSX.
Some of this code may change or get moved around based on the outcome of these tasks: https://phabricator.wikimedia.org/T286946
But this announcement makes things more official.
Some real gems here, most of which are free to download. I admire the level of borderline-obsessive dedication required to keep such a project going!
> Technology persists in a given settlement for 100 million years before dying out
Seems wildly speculative to me. Our own civilization has only been around for a tiny fraction of that time and future prospects are already looking pretty uncertain. And if we lived in a galaxy where civilizations had this kind of longevity, one would think we'd see some evidence of potential signals out there.
My own pessimistic take on the Fermi Paradox is that life and intelligence may not be very unique but there is no reason for them to be long-lived either. Most civilizations are probably just a "flash in the pan", existing too briefly and separated by too great a distance to ever come into contact with another one (or even learn of another's existence).
At this point the only feature I'd say is lacking is some kind of e-book store integration. I'd like to be able to purchase books from mainstream publishers to read on the device (it's sad how few publishers distribute books in non-DRM, plain ePub files these days).
At least we have Standard Ebooks[1] in the meantime!
It's a shame because as someone who has a lot of interest in design, photography, etc. I acknowledge that they create some very powerful tools. I still miss Lightroom. But I'm just not willing to give them this much control over my computing environment any longer.
* Wikipedia is not becoming an SPA
* Wikipedia is not dropping support for non-js users
* This proposal is not about changing our current browser-support matrix[1] (which includes IE11 as a first-class target; Vue.js ecosystem still supports IE 11)
* This proposal is about changing the way we develop enhanced, JS-only features across our projects; many such features exist already, but they are written in jQuery and an in-house framework called OOUI
* These features will continue to be delivered in a progressively-enhanced way on top of the PHP-rendered baseline for the forseeable future. We are interested in how server-side rendering of JS components can integrate with this but we're still looking into how this might work
* We will continue to prioritize accessibility, internationalization, and performance in everything we ship
I don't think that Vue is "better" than React, but I think it has some features which are especially helpful in our progressive-enhancement, ES5 (for now, anyway) use-case. But it's great to have so many amazing tools to choose from.
Previously we've been using a framework we created in-house for complex JS features, but it's a product of an earlier era of the web and is increasingly out of step with the current paradigms in UI development. We think that one big benefit of moving in this direction is lowering barriers to contribution (both for new developers at the foundation, as well as folks in the wider community).
This is one of the reasons that the article I linked to above recommends a community-based approach. friend.camp (Darius' instance) uses a Patreon to cover the (fairly small) costs of hosting, registration, etc. I think a lot of users donate something like $1-$5/ year.
Running an entire server just for personal use may be overkill in terms of time-investment, monetary costs, etc. But for a small group of users these costs are negligible, and the small community still gets the benefits of having a lot of control over how the instance operates (who to federate with, custom features, etc).
We are used to thinking in terms of solutions that are either totally individualistic (everyone for themselves) or rely on giant monolithic institutions. A system made up of small, autonomous communities which can still communicate is a nice middle-ground.