Why does it seem like more and more sites are requesting permissions to send notifications...makes it hard to consider this a "trustworthy" site when the first thing you're trying to do is ask for permissions to send notifications.
It was nice when it was used sparingly by things like chat apps, but it's become too annoying; maybe the webmasters just don't understand they aren't the centre of their users' lives.
At least the latest version of Safari supports blocking all these requests.
It's a poor design where a site is allowed to throw up a dialog like that (also goes for the "this site wants to know your location! yes/no").
It should work like the popup blocker, just show a red cross somewhere, that some action was blocked, and if the user wants to, he can go and unblock it. The onus should be on the site owner to tell his user "if you want this additional functionality, please go and enable <this or that>".
Depends on your OS. For Chrome on macOS, it'll show a chrome-styled square box with an icon and a piece of text in the upper right hand corner, kinda like macOS notifications (but they look nothing like it). In general, web notifications (can) work the same way they do on your smart phone. They can arrive from an active tab as well as from a background service.
Safari (on macOS) will use the native macOS notification system to display notifications AFAIR. I have no idea what IE on Windows does.
JS service workers allow a JavaScript thread to run in the background while the browser chrome (the window) is closed. So, in theory, the browser doesn't need to be open. Also, notifications can be useful with an open browser too (or, multiple tabs with a tab in the background for example)
I've noticed this trend as well, and it's accelerating fast. It's an unsolicited popup asking premission to send more popups. Thus I decided to completely turn off the notifications feature in my Chrome.
At ~175 MB with a blank drawing open, I've seen worse.
Some things I noticed about the menus (on Windows):
- The menus don't have hotkey support (Alt+…)
- The File menu is missing a Close option
- Submenus swich too soon on diagonal mouse movement
I'd suggest switching to native Windows menus. From other Electorn apps it seems this should be possible. I'm sure a way can be found to make the menu search feature work, too.
Another small note: on Windows, the close confirmation has the newer multi-option layout, the same you'd get when overwriting files in Explorer, but it only has an option to save changes. There is a cancel button, but that should really be an option.
The waste is still collected by truck from the terminal, and presumably driven to somewhere else in New York.
London tries to reduce large vehicle traffic by taking the waste away by barge; you can see the place in central London here [1] (I like the irony of "Smuggler's Way".) The Roosevelt Island waste terminal is at the edge of the island, so this is a missed opportunity -- if there's anywhere to accept it by barge. (London's used to go to [2], a quick search suggests it now goes to [3].)
I live in a neighborhood with this system installed. In fact you can see it at 3:28, pretty much all footage from that point on is from there.
When it works, it REALLY works. There is no trash in the streets, it's all in these tubes that you place your trash in. Some buildings have these tubes integrated, some have the tubes in the street kind of variety. Every now and then you'll see special trucks come in that quite literally suck the garbage out of the ground to empty out the underground storage.
Sometimes it doesn't work though. Maybe it's because people fill up the tubes with weird shit but I think mostly it's just because they don't empty the system often enough. When I first moved in this was a big issue, but now I haven't seen it in a while (actually years probably) so maybe they've figured out the a schedule better.
It is really nice, it works well and truly is an out of sight out of mind kind of thing. I'd imagine it's easier for garbage collection too since it's centralized, you don't have trucks coming around to each house or block.
There is some garbage that doesn't go in the chutes. Electrical appliances, glass, larger items that won't fit such as pots and pans and lighter furniture. They all go in special garbage rooms so still off the streets, but not quite as cool as giant tubes underground.
To your point of "out of sight out of mind" I wonder how much this impacts recycling programs. E.g. I'll just throw everyone in the trash because it's gone vs I'll recycle plastics etc separately which reduces "smelly" garbage.
I'll take a stab, although I don't share the same absolute stance.
I've run the gambit when it comes to types of front-end projects. The React community has more focus on scaling React for large teams and companies. This isn't to say Vue can't do any of this, but there is a clear focus in the React community. I need to do isomorphic rendering because of SEO, there is a lot of React documentation on that and very little for Vue. I need static analysis for my code to prevent errors, Flow answers that. I need a replayable state for debugging errors, Redux gives you that.
None of what I mention about React is its sole domain. You can list off many alternatives.
Reading through why people choose Vue, many common needs come up. The one that I find interesting is needing a system that Designers can understand because they code up the HTML and CSS. I doubt that is something that comes up with React teams.
In my opinion, if you require a framework, Vue and React are two great options. It comes down to various small differences about your team needs. (Please stay away from Angular though.)
I love both React and Vue, but I feel the need to step in and defend Vue a little here.
Of the 3 points you listed, Vue has a section in the official documentation dedicated to Server-Side Rendering, ditto for using it with Typescript for static typing, and it even gives you replayable state with Vuex (the official redux-style library for Vue).
If I make a typo in the name of a component or the name of an attribute used in a HTML tag property, Typescript will catch it. Since Vue & Angular uses template strings, TS can't do the same check.
This makes catching errors and refactoring easier.
I used to prefer Vue, but since I've discovered Mobx, I only use React now. It took me a lot of time to properly learn the tools, but I'm pretty happy with them now.
This. I just had a look at Vue and everything looked fine so far, until they started with two-way-bindings.
Two-way-binding failed already long before the web and SPAs. Many desktop GUI frameworks provided two-way-binding, but this concept constantly failed to deliver on its promises. Not sure why frameworks keep repeating this well-known anti-pattern.
I'd prefer framworks like React or Riot any time over two-way-binding.
1. Bad Two Binding i.e. Two way binding between components. Vue2 and most of the UI frameworks shun this.
2. Good two way binding i.e. Form model binding.
Because form input can actually come from two sources (user input and javascript). this is naturally two-way and this is why frameworks continue to keep it.
I think the second one isn't really a valid example. There are very few situations where you both want to have state mutations discard what the user has already entered and reflect user-provided state in real time. In other words even if it's supposedly "two-way" you don't actually want multiple inputs to share the same model and you likely don't want to represent the data the same way the form control needs to represent it internally.
As an example, let's say you have a formatted text input field that can be used to enter a decimal number. If the input contains no decimal separator, the decimal part is implicitly zero. But if you just use naive two-way binding with an actual decimal value this means you'll get in the way of the user trying to manually enter a decimal value (especially if the user tries to delete the decimal part starting with the separator).
As soon as any information is lost during the bind in either direction, you still need to explicitly think about where you want the data to flow into and out of the form field.
The archetypical example of two-way binding is definitely the auto-generated CRUD form that lets you edit a model in place, but IMO this is a tiny niche in practice because it falls apart as soon as you want to do anything non-trivial. It's great for prototypes though.
EDIT: To clarify, I think you're talking about two-way binding a form model to form inputs. But calling that two-way binding from an application developer's POV is kinda redundant because you still need changes from the form model to propagate outside the form in a more controllable and predictable way than two-way binding offers, so the two-way binding of the actual form fields becomes an implementation detail.
> Many desktop GUI frameworks provided two-way-binding, but this concept constantly failed to deliver on its promises.
Can you elaborate on this? The last time I wrote a native application was 6 or 7 years ago using Cocoa and Objective-C. If I remember correctly, Cocoa had a mechanism that was similar to two-way binding. Have things changed recently? What do modern iOS/Mac applications use?
Cocoa Touch (iOS) got rid of bindings altogether and you manage updates manually (although I use a bindings library to emulate the old OSX bindings support in one of my apps).
Not sure on macOS, bindings may still exist there.
That's exactly my point. The concept of bindings (in the sense of two-way-bindings) hasn't proved to be successful - neither today nor in the past, neither on desktop or in the web.
As a more general throught:
When comparing concepts or patterns, there are often discussions about which one is better, comparing different but almost equally good options. Choosing the "best" one is hard. So the list of advisable patterns is constantly evolving and changing.
However, some concepts clearly didn't pay off over decades across a huge variety of settings. These anti-patterns are quite stable, and more or less just growing, not changing. It may make sense to collect these ones.
The "good" concepts may be subject to fashion and evolution, but the "bad" ones are stable and hence worth collecting.
Two-way bindings are great for prototypes because you no longer need to think about how your state gets from one place in your application to another, you just shove your mutable state blob into every last part of your application and the framework does the rest.
But what you lose in return is the ability to control when state should change and sight of where changes come from. In the case of POJO state implementations like AngularJS 1 it also means you have to constantly diff the state against what you've last rendered to be able to respond to changes nobody told you about.
AngularJS 1 actually tried to optimise this a bit but ultimately it needed to pretty much control everything asynchronous in order for that optimisation to work and more often than not that resulted in hapless beginners wondering why their changes aren't always reflected in the UI (answer: because nobody told Angular it should check).
So in other words, your state consists of big balls of mud that may change shape without notice and if you pass one of them to any piece of code you must expect it to do just that without any way to tell until it happens (and good luck trying to figure out where it happened exactly).
Compare this to the "one-way data flow" React made popular: your state is a bunch of impenetrable rocks that roll into your application, which can't modify them but can do whatever it wants in response to them (e.g. push pixels around on the screen). If the application wants different rocks, it needs to explicitly tell wherever they came from that they should be different, at which point the application will be fed a different (or maybe identical) set of impenetrable rocks again.
In a word this is basically the difference between mutability and immutability, taken to the extreme. Although there's nothing in React forcing you to use immutable data structures, the one-way data flow assumes everything it's fed is immutable unless you say otherwise, and you pass in callbacks to be notified when state should change.
On the other hand, in two-way binding your state is mutable and extremely malleable by definition, and thus the implicit expectation for every operation is that it may have changed the state.
As a side-note: React actually has a dirty little secret called "context" which is the equivalent of thinking with portals: instead of passing ALL the state into your ENTIRE application's root, you pass the state container to a magical Pez dispenser that wraps your application root and then each component can be wrapped in a container that knows about the dispenser and asks it for a specific part of the state. That's how React-Redux works among other things and it's not entirely unlike dependency injection (except it doesn't happen globally but only in the context of the specific instance of the application).
The goal for this was a dynamic approach to create and destroy endpoints on the fly. The OpenVPN Access Sever is typically for a more permanent deployment.
> “Clemency is the one administrative action President Obama can take that will not be overturned by an incoming Trump administration,” Jessica Jackson Sloan, director of #cut50, a criminal justice reform group, said in a statement.
This becomes a huge problem when someone is linking you multiple tickets and you sit there waiting for asana to load. Even worse, I find that some basic features are still lacking such as the ability to strikethrough text.
It would help if their API were sane, and I could just write something to grab what I need on the command line or to a plain HTML/CSS page and never interact with their confusing, slow "web app", but it really, really isn't. I suspect that's a symptom of their backend being fairly dumb, which is (a big part of) why the frontend is so damn heavy and sluggish. Seems like an early (poor) architecture decision.
(yes, there are some command line tools that people have written, but they're too limited, for this reason, unless something's changed in the last ~6 months since I last looked at them)
Let me preface this by saying I'm a developer advocate at Asana, so it's part of my job to try to construct useful stories from this sort of information. If you don't mind me asking, what do you want to see from the API? Text formatting (i.e. the strikethrough) is a huge one that I'd like to see implemented, and there are definitely some, um, ideosyncratic parts of the API (I'm trying to be nice here), but I feel it's way better than screen scraping, which is what it sounds like you're advocating.
And as for the backend, I wouldn't call it dumb, exactly, but it was implemented in a way that would help spur early growth of the company - and it succeeded in doing that, so it wasn't a poor decision from that point of view. We really, really do know that we've outgrown it now, and are hard at work replacing it with something better. That happens at just about every company as it scales. The frontend is constantly getting faster as we adopt the rewrite, and the faster backend for the API has just entered open beta, as a matter of fact; you're welcome to try it: https://asa.na/fast-api.
IIRC the part the got me to give up on trying to do anything useful with it on the command line was realizing that to get a list of tasks under a team (which we treat as a project) I was going to have to make multiple queries, and it would be even worse if I wanted to show all tasks for a user across all teams (which, again, we treat as projects). It became clear that I was going to have to do a lot of filtering and request-chaining to just view basic things, let alone edit—which I'm guessing the web frontend has to do, which is part of why it's so heavy.
Glancing at the docs, it looks like they've gotten better in the last few months, which is great. Maybe some of that stuff's been fixed. I'll take another look at it when I've got some time.
More broadly, there are three things that would remove nearly all my complaints about Asana:
1) Clicking on a link to a task from outside Asana should bring up an ultra-light view of just that task (and its comments and such) that loads in under 200ms—under 100ms, ideally. If it must be read-only for this to happen, that's OK. Provide a link to open it in the full "app".
2) A light (think: basic-html-mode Gmail) version of the app itself. Most of the dynamic features are liabilities for me. Drag-and-drop happens accidentally more often than intentionally. Sometimes all the JS steps on its own tail and makes my cursor, and my typing, go places I don't want it (happened this week again, actually), along with other periodic, odd glitches. Editing task titles and such in-place happens more often by accident than on purpose. Every time I mess around in Asana I leave not certain whether I've mucked up the project without noticing. I'd much, much, much rather have a very fast-loading low-memory interface where such things happened only when I wanted them to. I don't mind full page loads if necessary (see again: basic html Gmail, which is faster than regular Gmail and certainly Inbox, most of the time, despite frequent full-page loads). I'd be happier with a zero-javascript interface, really, since the JS features mostly get in the way. However, with how much logic I suspect is housed in the frontend to achieve what's seen in the "app", this may be asking a lot.
3) Search. It needs to do The Right Thing by default. It should search the project I'm currently in unless I tell it otherwise. It should support inline filters, with auto-suggestions (as in Slack's search) so I don't have to clicky-clicky-typey-clicky-typey-clicky-typey-clicky to accomplish even fairly simple searches.
4) (BONUS POINTS!) Slack-style @ referencing, so I can just type it and don't have to use the autocomplete list to make it take (rather than just adding the text literally and not referencing the person I was trying to, which is what happens now if I don't select someone from the autocomplete list)
5) (BONUS POINTS 2!) It'd be nice if the "Inbox" displayed something like a colored diff-view of each item when it's selected, to make it easier to see what's actually changed. Clearing my Asana inbox takes more time than it ought to.
6) (BONUS POINTS 3!) Add an option to reverse-sort and never collapse any part of comments sections on tasks.
