Linkdump for August 14th
¶ by Rob Friesel-
Drew Crawford (Sealed Abstract) wrote this a few weeks ago and I finally (finally? finally!) got around to reading it start-to-finish. The best part about it is that (as he says in the first paragraph) his discussion is entirely fact-based. And where possible he is also illustrating his methods for generating these facts. This is excellent, because this is the sort of thing that we need in our technical discussions.
That being said, for all its fact-based-ness, it also comes across as a bit of defeated-hands-in-the-air "JS is slow" fatalism. Yes, he is bringing the facts to bear on the case, but he leaves it at that. Which is totally his prerogative. It's a 10,000 word beginning to the conversation.
Anyway: it immediately made me think of the work being done by the webapps working group (e.g., web components) — basically: future alternatives. Maybe I'm wrong to think so, but I'd like to think that in a few years we'll have some better tools at hand, even if JS is still "slow".
-
Jan Varwig:
Directives are the core building block of an Angular app. Use them to insert whatever structure or behavior you need in your app. Views are merely a shortcut for very simple use-cases.
The more I work with Angular, the more I agree with this statement. The framework's greatest power is in the directives. If you want to know where to invest your energy: directives. (Or, as Varwig puts it: "Embrace directives, they're cool.")
-
Allan, writing at the LayerVault Blog:
We implement Progressive Reduction by assigning levels to each feature, starting with level 1. For example, if you gain enough proficiency in Signposting and Delivery you’ll see the level 2 version of various UI elements. If you fail to Signpost for a few months, your UI regresses back to level 1.
Their notion of "progressive reduction" is intriguing, even if my initial reaction is one of hesitation (esp. w/r/t/ the inherent inconsistency it creates). I wonder if this is something that will catch on.
-
Rands In Repose:
What isn’t obvious is that there are folks who aren’t going to complain because they believe the right thing to do is to take one for the team. They worry that that the act of complaining is tantamount to saying, “I don’t believe I should do shit work” or they’re simply wary of being accused of not being a team player.
-
Jesse Hallett in a blog post that uses jQuery and Bacon.js to illustrate the functional reactive programming style:
The new stream is converted to a property to make this work. A property is a value that varies over time. The main practical distinction between a property and an event stream is that a property always has a value. In other words a property is continuous while an event stream is discrete.
Somehow this seems a little backward, but I'll go with it until I have the right level of understanding to either challenge it or else concur. Anyway: this isn't the first time I've encountered FRP, but this example seems a bit clearer than the last time around. Hallett's example talks about FRP in a practical sense by using it to manage characters from a typeahead field. And now to meditate on other scenarios where this style is useful and what it offers over over simple event listeners.
Leave a Reply