gravity13

There's a really interesting book called [A Pattern Language](https://en.wikipedia.org/wiki/A_Pattern_Language) that goes into this.

They attribute tall buildings with insanity, as denizens begin losing scope of their world simply by virtue of not being able to see beyond buildings.

Another thing to note is that "Centers of Culture" are beginning to become more amorphous, as tech gentrification is whitewashing a lot of what gave San Francisco its identity. The Mission is probably the most glaring example of transformation, for better or worse.

Angular: for people who think programming UIs is all about two way data binding.

I've gone back and forth on this with a previous coworker before.

My opinion on it now is: there's two common general ways to use css. One way is as a style class, which is something you'd apply in multiple places around your project (like `.error` setting font colors to red, for example). The other way is to markup specific content so that you can apply specific styles to it - for instance, pixel pushing a header to fit exactly where you think it should in this one instance (perhaps to align an upvote button with a username, or something).

The latter way really seems to just markup dom nodes purely for the sake of identifying them within their structure (I might use BEM or rscss especially for these).

The way I structure my css in projects follows from this - I extract common styles and pepper them throughout my app where needed (but they are never referenced in any js/$ selectors). These are intended to cascade.

And then I will scope my more specific css under a selector (using sass, or cssnext or whatever) to avoid polluting the global scope:

  .some-view {
    .header { ... }
    .note { ... }
    .icon { ... }
 }

In the case of these nested selectors, they are more identifying tags for the content of the node, than they are declarations of a specific style. These are not intended to cascade.

So even though css classes "exist for styling purposes" I think they have two paradigms for use. One for marking up content for a general application of a style and another for marking a node to be given special treatment.

And taking that approach, I argue it's fair to use the same selectors for js as well as css.

Besides, in practice, you're going to realize you're just adding the same class name appended with `js-` everywhere `<div class='error error-box js-error-box'></div>` when you're using that `error-box` really only to mark the node for use.

Though I'd be curious to hear more about why you think this:

>Using CSS classes for both style and data binding would result in a maintenance nightmare, IMO.

uhh, don't know what beach you guys are working from, but I appreciate a strong 'Work hard' vibe, myself.

You want a chilled out work-to-life ratio, there's a number of places out there for you. Hell, some of them are startups. But part of the appeal of working at a startup is that you gotta get shit done.

Work hard and be nice to people. Not a bad thing to see on your wall.

>At this point I don't even think they know who they're targeting they're just trying to do a little bit of everything

They're basically trying to brute force their way by now.

Yeah but the action of maneuvering through the content is fleeting. Rather than squinting and parsing a whole bunch of stuff - you're just filtering as you move down the page. I do the same exact thing on HN. It's just that I can be lazy with the affordance of a large screen.

Also, reddit is different as a consumption medium, rather than news aggregator. With reddit, you consume. With HN, you peruse.

Only in the context of our fleeting industry.

The things I'm curious about with Shadow Dom:

- How does it affect performance, if say, a large application is composed of many shadow dom elements, each containing a large amount of redundant CSS?

- Will there be a way to let certain css styles "leak" through while encapsulating others? Or is any type of native inheritance gone?

React does not use Shadow Dom. And React is not related to CSS first-hand, though people are trying apply the same modularization principles of DOM encapsulation to the CSSOM.

Not only that - there's a lot of implication that come with Shadow Dom that will make it impossible to just plug and play with React. Namely, the fact that is stops the cascading effect of Cascading Style Sheets. Whereever you are stylizing large swathes of your app with common css code, you'll need to rethink by either treating css as a module and importing at the new shadow root, or by rewriting your css to be more redundant.

These tradeoffs require considerable buy-in, which leads me to suspect React will continue to be agnostic towards shadow dom.

> dull minded annotations

Is scandox making an assertion here? Could be, or perhaps it's a just a meager judgement. Whether or not he/she really thinks this is a pleasant first experience is open to question.

> That's actually what I love about react apart form using hierarchal components as building blocks.

This is interesting to me - I've become a bit wary of the hierarchy of responsibility as well.

Seems like a lot of it is stemming from the fact that there certainly is a hierarchy within the DOM. (This is one of the reasons I was so excited about GSS, which gives the ability to build a flat dom). But what are the solutions otherwise?

I would argue that's fair. Somebody might come along and suggest you GraphQL all the things, but the flux-flavors mostly tend to be focused more on the use of state in applications and less so across the wire. And Backbone's collection/model is pretty good at that.

I can see argument against adding heft to your app, though - if that's something you're worried about. There's the ampersand library which tries to be more modular while reflecting the good parts of Backbone, but it seems to be going a bit quiet.

You gotta imagine it from an old-time SF residents perspective, though.

A lot of people have seen their friends get pushed out by the rent situation, and slowly, places like the Castro are becoming less beacons of the gay pride community and more like another up-and-coming hip place to be.

It's not intolerance to be annoyed by it, a lot of the residents of the city loved the city for its culture but now there's so many tech bros in the land that the culture is being displaced.

The world's in flux, so tough shit, but as both a native to the area and a tech worker, in my opinion, this city is becoming less open minded.

It's also the fact that elemental mercury's toxic side effects are really hard to quantify and see because it fucks up the central nervous system, and is of more psychological detriment. Note that this is elemental mercury, not methylmercury, which only happens from predatory bio-accumulation in fish.

Over the years OSHA has consistently been lowering their safe mercury exposure levels (blood tests), and it's fast approaching "No mercury exposure at all is best."

I used to work in a lab with a ton of mercury in it, and some lab workers who were quite liberal with their handling of mercury, and liberal over 20 years. I don't know if they were crazy from the start, but I didn't want to find out.

The closest is ckeditor, I think. But that's still a long shot away.

Notion is actually really well constructed (as somebody who's been in the space building tools kinda like it for a while, it's quite impressive). But I agree, the space needs an open source notion...

Ah, cool! Yes, I completely agree. I'm actually working on something a bit like this which puts blocks of content as the building block.

It's ideal in an educational authoring platform - since you can have some people crafting the content and others curating it by linking groups of content together. It's important to cater to both needs, I think.

This is actually perfect for shadow dom, because it allows composition.

You gotta remember, Shadow Dom is a double edged sword, - while it prevents styles from leaking in, it prevents styles from cascading too. And sometimes, cascading was a good thing. Without it, you need to reapply base styles, and that's annoying. With this approach, you can compose component styling by declaring what to inherit.

Sure, but it suggests a component hierarchy which blurs the already ambiguous line between view and controller. Which is why there's flux and all of its variants, and things like falcor in the works - the missing model in data-component architecture.

This really is a flaw in netflix's design, I believe. I was surprised to find a movie I wanted to see on Netflix the other day and only found it via a roku search across multiple catalogues. Here I thought I knew their catalogue after searching for movies to watch several times.

It's like going to a movie store and only browsing one section. Over and over.

Yeah, you also have to account for box sizing by adding borders. What I've done for this in the past is use a css &:after pseudo-element and make it absolutely positioned, and set width and height at 100% and position it at left: 0 and top: 0. You can do things like give it a fill with opacity too, to highlight not with just outline but color overlay too.

.outlined:after { content: ""; position: absolute; top: 0; width: 0; height: 100%; width: 100%; background-color: green; opacity: 0.3; }

.outlined { position: relative; } // this part my be a poor assumption

After working with es6 for a bit (with babel), I still think I prefer CoffeeScript mostly because it's annoying to ensure brackets/parenthesis are closed properly.

Is it really because they're old? Or because they've established they are one trick ponies?

I've met young programmers who I wouldn't hire (were it up to me) for the exact same reasons most people wouldn't hire the stereotypical old programmer. 'Legacy' dudes from a time who seemed to understand bad code as a way to always retain a job because who else would understand the shit they do?

And then I've also met (and worked with) older programmers who taught me about the almost repetitive cycle of trendy functional languages, the types where I can literally have a two hour long philosophical conversation about design, extremely smart people I would hire.

I get the sense this is not entirely about ageism, but rather, the field itself has two different directions for growth.

Why? To preserve my "image" with fickle internet communities full of judgmental people who give me a double standard because my name is known?

This is why I'm glad I'm not famous...

lol I didn't know that.

Meh. It's something I would have done myself in the same situation.

Disagree. Perhaps because I was never an entitled CS grad with the world vying for my attention? I was never scared about whether or not I'd make $120k or $400k. I just wanted to work on something I believed in and be a positive force in this world.

"attack him publicly" - interesting choice of words there.

I was curious what "chastise an engineer candidate on Quora" meant so I looked it up: http://qr.ae/7IErH1

Sounds like a perfectly reasonable answer to me. Especially after reading the question. It gives me a bad taste, I wouldn't want to work with that guy. He's the annoying guy at the table who is like "I work at x" and wants everybody to go "oooh," not "wtf is zenefits?" It reeks of the almost ubiquitous entitled tech engineer stench.

If anything, this makes me appreciate the integrity of Conrad.

Huh?

You mean do I currently support anything but Chrome? Actually, no. But I'm not worried about cross-browser this minute. I'm leveraging shadow-dom pretty heavily to allow for encapsulation of web components developed by third parties and Chrome is the only browser to fully support that (with the webcomponents lib).

By the time my project is ready to (hopefully) be used by people, browser support will either be there or I will need to implement graceful fallback with iframes (but I think webcomponents.js will get there).

Not sure how else to respond to your snarky comment, so I'll just let you know: it's not easy.

Excellent stuff. I'm working on a framework right now for creating web documents like these!

Why DOM? It seems pretty simple to me, a simple standardized tree of nodes representing content.

My biggest gripe would actually be CSS. I mean, wtf.