The Zen of Just Writing CSS - <AUTHOR> https://svelte.technology/blog/the-zen-of-just-writing-css <comment><USER2> I like the simplicity provided by scoped CSS, and I tend to name classes in a way that essentially accomplishes scoping. However, there's this nagging feeling at the back of my mind that if every component in your app has its own stylesheet, your style is maybe not consistent? It just seems like the ideal website with a consistent and good UI design should be able to have a single stylesheet (probably written in Stylus/SASS). I don't know if this ever happens in practice, but it's just something I think about.

Less on-topic, I feel like the title of this article is wrong: you're not "Just Writing CSS" if you're writing scoped CSS, which requires some sort of build system.

<comment><USER3> You can use a global set of variables for typography, colors, borders, box- shadows, and spacings. This could be CSS variables, SASS, or Javascript variables in CSS-in-JS.

Typography and colors are something almost everyone tries to keep within a bounded set, but spacings are often overlooked. If the designer has defined a clear set of spacings - like 8px for small, 24 for medium, and 48px for large, then we can build consistent interfaces by using that as a primitive. Button paddings will be $small-spacing, while sections can be separated by $large- spacing etc.

The stylesheet at this point is just an application of all these base values to the HTML structure of the particular component, and that arrangement can be unique to each component depending on how its HTML is laid out.

[http://tachyons.io](http://tachyons.io) does this really well - @mrmrs_ has teased out a universal set of base values that can cover most designs, and has built out a complete UI kit out of it. There are many experience reports online, here's how DNSimple went about it - [https://blog.dnsimple.com/2017/01/CSS- journey/](https://blog.dnsimple.com/2017/01/CSS-journey/).

<comment><USER4> Has anyone in practice updated brand colors without needing other major style changes?

<comment><USER5> Yep, changing government department colours in my case. About 6 departments wanted the same components and each had small themeing changes, really just colour and font.

</comment></comment></comment></comment><comment><USER6> Just adding it here as well: if one likes editing CSS files in Chrome Dev Tools, then activating Workspaces will save such changes into the source file. This Dev Tools integration with the Svelte approach is so useful that it might actually tilt the choice in favor of CSS files over the more abstract, thus Chrome-uneditable CSS-in-JS (Workspaces are doable with SASS too as per [https://www.amazeelabs.com/en/How-to-write-Sass-within- Chrom...](https://www.amazeelabs.com/en/How-to-write-Sass-within-Chromes- DevTools-using-Workspaces-and-Auto-reload)).

<comment><USER7> Worth mentioning that CSS-in-JS _and_ CSS-in-CSS hot reload in any modern build system anyway. So using workspaces used to be super useful but it's not a big selling point any more.

<comment><USER6> I'd agree with it were it not for the huge difference between the view refresh latencies. Within the browser, it's near-intantaneous. Hot module reloading (which is still experimental) is relatively fast, yet there's a couple of seconds of a trip; also depends on what and how changes. Full page reload can take even longer, there's compilation time, bundling and the unavoidable cost of reloading stuff in the browser. Sure a couple of seconds doesn't sound bad but it's still a couple of seconds longer than what it should be (immediate) and it breaks my (work)flow.

<comment><AUTHOR> And you lose state, unless you've carefully designed your app around that problem by using something like Redux. Which is a fine thing to do, but not everyone wants to.

<comment><USER8> The chrome dev tools API has a neat function to inject new source code by only replacing all functions from the new code, thereby keeping any state. I've used this when building wright ([https://github.com/porsager/wright](https://github.com/porsager/wright)) to allow for hot reloading of anything (no need for redux). CSS reload is also instantaneous with wright, so might even make sense for you to use with the setup you described - No need for copy pasting ;) You can see it in action here [https://porsager.com/wright/example.mov](https://porsager.com/wright/example.mov) \- The start is editing js code (a mithril app) that is going through rollup, but there's also editing of raw css files at the end.

<comment><AUTHOR> Insanely cool demo. Learning Wright has been near the top of my TODO list for longer than I want to admit — I just never manage to get through the other items on my open source TODO list :(

<comment><USER8> Thanks a lot! I know that feeling, so many exciting things going on :) If you get around to it, I'd love to hear about your experience.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> TL;DR: People love to hate CSS, but it's the reality. People have various solutions to deal with the major problems with CSS (i.e. cascading global styles mean impact of any is unpredictable) but recently people have begun tying the CSS to the particular HTML collection it applies to, and the author likes that and points out some particular implementations he likes (I'm assuming "Rich" is/identifies as male).

<comment><USER10> Scoped CSS really is the most forward-thinking CSS IMHO. It's 'plain' enough to be adopted into most workflows and it doesn't really stray very far from the original CSS language.

<comment><USER11> Scoping CSS is great, you can do static analysis, idiot-proof just-in-time stylesheet loading, and when done correctly it eliminates a lot of specificity issues. It doesn't scale well though. Eventually you develop http-call bloat, and unless your CSS is written by a single and very devoted person, consistency becomes nearly impossible to maintain.

Visual consistency begs for DRY CSS, and DRY CSS tends to bend back towards single global stylesheets.

<comment><AUTHOR> The http call bloat is a by-product of how your build process works though — if your CSS lives in your components then you can easily bundle it just like you bundle your JavaScript. The ability to lazy-load individual components and their styles _if you wish_ is a feature, not a bug.

It's fine to still have a (preferably fairly small!) global stylesheet that covers fonts, colours and so on. The key is to avoid your components potentially clobbering each other, which is what SFCs accomplish.

</comment></comment></comment></comment><comment><USER12> I was using CSS in JS or CSS scoped to components, but what really solved my problems was tachyons

<comment><USER13> not familiar with tachyons and just did a cursory look at it, what about tachyons really solved your problem?

<comment><USER12> The problem of locally scoped CSS vs shared styles across components sometimes.

With tachyons I still wrap up styles in components but I also get globally scoped CSS for consistency with fonts/spacing.

<comment><USER14> Honest question: how do tachyons differ from a (well-thought-out) collecion of less/sass mixins?

<comment><USER12> Tachyons differs in that it gives you consistent typography/spacing but without the added complexity of a build step.

</comment></comment></comment></comment></comment><comment><USER15> I like the declarative nature of CSS.

I find that keeping what I do simple and small and well documented makes the simple stuff I do easy to maintain.

Yes, I can write you (another) 100kloc of Java or C++ or JS if you really want, but I did also enjoy Standard ML and Prolog over more and more imperative code with exciting race and portability issues.

</comment><comment><USER16> One thing i learned with css is that as a programmer you have to take it seriously. We generally don't consider it a programming language so we work on it the least, more often then not we don't even include it in our completion estimate.

To do CSS at scale requires organization and planning from the very beginning. If you start with bootstrap, you can't just deviate down the line. If you follow the BEM convention you not only have to stick to it, you have to enforce it so everyone in the team follows it.

Currently I work on 2 MVC project, and just like every component has a view, each also has it's own css file. We don't have to wait for compilation since .net has a realtime css update, and php doesn't need to compile in the first place. But for each project, i have to train new members to follow the convention.

<comment><USER17> > One thing i learned with css is that as a programmer you have to take it > seriously. We generally don't consider it a programming language so we work > on it the least

Agree with this. I've seen frontend work collapsing under its own weight because the CSS was kept in one huge file, you couldn't tell what was dependent on what, JavaScript was being used to alter the DOM based on classes and window resizes, there were around 20 different media query size widths, nothing was shared as variables...changing anything was terrifying and took forever.

You need to keep CSS modular, stick to naming conventions, reduce duplication and keep code concise; exactly like you do with regular programming languages. You can get far with CSS without any programming knowledge but at a certain scale you need to understand good coding fundamentals.

</comment></comment><comment><USER18> How is Svelte solving these problems in Vue Components?

> 2\. A child component's root node will be affected by both the parent's > scoped CSS and the child's scoped CSS.

> 5\. Be careful with descendant selectors in recursive components! For a CSS > rule with the selector .a .b, if the element that matches .a contains a > recursive child component, then all .b in that child component will be > matched by the rule.

[https://github.com/vuejs/vue- loader/blob/master/docs/en/feat...](https://github.com/vuejs/vue- loader/blob/master/docs/en/features/scoped-css.md)

If it's the same in Svelte I don't see how scoped CSS solves anything. I still need to be careful not to let the CSS bleed into the child components.

<comment><AUTHOR> It's not the same. Styles declared in a Svelte <style> block only pertain to that component, unless you opt-in to the cascade with a little bit of extra syntax borrowed from CSS modules: `:global(.foo) {...}`.

You can also compile Svelte components to custom elements, which use shadow DOM to enforce complete style isolation (though this is a new and experimental option).

<comment><USER19> Shadow DOM is the real answer here.

</comment></comment></comment><comment><USER20> If scoping CSS is such a big deal, I've got to ask if its not easier to just go with inline-CSS instead. It's a matter of whether specifying styling rules separately from content markup is a good fit to your app or doc, or if you're rather working around an undesired far-distance effect of CSS. If you need complete style isolation from the rest of your site, then you're really writing HTML markup to express an UI, so why not express it in a single artifact or dynamically generated HTML along with properties in plain old HTML style attributes?

<comment><USER21> Inline CSS is underrated. Sometimes you just need one big red button, not a .big-red-button class.

<comment><USER22> css doesnt constrain you to classes. there are other selectors as well.

</comment></comment></comment><comment><USER23> I'm completely dumbfounded how everyone has missed that the simple problem of scoping in CSS is naming.

I work with Vue and Stylus. You already have to give your JS components a name. Your styles can use that name. I don't need my styles inside the .vue files. I just keep them in a separate file: /styles/components/foo.styl. At the top of your Stylus file you give the name of the component (.foo) once. Even further, you can prefix it (.my-foo). That's the namespace. Then all your styles can be written under that with a methodology like BEM. Now you get scoping AND you can still load up your variables/settings first, via a main.styl. Otherwise, if you put styles in your .vue files then you need to remember to import variables each time. Also it becomes an issue to discern which classes in the component are from you and which are from a vendor (ie. Bulma, Boostrap). Then think about libraries. You can't work with styles that are in the vendor's .vue files (without adding more specificity). I wish that library would have provided me its separate SCSS/Stylus styles instead. Am I missing something here Rich? (btw, love your work in Rollup!)

<comment><AUTHOR> I personally prefer the co-location of styles and markup, because it means I'm context-switching a lot less. And it's essential that the compiler can analyze the styles _in the context of the markup to which it applies_ in order to do things like dead code elimination.

But support for external files and preprocessors is on our roadmap.

<comment><USER24> I have setup my own methodology for loading external files and preprocessing (ala postcss and whatnot) which works to my preference. As well, one can _still_ namespace to match. Win-win.

<comment><USER23> Alright, this discussion got me thinking. I think this is the way to go now. The bullet list:

\-- All separate style files (for non-vue-component styling, such as variables, functions, and CSS-only components) use BEM. All styles inside Vue components also use BEM. Consistency!

\-- Use Stylus in the Vue components. Vue-loader supports preprocessors. Why a preprocessor? Mainly for theming. Why Stylus? It's just so beautiful.

\-- Using BEM inside vue components means I don't have to worry about collisions (with global, or children, or vendors).

\-- Mental context-switching is reduced now since component styling lives inside the .vue files.

\-- I don't mind using #app to override vendor component styling.

\-- Better scenario for Dead Code Elimination to work with when putting styles in .vue files.

\-- I don't mind importing variables/functions/theming to each component until this is solved in the future. Plus, I could create a bootstrap.styl (not to be confused with Twitter Bootstrap) to import everything I need so I'm only adding a single file to each Vue component. Any changes made are made within boostrap.styl and Vue components would not need to be updated.

</comment></comment></comment></comment><comment><USER17> > The biggest problem with CSS Everything in CSS is global. Because of that, > styles intended for one bit of markup often end up affecting another. > Because of that, developers often resort to wild namespacing conventions > (not 'rules', since they're very difficult to enforce) that mostly just > increase your risk of RSI.

Hmm, I don't find namespace issues a problem to be honest. Generally I use a framework (e.g. Bootstrap) where I don't reuse any of its names, I have some global styling (e.g. buttons, forms, typography), each major screen/component gets it's own file with its own class identifier (e.g. page-home for the homepage) then in SASS/SCSS I make sure everything everything in each file is nested under the screen/component identifier (e.g. so everything to do with the homepage is nested under .page-home). It's going to be very obvious if you get a naming conflict and they're not hard to resolve.

Is there anything wrong with the above approach? You'd need something different if you were designing your own framework or general components across a huge website but for SPA and typical websites I don't see the need to make it more complex than this.

<comment><USER25> The problem I see with that approach is that it doesn't leave a lot of room for reusability in different types of design components.

Many times in larger web applications, designers will have similar design themes that span multiple pages (more than just simple things like forms). So there may be a callout with a border and all text inside is blue across 5 separate pages.

You may approach this as #homepage .callout at first but it begins to become hard to manage when you realize you need to refactor it into a side wide style.

Generally I approach everything in attempts to make it re-usable. And organize what I can into components. I'd rather write more css classes in the markup than have to specify names for certain cases where 'this heading is bold here but underlined in this case' yada yada, when I can just write .bold .underline .h5.

<comment><USER17> > You may approach this as #homepage .callout at first but it begins to become > hard to manage when you realize you need to refactor it into a side wide > style.

So one approach would be to have a "callout" css file, nest everything under ".callout" and have several callout styles you can use inside that file (e.g. ".callout .warning")?

> Generally I approach everything in attempts to make it re-usable. And > organize what I can into components

Personally, I find very little CSS can be reused between different projects as designers want completely different looks so I let things like Bootstrap take care of the basics and customise from there. It takes time and effort to make things reusable (same with code) so you need to weigh up how likely you are to actually reuse things and how much time that would save you.

Sometimes duplication between projects saves time compared to maintaining the code for some generic widget that has to work in many scenarios. For me, I don't think it would save much time as each component is usually small and simple but I could understand if you were to create e.g. a calendar widget where it involves a lot of complex styling and code.

</comment></comment></comment><comment><USER26> How do you re-use CSS across components?

<comment><AUTHOR> That's one of the unresolved questions. A couple of possible solutions:

* have a small global stylesheet with styles that are common to many components * put the styles in a mutual parent component and opt-in to the cascade with the :global(...) modifier (from CSS modules) * you don't. This is often the answer I prefer. DRY code is less flexible, and I've often found it far better to have some duplication 5 minutes before I ship rather than be desperately trying to change some CSS on _this_ component without also affecting _those_ components

But yes, this is an area we still need to work on.

</comment></comment><comment><USER27> > How can we reuse constants that are defined in a single place?

The answer for this is already in your browser: CSS custom properties [http://caniuse.com/#feat=css-variables](http://caniuse.com/#feat=css- variables)

On top of that the CSS working group is working on ::part and ::theme pseudoselectors to help theming across components. Brief intro in this Polymer Summit 2017 talk: [https://youtu.be/rvpJ5O0W_6A?list=PLNYkxOF6rcIDP0PqVaJxqNWwI...](https://youtu.be/rvpJ5O0W_6A?list=PLNYkxOF6rcIDP0PqVaJxqNWwIgvoEPzJi&t=1180) (skip back to 16:17 to hear why the CSS mixins proposal didn't work out)

</comment><comment><USER28> > It warns on _and removes_ any unused rules, then it minifies the result and > lets you write it out to a .css file.

So... is `el.classList.add('error')` going to do nothing if the source contains an otherwise unused error class? Is there some comment flag that prevents this behavior? Do you need to shut off the analyzer completely, or add extra hidden markup to also consume your dynamic classes?

Does it handle media queries? Or new/upcoming CSS features like the replacement for the attempted mixin standard? (:theme and... something or other...)

I'm all for finding dead rules, but if it automatically eliminates them I worry it'll be easy to accidentally trick.

<comment><AUTHOR> For the static analyzer to work, you'd need to add that error class to the template (`<div class='{{error ? "error" : ""}}'>` or something). But that's okay — it's the whole point of state-drive UI, and happily it's _much_ easier than manually manipulating the DOM in a way that keeps track of state. It's a feature, not a bug ;)

Yep, it handles media queries. It should handle ::theme just fine (since it doesn't know what it is, it'll just ignore it), but since it's not implemented anywhere I haven't tested that yet!

<comment><USER28> Ah, that's a good point. Despite using Polymer, React, etc... for side projects, my primary browser target remains IE8 in quirks mode, so I forgot modern UI patterns for a moment.

Sounds good, thanks for clarifying.

</comment></comment></comment><comment><USER29> Here's how I generally deal with CSS:

* As the author of that article was talking about, I keep as much CSS scoped to the component level as possible.

* Any layout-oriented styling(how a component is positioned and sized on a given page) is separated into its own style sheet per page. That way how a page is laid out is separated from how a particular component looks & behaves.

* To deal with the lack of container/element queries, a big roadblock in making components truly reusable, a component style sheet exposes Sass mixins that represent how the component looks at different sizes. The layout CSS for a given page, as mentioned in the last bullet point, includes these mixins at different media query breakpoints. The advantage to this is that the layout can manipulate a component at different breakpoints to create responsiveness without needing to have any knowledge of a component's internal workings.

An example of my third point is a component I'm currently working on right now called `incidents-grid`, which is merely a grid of items. The `components/incidents-grid.sass` stylesheet has mixins called `incidents-grid --xl`, `incidents-grid--lg`, `incidents-grid--med`, `incidents-grid--sm`, `incidents-grid--xs`. Other components follow the same convention. For my page, I have a `layout/index.sass` to deal with how I lay out my components on the page. At different media query breakpoints, I will include the incidents- grid mixins to change how the component looks at different sizes; at different sizes, this component may show or not show a thumbnail, or show smaller icons, or no icons, or omit some information. The layout can make these things appear/disapper at different screen sizes without a bunch of CSS specific to the component saying things like `.incidents-grid__thumbnail {display: none}`. Rather, my layout stylesheet can say something like `#l-index__incidents-grid { @include incidents-grid--sm }` in a media query to accomplish the same thing.

Granted, this can't be done with plain CSS without some JavaScript. But I've found being able to separate layout CSS from pure styling CSS, as well as abstracting the internal workings of components with mixins, to be a very sane approach.

<comment><USER30> For element/container queries I've written a few plugins: [https://docs.google.com/spreadsheets/d/1erAKZq0p6dH3LjtU01hj...](https://docs.google.com/spreadsheets/d/1erAKZq0p6dH3LjtU01hj2PlZH7tZxbGxFUl5jn- V_Hg/edit?usp=sharing)

Ultimately it's something you can DIY in ~30 lines of JavaScript, and over the weekend (just for fun, just to see how far back the ideas worked) I got it running in IE8, IE7, and even IE6 - so it's definitely something you can use today! [https://twitter.com/innovati/status/903998563738415104](https://twitter.com/innovati/status/903998563738415104)

</comment></comment><comment><USER19> Note that the benefits of scoped CSS are completely independent from single- file components.

The key idea is that with CSS and DOM scoping you write simpler, easier to understand, stylesheets and templates, which massively improves maintainability.

In Polymer elements, because of Shadow DOM, selectors are considerably simpler and shorter, often just using a tag name or id. Templates for a single component often fit in one screen, so you can more easily see if a selector is used.

As we get into more declarative template formats and better static analysis, we'll be able to see if selectors are used even for dynamic classes and attributes.

</comment><comment><USER31> > "But at the end of the day, you have to know CSS anyway"

If you string-replace "CSS" with "assembly", most of Bret Victor's "The Future of Programming" [1] still seems to apply. People used to argue this passionately that knowing how to write assembly by hand was critical to being a good programmer.

> "Love it or loathe it, you must at least learn it."

This might be true today, but it would be a shame if tooling didn't level up to a degree where CSS becomes mostly a compile target (just like assembly is today).

At the end of the day, CSS provides styling tools for a massive medium, one that should be accessible much further beyond the 0.25% of the world that knows how to code. The main way we can unlock that is with better tools and better abstractions. It's wholly unrealistic to get everyone to be as good at hand-crafting CSS as the author, nor should it be the goal.

CSS is getting more and more powerful and more complex, and it's unrealistic for folks to continue hand-crafting in perpetuity. Even today, with some of the world's best software engineers, I routinely see this:

* Most devs don't know how to create a radial gradient from memory

* Most devs don't know how to hand code shape-outside code, especially polygon

* Most devs guess-and-check repeatedly as they work with Flexbox props and use cheatsheets even after years of practice (while designers are running circles around them using visual abstractions like [2])

* CSS Grid minmax formats, don't get me started...

I personally love crafting CSS by hand, there's a certain satisfaction to it. But if that's the primary way that folks are styling stuff on the web 5 years from now, to me that would imply that we did a bad job of exposing this wonderful technology to orders of magnitude more people.

\---

[1] [http://worrydream.com/dbx/](http://worrydream.com/dbx/)

[2] [https://www.flexboxgame.com/](https://www.flexboxgame.com/)

<comment><AUTHOR> > Most devs don't know how to create a radial gradient from memory

I think I largely agree with you — giving more people the ability to build and design stuff with web technologies is something I care a lot about. To me, the answer is to build better tools around CSS, rather than creating a multitude of abstractions and creating tools that target _those_.

My belief is that CSS tooling hasn't evolved as quickly as JS tooling (and hence CSS-in-JS) because the JS community has often had a bit of a snooty attitude towards CSS and people who write it. That's something I hope we can change.

<comment><USER24> THIS.

</comment></comment></comment><comment><USER32> You seem to be calling out BEM as a "crazy namespacing convention" \- but as awkward as those underscores are to type, they _do_ seem to do the job.

I'm just a bit lairy of adding yet _another_ proprietary tool to my buildchain to try and bend the web platform to my will.

<comment><USER33> Anyone who dismisses BEM because of the syntax is missing the point of BEM entirely.

<comment><USER6> I think there are other reasons for dismissing BEM, it's quite an opinionated and shallow structuring, good for some stuff and not for others. Very HTML tag oriented, for which we have, well, HTML tags already. Its claims are simply not true (eg. "Reduces style conflicts by keeping CSS specificity to a minimum level."). Even in syntax, it saves on silly things (".btn"?) and wastes much more on, in effect, introducing Hungarian notation to CSS. I could go on but no time rn

<comment><USER33> Please do go on. Can you explain what you're talking about re: HTML tags? Maybe brush up here [http://getbem.com/naming/](http://getbem.com/naming/)

</comment></comment></comment></comment><comment><USER34> Perhaps if the web had started off as dynamic instead of static we'd have several styling minilanguages to choose from, that worked the same on all browsers, rather than the mess introduced by letting the browser wars dictate web standards.

<comment><USER35> There is no real alternative to letting the browser vendors dictate web standards.

</comment></comment><comment><USER36> So, as someone who currently has no background in web stuff, but is leaning that way, should I be paying a lot of attention to this, or put it on the shelf for now? How does this fit in or compare to Less or Sass?

<comment><USER37> The article is primarily talking about keeping your CSS modular... writing CSS that applies only to one "component" of a page (e.g. a box in the sidebar or a header logo or a navigation menu or whatever).

LESS and SASS have more to do with the fine-grained details of CSS syntax... primarily reducing repetition (via nesting, mixins, variables, etc).

I personally wouldn't worry about any one particular technology (other than CSS itself), but I have found over the years that the most immensely helpful technique when working with CSS is keeping things as modular as possible. Basically, ignore the "C" (Cascade) in CSS, either with compiled / scoped components (like the linked article is talking about) or through a naming convention like BEM or SMACSS.

</comment></comment><comment><USER38> i work in react, so i just create a <componentname>.css file in the same directory and `import componentname.css` in my component.

I get the advantage of using either Sass or less or postcss with webpack and I get all the features as expected from this workflow.

The only thing I don't have is that unused class feature with my workflow, but I can probably find a postcss plugin which handles that.

I don't see any advantage of this library for me?

<comment><AUTHOR> The CSS developer experience is just one small aspect of the framework. The advantages are spelled out more fully in [this blog post]([https://svelte.technology/blog/frameworks-without-the- framew...](https://svelte.technology/blog/frameworks-without-the-framework)) — Svelte compiles your components to lean, _very fast_ JavaScript. It handily outperforms React, and your app will almost certainly be smaller and start quicker.

You're unlikely to find a postcss plugin that can eliminate dead code. Unless it can analyse your CSS _in the context of your markup_ , it has no way of knowing what's safe to remove. For that, you need statically analyzable single file components.

<comment><USER10> No reason why Webpack/`import css` couldn't eliminate the CSS from this

        // styles.css
        .root { background: grey; }
        .button { border: 1px solid blue; }
        .error { color: red }
        .alert { background: red }

        // Component.css
        import styles from './styles.css'

        return (
          <div className={styles.root}>
            <button className={styles.button}>Submit</button>
            {false && <div className={styles.error}>Error!</div>}
          </div>
        )

Both the .error and .alert are candidates for being removed.

Of course, I'm not aware of any solution for nothing this currently, but all the bits and pieces are there for it to be feasible.

</comment></comment></comment><comment><USER39> I think browsers need a pixel level api that someone can compile a layout engine down to. Sort of like webassembly for layout instead of logic.

<comment><USER40> You mean like WebGL or canvas?

<comment><USER39> No, outside of canvas. Make the pixel api the parent and html/css the compile target.

<comment><USER40> Can you elaborate?

<comment><USER39> The model of html/css is not designed for the ground up for modern layout. It was a tool designed for a separate purpose with features hacked on over the years to make it work.

Nowadays a website is no longer just a document. It's an application. Why have html/css the one crude way to make a web application? In the backend we have a constellation of apis, frameworks and languages to build an app, but in the front end it's HTML/CSS/JS. The role JS played is generalized by WebAssembly, it's time to do the same for HTML/CSS.

<comment><USER40> Yes, but what would be the advantage of having low level HTML/CSS?

WA gives us performance. Before WA you could already write with many languages and output JS.

<comment><USER39> The primary reason behind WA is not for performance. If performance is all they cared about then browser developers can continue to work on optimizing the speed of the JS vms. The advantage of a low level pixel based api is for people who don't like HTML/CSS. It's to make web application development truly about application development by allowing developers access to a whole universe of layout engines rather then just one.

</comment></comment></comment></comment></comment></comment></comment><comment><USER41> There's no better feeling when you can write some clean CSS in a wordpress template to make it do what you want!

</comment><comment><USER42> wasn't this all possible with tables and iframes.

we even had IDEs back in the day that compiled wysiwyg into that code.

we're repeating everything but just in a prettier way.

</comment><comment><USER43> Scoped styles don't work properly for child nodes.

<comment><AUTHOR> What do you mean?

</comment></comment><comment><USER44> Pure zen is vanilla-css.com

<comment><USER45> That 404s, did you mean vanilla-css.com?

<comment><USER44> Indeed. Thanks.</comment></comment></comment>


Scala Pros and Cons - <AUTHOR> http://jim-mcbeath.blogspot.com/2010/12/scala-pros-and-cons.html

<comment><USER2> _If you believe, as I do, that a given programmer can produce roughly the same number of lines of code per day independent of the language used, you can see how this reduction of lines of code can translate into a substantial increase in productivity and a faster time-to-market._

Do people actually believe this? It seems to me the time spent typing actual lines of code is dwarfed by an order of magnitude by the time spent thinking between writing each line or method, cut and pasting for refactoring, etc. To borrow Fred Brooks' terminology, I think the most common languages at this point - certainly Java, Ruby, and Python - are at a high enough level that we spend an order of magnitude more time on fundamental rather than incidental complexity.

<comment><USER3> Not true at all. I encounter incidental complexity all the time when writing code in Java, Ruby, and Python. Especially when I need to interface with _other_ libraries and _other_ frameworks.

Ruby, Python, Java deal with the expression problem very poorly. The desire to write code generically is real so you have the mess of generics and people run to dynamic langs. In dynamic langs the desire to monkey-patch is real because you often need to extend objects whose source you do not control. In dynamic langs you often want an extension point, _that does not a mean a list of methods to call_ , rather a list of method signatures to implement so I plug my own functionality in w/o reading through your source.

All this adds up to countless hours wasted.

These are real problems in real software _today_ that current mainstream languages address very poorly.

<comment><AUTHOR> Thus summarizes the negatives. Do you have any examples of languages with effective solutions to the expression problem?

<comment><USER3> Scala (implicits, structural typing) and Clojure (protocols, extend-type) both have great solutions to these problems. Anyone know of other langs that deal with these issues properly?

<comment><USER4> Haskell has type classes and type inference which seem like they would be helpful.

<comment><USER5> Scala has (limited compared to Haskell, but still powerful) type inference and a way to simulate type classes as well.

<comment><USER6> Scala type inference is still evolving (as are clojure, and, I think, haskell and F#)

[http://www.reddit.com/r/scala/comments/ectzr/why_no_type_inf...](http://www.reddit.com/r/scala/comments/ectzr/why_no_type_inference_in_scala/)

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> _Scala provides tools that allow highly competent developers to write very concise code, and if you give them those tools they will use them. Developers who are less competent may then have trouble understanding that code._

A wise co-worker of mine once said that it is just miserable when you have to maintain code written by someone smarter than you. So I strive to be concise and clear, but very rarely can I justify using arcane features and concepts to achieve that goal.

</comment><comment><USER8> I'd like to add one to the "Cons" list. This language is even bigger and more complicated than C++. If that doesn't scare you, I don't know what will.

<comment><USER9> It's actually smaller and simpler than Java or C++ as far as I know. It's designed to have fewer edge cases and employ a smaller number of powerful features instead of many less-expressive ones.

It's interesting that you use the word "scare." It's a computer language. What's there to be afraid of?

<comment><USER8> > It's interesting that you use the word "scare." It's a computer language. > What's there to be afraid of?

I guess you haven't read very much C++ code. :P

With respect to the intent of its design versus the outcome, I can think of a few things that have been difficult for me in my playing with Scala. Implicit parameters, type parameters in general, especially the <: and >: operators, and some things like :/ and Ordering.by have confounded me quite a bit. The limited nature of its point-free style is also kind of difficult to get in -- IMO, they should have left that out entirely because two ways to do something is often worse than one. The distinction between = and = { at the end of method declarations, when you do and don't have to put parens on a no-arg method, and various other little quirks of the syntax are also a little annoying.

Don't get me wrong. I'd far rather program in Scala than C++ on a day to day basis. But, it seems quite large to me. It's a subjective measure, but that's my assessment as a professional C++ programmer and a beginner Scala programmer.

</comment></comment></comment><comment><USER10> When people say Scala is too complex, are they talking about functional programming?

<comment><USER11> No, it's the interactions between all of the boatload of features of the language that causes the explosion of complexity.

<comment><USER10> Right. The OO subtyping combined with the type system makes it complicated. I don't mind that, but another consequence is the limitedness of the type inference, which is kind of annoying.

</comment></comment></comment><comment><USER11> Scala is to Java as C++ is to C.

<comment><USER12> Not really; Scala is actually better than Java.</comment></comment>


Emacs-24.3 released - <AUTHOR> http://www.gnu.org/software/emacs/NEWS.24.3

<comment><AUTHOR> From the last release (8 months ago) 2519 files changed, 203613 insertions(+), 124051 deletions(-)

Incredible to see how much work has put into Emacs development.</comment>


Man wins $390,000 compensation after female colleague gets promotion - <AUTHOR> http://www.newsweek.com/man-wins-gender-discrimination-lawsuit-after-woman-gets-promotion-he-wanted-853795 <comment><USER2> So, zero details about what made the judge deem the promotion as discriminatory. Great press-work.

</comment><comment><USER3> Anyone from Austria have insight about the equal-employment/anti- discrimination laws?</comment>


A DMT trip 'feels like dying' – and scientists now agree - <AUTHOR> https://www.bbc.co.uk/bbcthree/article/dd52796e-5935-414e-af0c-de9686d02afa <comment><USER5>
        "My body just didn't seem relevant anymore," says
        Iona. "And I felt like I arrived in some consciousness
        soup which seemed like a different realm to the one I
        ordinarily inhabit – even in dreams. It just seemed like
        everything was rotating and swirling and spiralling. It
        didn't seem like there were normal space-time proportions
        going on."

I'm not exactly sure how close I came to dying, but I had the _exact opposite_ experience in the ER one night.

I had a bout of acute pericarditis, a swelling of the sac that protects the heart, essentially preventing it from beating. Usually it's a milder chronic condition but for whatever reason (freak infection?) I had an intense acute attack one night. It presented almost exactly like a heart attack which is why I rushed to the ER.

We got there just in time. My lips were turning blue and I was drenched in sweat, semiconscious as I was wheeled back to the ER. Heart rate plummeting, etc.

So anyway I was _hyper attuned to my body_ as the doctors worked on me. I was terrified and didn't want to die so for a lack of any other options whatsoever in my barely conscious state I became profoundly aware of my breathing.

I could feel that I perhaps going to die, and didn't want that to happen, so I just focused on being the best damn breather the world had ever seen. I figured whatever the hell was happening...well, I was alive as long as I was breathing, and the more oxygen I could suck into my body the better.

I have never, ever felt more connected to my body than in those moments.

Think about times you've been asked to focus on your breathing during yoga, meditation, etc. Like that, except times ten or twenty or a billion or something.

After some completely amorphous amount of time during which they worked feverishly, the doctors gave me a jab of atropine and I was more or less instantly OK, hilariously enough.

<comment><USER6> I had a similar experience from a bad trip on acid. I felt like I had had a stroke while trying to leave my body, and got pulled hard back into the physical realm. All I could feel was my flesh, tongue, teeth, skin, breath, heartbeat, etc. Everything was physical machinery, and had lost all meaning and purpose. It was the most horrific experience I've ever went through by far.

<comment><USER7> Are you talking about the comment, or the article? Your description does not sound anything like what the comment says.

</comment></comment></comment><comment><USER8> On the other hand, 5-Meo-DMT (5-Methoxy-N,N-Dimethyltryptamine), comes in the form of an organic lab-produced extract, or the Bufo Alvarius venom, takes it to a completely different level of non-duality and complete and utter shattering of your ego (temporarily of course, for about 20 minutes). Someone named Albert Most discovered this bizarre compound a few decades back by smoking the venom from the glands of a Sonoran Desert toad somewhere in New Mexico if I recall correctly. I haven't tried it myself but going down a rabbit hole of reports and practitioners on YouTube is in and of itself a profound trip: [https://youtu.be/PQctOMSmBuk](https://youtu.be/PQctOMSmBuk) . EDIT: Here is the piece Vice did on Albert Most: [https://www.youtube.com/watch?v=00jbzI4bcUw](https://www.youtube.com/watch?v=00jbzI4bcUw)

<comment><USER9> > Smoking venom from the glands of a Sonoran Desert Toad somewhere in New > Mexico

I don't know why but I just found this hilariously funny. Suddenly my life seems very mundane.

<comment><USER10> Have you lived or been to new mexico? Mundane life is what results in actions like that. Boredom breeds strange creativity.

<comment><USER11> It seems mundane when you live in NM. But I spent a decade in LV, NV. I'm very grateful to be back in NM. This place even had a Burning Man celebration before California afaik.

<comment><USER12> Burning Man is in Nevada, 100 miles north-northeast of Reno.

</comment></comment></comment></comment></comment><comment><USER13> I think it's important to stress the fact that DMT does not feel like being thrown in a meat-grinder, or being impaled in a car accident, or any other grisly way to die. Really, it might be more correct to say "Death might feel like a DMT trip" because many have experienced a DMT trip, but it's not every day you get to experience death. Of course, it makes for a less interesting title.

<comment><USER14> People experience death (and psychoactives) in a variety of ways, and its metaphorical usage reflects that. The meat-grinder sense maps better to stimulants (ie., caffeine, amphetamine, etc) whereas the exhausting, perhaps harrowing and enlightening sense of death is what we tend to experience with the psychedelics.

<comment><USER15> back in the day I experimented with psilocybin mushrooms and experienced what is called 'ego death'. basically, you lose a sense of self and identity. You are literally a blank slate. It was a surreal experience and I felt panicky like 'oh shit i think im dead but im still concious'.

Before I reached this state I was seeing math formulas everywhere. Basically when my internal thoughts stopped, that is I was experiencing reality in the rawest form, the only truth we have in the universe is math, in all shapes and forms, we live inside the 'body of god' that is math, but of course, so extremely complex to express in our 3rd dimensional world.

<comment><USER16> Yeah, that can be a frightening state. And yet, it was my favorite part, during the peak of the peak. To some degree, the rest of the trip was just something to be endured. Although I eventually learned to go dancing or bike riding or whatever.

The absolute worst combination is marijuana on the tail of an LSD peak. Your short term memory drops to about 100 msec. I spent a few hours, decades ago, reminding a friend who they were, and that everything would be OK in a few hours. And it was hard work, because I could barely remember who I was, and who they were ;)

edit: clarity

<comment><USER15> yes I should clarify that after the experience, it felt like I had been in a sauna for the psyche. Basically, I had lingering sense of peace and wellness.

The scariest shit I've seen while tripping was seeing the Eye of Providence. What's more creepy is that this is a common symbol people experienced. For example, I didn't know what the hell was a third eye until I saw it. It was unbelievable.

It changed my life. It gave me an unbiased raw truths about myself, circumstances, and ultimately the realization that we are where we are because of our decisions in the past.

Everyone should consume psilocybin mushrooms once. LSD you buy off the street can be laced. But good ol' mushrooms will never let you down.

<comment><USER17> I'm really interested in trying it out, but I live in mainland China right now. Have no idea who I could even contact about getting some, even in places like Taiwan or Thailand.

<comment><USER18> Houby hunting, then PF Tek.

Obviously, do lots of research. There aren't many deadly varieties by some of them look very similar to edible ones.

<comment><USER15> I wonder how many trial and error and generations of humans it took to realize which mushrooms were safe to eat. It's fascinating stuff.

<comment><USER16> Look for ones that turn blue when bruised.

Also, the fundamental methodology is to start with an extremely small amount. If there are no observable effects after some hours, eat double the amount. And repeat until there are clear effects, and decide if it's something useful. For food, for fun, or to use for poisoning enemies.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> > "There is nothing here to begin to enable us to propose that on DMT, you > literally transcend the laws of this universe and do actually go to another > world," he says.

This is faulty thinking. An afterlife doesn't presuppose a violation of natural laws, or a separate world. It just means you continue living in a different form.

The only thing that would be required for that is a causal relationship (yet to be observed in science) between your dying mind and some other living structure.

The causal eelationship needn't even be mind-out. If your mind is caused by the enduring structure and you experience its presence at death, that would be physically indistinguishable from you becoming that thing.

Given that we continue to discover entirely new structures in both the biological world and our own bodies, which were hiding in plain sight, I don't find this implausible.

That's not to mention psychoaocial structures which science hardly can model, and to which our individual minds are very tightly coupled.

<comment><USER20> Thank you for sharing. I think too often we assume the concept of an "afterlife" implies some kind of supernatural or religious phenomenon. Since we don't have proof of it I can't say I definitely believe such a thing exists, but I certainly believe it's possible. If there is an "afterlife" I believe it fits into our natural laws and can be explained and observed scientifically - we just haven't discovered all of the information we need yet.

<comment><USER21> It's tricky, because the kinds of natural laws that are necessary for the existence of an afterlife are the same kinds of natural laws that invalidate the principle of physicalism or materialism, which is the consensus view of the scientific establishment today. So if you decide to investigate something easier to test for than "the afterlife" which could also plausibly exist with these expanded natural laws—like remote viewing, or the effects that consciousness has on physical systems—your research will be generally dismissed as quackery. Not many folks will try to replicate your results, or even spend the effort to examine them deeply for flaws, because the assumption is "we already know that cannot happen, so you've done something wrong in your setup or you're lying."

There is plenty of evidence out there that points to something odd going on; the challenge lies in getting more skeptics to seriously evaluate it. Some HNer years ago turned me onto the book _Irreducible Mind_ , whose last hundred pages or so is a bibliography of evidence for this kind of thing provided by people who say "I don't believe it, but I can't explain it." But a lot of that evidence comes from skeptics testing exceptional individuals, and James Randi did a good job of showing how fakers can fool scientists, so I can't really say how reliable it is other than as a jumping-off point for further study.

I came across an interesting and more rigorous set of studies done recently on how consciousness can influence quantum effects. They had observers try to influence the amount of interference generated by the double-slit experiment, and have repeatedly under various conditions gotten a significant effect. Perhaps most interesting is that while all humans had an effect, the meditators reliably outperformed the non-meditators. The setup is simple enough that it's just begging for replication.

Here's the video link for any curious folks. Skip the first 5 minutes which is just a refresher on what the double slit experiment is:

[https://youtu.be/nRSBaq3vAeY](https://youtu.be/nRSBaq3vAeY)

<comment><USER19> > the existence of an afterlife are the same kinds of natural laws that > invalidate the principle of physicalism or materialism

I don't see why that follows.

There are lots of phenomena in the world, like money, which are manifest in a non-physical substrate. Many many other things are immaterial. The characters I am typing right now are immaterial. There are bits in memory that represent the characters, but it's only in interplay with an entire system of physical structures that you can say the characters themselves are manifest. You can't point somewhere and say "that's where the character is". It's diffuse across a bunch systems in such a way that it's not manifest in any one location.

Almost all of our social and political realities are like this. Where is Conservatism? Where is calculus? These are not things with locations, which is what makes them extremely difficult to study, which is why so many people reject things like Social Psychology or Science Studies as bunk science.

Money, algebra, and the capital M that starts this sentence are all things that exist, in a way that's totally compatible with materialism. It's not necessary to claim that these things exist outside of a material substrate. They merely exist above it. Distinct from it, yet contained within it. Fully determined by its laws, but not described by them.

<comment><USER22> Consciousness is an abstract, non-physical structure and concept, but everything we know suggests it is inextricably tied to and an emergent phenomenon of the brain.

In the distant future there may be a way to extract and transfer consciousness into a new substrate, but with current technology, there's no reason to believe any sort of life, consciousness, sentience, awareness, etc. after death is possible at all. Just because it's possible in theory doesn't mean that applies to any currently living humans.

<comment><USER19> > everything we know suggests it is inextricably tied to and an emergent > phenomenon of the brain

I don't think that's universally accepted. I think trees are conscious and they have no brain.

I think the brain does create an illusion that other things are not conscious. It tricks us into thinking our own consciousnesses are distinct from the rest of consciousness. And that's been a useful adaptation for us. And it confuses the hell out of consciousness philosophers. But we were conscious before we evolved it. It's possible we were human before we evolved it.

> In the distant future there may be a way to extract and transfer > consciousness into a new substrate

It's possible such a thing already exists. We have ancient stories about it. If it were true it would be very difficult to detect.

If the universe is a simulation then it seems extremely unlikely that consciousnesses would never be read, just operating until they get eaten by the 2nd law.

<comment><USER22> >I don't think that's universally accepted. I think trees are conscious and they have no brain.

I don't think consciousness of trees is accepted by nearly anyone. But even if any trees were conscious, I don't see how it helps your argument at all.

>I think the brain does create an illusion that other things are not conscious. It tricks us into thinking our own consciousnesses are distinct from the rest of consciousness.

Yes, but consciousness of animals doesn't really mean anything here. If anything, it's a point in favor of the opposite side: that consciousness really isn't very special.

>It's possible such a thing already exists. We have ancient stories about it. If it were true it would be very difficult to detect.

Many things are possible. We have ancient stories about many of them. If they were true they would be very difficult to detect. That's why the basic scientific principle is falsifiability.

>If the universe is a simulation then it seems extremely unlikely that consciousnesses would never be read, just operating until they get eaten by the 2nd law.

I don't agree. If the universe is a simulation then they _could_ be read, but they don't have to be, and I don't think it's extremely unlikely that they wouldn't be. If it's a very "raw" or "real" simulation with no interference, they could very well just dissipate into nothing.

Assuming it is a simulation, what happens when you get shot in the head and lose brain function? Where is your consciousness at that moment? Is there a pre-damage backup somewhere? When was the backup taken? If backups are taken every instant or otherwise very infrequently, which one is the "real" state after you die? The one from right before the damage occurred? Something picked at random? If there is no backup needed because there is instead just some outside extra-dimensional consciousness "force" or "energy" existing since long ago, what is that thing doing exactly when you suffer from a brain injury? Does it just "stop working" in or "lose connection" to those parts of the brain? What is it doing when we're children?

I think even if we're in a simulation where nearly all living things are conscious, the chances of some kind of post-death experience is still basically zero.

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> The feature that sets DMT apart from other psychedelics such as LSD or mushrooms is the persistent environment called "hyperspace". In short, various psychonauts over the years have discovered an environment - for lack of a better word - they named hyperspace, which consists of surprisingly similar perceived attributes _over many different observers_.

Experienced LSD/mushroom users know that there is a tremendous degree of subjectivity and symbol/archetype emergence in their trips. If I only had a few words to describe the LSD/mushroom experience it would be "lack of clarity". It's as if one is looking through a scanner darkly (personal unconscious).

With DMT, this is not the case. There is no perceived intermediate filter, nothing impure or fuzzy. One feels as if one is already there and directly interfacing with the space itself. Rather than exploring his own psyche, a DMT user feels like he's exploring an entirely new space. This becomes apparent even when dealing with the difficulties of trying to use shared language to describe the experience with other explorers in order to discover common attributes [1].

[1] [https://wiki.dmt-nexus.me/Hyperspace_lexicon](https://wiki.dmt- nexus.me/Hyperspace_lexicon)

<comment><USER24> This is often my experience too - DMT is like being in VR. The geometry is simplified - lots of smooth curves and sharp angles, mostly flat textures or gradients. And it's populated by barely intelligent entities made of the same stuff.

</comment></comment><comment><USER25> Can anyone give a reason in darwinian terms, for why brains would evolve a feeling of detachment and contentment near death? I can't project a selfish- gene reason.

Maybe, if you hypothesise its in the 'I die, so others live' space, its like altruistic behaviour and favours the group genome, not the individual

<comment><USER26> Well we don't really understand the nature of "feelings", so the answers are going to be very speculative. But a better question might be: why do we feel contentment _at all_? Why isn't it all just fear and rage all the time, with certain things lessening the fear and rage, like eating, pooping, and copulating? After all, if we avoid death and reproduce, the genes get passed on - evolution doesn't care about feelings. This entirely sidesteps discussion about the epiphenomenalality of conscious experience and how/whether it can be "causal" in any sense.

<comment><USER25> "I don't want to die" has a pretty strong biological determinancy to it. It helps, mostly in adverse situations. Flipping over to "meh, who needs bodies" is inexplicable (to me)

<comment><USER27> There's a moment where your brain switches from "fight for your life" to "I'm fucked, don't bother trying to save me".

The I experienced when I nearly drowned once. I was very calm and ready to go. You can see it in videos of how to spot a drowning person.

<comment><USER28> I am an anxious person. About a decade ago I was a passenger and at one point I was within about one second of almost certain contact with a vertical box section on a very slow moving vehicle. There was no way that my friend, and inexperienced driver, could brake in time.

That one second was slow and I was unnervingly calm. Right at the last minute with probably less than 200ms to go, the driver very gently swerved and we must have avoided collision by less than two inches. Quarter inch if we include wing mirrors. My friend, the driver asked later why I didn't say anything. I explained that had I panicked, he would have panicked and we would probably both be dead.

<comment><USER29> I was driving 60 the speed limit on a rainy day in southern Cali when a truck appeared out of nowhere, spinning into my path. I had a very brief 'oh shit, this could be the end of me and my wife ' moment and then I calmly swerved to the left into oncoming lane that was empty at the time. The back of my car clipped the spinning vehicle at probably full speed perhaps slower If I slowed down (I can't remember if I did) and we spun a complete rotation and a half to end up on the oppoite side of the road facing the opposite direction. My wife went into full panic mode while I was as calm as I'd ever been for reasons unknown to me. I realized later had I panicked and waited a second longer to take action, we'd likely both be dead now. I don't know if t all happened too fast or if my mind decided to stay chill instead of panicking, but I'm glad i did what I did and that there were no cars in the other lane.

</comment></comment></comment></comment></comment></comment><comment><USER30> If anyone is in NYC this week, this conference on DMT has a ridiculously stacked speaker list:

[https://events.theassemblage.com/dmtdialogues](https://events.theassemblage.com/dmtdialogues)

<comment><USER31> A HN friend and I are going to this. Email in bio if anyone attending is interested in meeting up.

<comment><USER32> I don't live in the US so I don't have the opportunity to meet up with you guys, but I just wanted to say that your mention of "a HN friend" piqued my interest. Is that to say you guys met through HN? Does that happen often, that people meet through HN?

<comment><USER33> Most likely a friend who is also a HN user. But who knows — he is calling for people to meet up after all.

</comment></comment></comment></comment><comment><USER34> If it's near death experiences you want, no need to push the boat out - <USER2> skip dinner, go to the pub, drink 7 pints of beer, have a kebab (you'll probably be hungry by then), go home, drink the 2 bottles of beer you found in the fridge, that and eat the pork pie, then sleep for 6 hours, then wake up.

<comment><USER35> FWIW DMT is far more pleasant and far less of a hangover than the experience you're describing.

</comment></comment><comment><USER16> The key distinction here is between dying and all of the unpleasant stuff that normally comes with it. I've experienced loss of body awareness with LSD, psilocybin and DMT. But what didn't come with it was pain, cardiopulmonary stress, cramping, and so on. So it was easy to relax, and let go of body and consciousness. With just naked virtual awareness left.

So anyway, I can imagine that a pleasant death from opioid or barbiturate overdose might be comparable. Or maybe breathing helium, where there's no overt respiratory feedback. Or maybe hypothermia, although in my experience that involved too much twitching around.

</comment><comment><USER36> Ive done DMT probably 10-15 times in my life so far but quit all recreational drugs ~3 years ago. My last trip being the most intense; me and a friend used a dabbing rig and poured about a gram of dmt onto the heated metal nail - <USER3> 20 minutes but what seemed like eternity I Observed the birth, life, and death of myself multiple times over until I finally came back down to the 'real world'.

<comment><USER37> did you regret that last one? how much of a DMT trip can you actually remember?

<comment><USER24> In general it doesn't seem like memory is affected; the main difficulty is making sense of what you experienced.

<comment><USER38> This. I spent a solid year reflecting and trying to understand everything that happened during my first LSD experience. The whole thing simply transcends anything you have ever experienced.

When you "see" a strange loop involving your mind creating the physical world as you know it, and at the same time realizing the physical world enables your mind, it can take a long time to unpack. Sure when I'm here, we say that the mind is just a construct within he physical world, that just happens to be modeling the physical world. But that Doesn't make it any less of a significant experience.

It was like seeing the concept of ying-yang (duality and mutual dependence) reflected onto mind-body problem, and everything else.

Oh great times when you get bored of all the analytical logic problems of the everyday world. :)

</comment></comment></comment></comment><comment><USER39> The subhead is a much better title: "A new scientific study suggests strong similarities between near death experiences and [DMT]"

</comment><comment><USER40> I just associate DMT with nausea — and have no desire to repeat that pain. I did an ayuasca ceremony and only managed to drink one dose (you are encouraged to drink a lot more) — but my body felt so awful and all the evidence suggested the pretty obvious cause that there was no part of me that wanted to drink more and I felt completely fine with my decision to stop.

<comment><USER41> ayuasca and smoked DMT are too very different experiences.

<comment><USER16> Yes. And the article didn't make that clear enough. The biological lifetime of DMT is very short, because there are enzymes (monoamine oxidase aka MAO) in many tissues. So the effects last 15-30 minutes. But ayahuasca includes MAO inhibitors, so the effects can last for many hours. And it's mainly the MAO inhibitors that make users feel ill.

<comment><USER42> Changa includes rima (hamalas from b.capii) and lasts around an hour if good. And No nausia or effect from food.

<comment><USER16> Hey, thanks for that!

I used to have a book about ayahusca-like formulations, using plants from various continents. But I've forgotten the name. Basically, many plants contain DMT, and many others contain MAO inhibitors. Also, I believe that one can combine some MAO inhibiting antidepressants, such as selegiline, with DMT.

</comment></comment></comment></comment></comment><comment><USER31> Previous discussion: [https://news.ycombinator.com/item?id=17795900](https://news.ycombinator.com/item?id=17795900)

</comment><comment><USER43> Can we hear this "specially commissioned ambient soundtrack" somewhere?

</comment><comment><USER44> One thing people talk about is the short-lived effects of DMT, and how they would like more time in the the DMT space. But as I understand it, your body doesn't build up a resistance to it. The DMTx [0] project is seeking to exploit this property and created extended-state DMT experiences using some basic medical techniques. Also, they are looking for volunteers.

[0]: [https://www.dmtx.org](https://www.dmtx.org)

<comment><USER45> That sounds awesome. I wish I could pay to lie in a hospital bed and have a medical professional administer intravenous DMT just for a short period (at least initially). Hopefully this work will bring us closer to a world where supervised DMT voyages are available to the public.

<comment><USER46> They're looking for volunteers in the UK for psilocybin experiments:

[https://www.google.com/search?hl=en&q=Volunteers%20sought%20...](https://www.google.com/search?hl=en&q=Volunteers%20sought%20to%20take%20%27magic%20mushrooms%27%20ft)

</comment></comment></comment><comment><USER47> I feel at some point we changed what an NDE was really categorized as. When Rick Strassman did his research in the 90's and wrote DMT the spirit molecule he stated that classical NDEs were distinct from alien encounters and that in his trials alien encounters were far more common than NDE. Now it seems that alien encounters are also considered NDEs.

</comment><comment><USER42> It feels like having sex with the Universe. Pure dmt is more "cold" experience. With hamalas (changa/rima) its a more warm prolonged loving experience that happens more gradually Where the pure is more a fast blast into space. Its medicine and Works sonders for the mind. It saved marriges, lifes, jobs among my friends.

</comment><comment><USER48> Once when taking mushrooms I saw myself go into countless pieces in something that resembled a starburst. It was beautiful. I felt completely at ease. Then a profound realisation came to me; This is death. Then I connected the two.

</comment><comment><USER49> I wonder if "beta thanatine" from _Altered Carbon_ was based on DMT...

</comment><comment><USER50> Am I the only one who read this as _" A trip to the DMV feels like dying - <USER4> scientists now agree"_ ?

<comment><USER51> Being neither an experienced drug user nor American, I misread that similarly (Department of Motor _Transport_?) before remembering that DMT is a drug because I saw it in the title of a documentary on Netflix.

I don't know if my life has just been too sheltered, or not sheltered enough, because I wouldn't even know where to begin if I wanted to buy anything not available over the counter.

</comment></comment><comment><USER52> I died in a dream. Does that count?</comment>


Show HN: Razorframe – A Node.js module for empowering real-time apps at scale - <AUTHOR> https://github.com/team-emt/razorframe <comment><USER2> Why should anyone use this, instead of just using a Redis client, the `cluster` module, and a WebSocket server directly? It's only 251 lines of code as of writing, which is partly spent on trivia such as a linked list implementation, a string hashing function, and some console messages. There is a whopping total of 23 lines of test code for the linked list implementation.

Also, did you really hardcode credentials to some hosted Redis instance somewhere? [https://github.com/team- emt/razorframe/blob/e35004f7f2915275...](https://github.com/team- emt/razorframe/blob/e35004f7f2915275f81d6133455fc95293c88665/lib/Razorframe.js#L10) (I'd rewrite git history if I were you)

<comment><USER3> Hey this is Michael, one of the co-creators of Razorframe. We're currently hosting a redis server for devs to use during the prototyping phase. Those who are moving into production will need to host their own, but we're happy to share with the community. We're adding information to our documentation to this effect. Great catch and thanks for reviewing our code!

<comment><USER4> Ahem. [https://github.com/team- emt/rz_demo/blob/master/server/datab...](https://github.com/team- emt/rz_demo/blob/master/server/database.js)

<comment><USER4> Yeah. [https://github.com/team- emt/rz_demo/commit/59ee149a50f25d13f...](https://github.com/team- emt/rz_demo/commit/59ee149a50f25d13fe3414bb2818b06e286da634)

Rewrite history, as @sapeien suggested.

</comment></comment></comment></comment><comment><USER5> "real-time apps at scale" and socket.io ? I don't think so. If you want to compare socket.io with something that works on scale look at uWebSockets[1] which is around 50 times faster and lightweight than socket.io is.

[https://github.com/uWebSockets/uWebSockets](https://github.com/uWebSockets/uWebSockets)

<comment><USER6> Whoa--was unaware of this gem. Thx

</comment></comment><comment><USER7> > Those interactions are held in the queue only as long as the server needs > before dequeuing.

How sure are you that this invariant holds? Under what conditions do you expect it to fail?

Clearly this is a fairly new project. 148 commits. No tests, benchmarks, or specifications.

Keep at it. :)

<comment><USER8> I too think this is a bit premature, especially when I see placeholder code like this [1]. I'd also mention the redis dependency somewhere, IMO I shouldn't have to go all the way here [2] to find about it.

Somewhat less important feedback:

\- I want my libraries to be quiet; currently there is a lot going out to stdout. I see you already depend on debug, why not use it some more? (somewhat related: are the emojis really necessary?)

\- IMO libraries shouldn't listen for uncaughtException. Libraries don't have enough context, or even the guarantee these errors belong to said library.

\- require all your deps at the top; I'd like to pay that cost upfront when I start the process rather than after calling a function, potentially in the middle of doing something.

\- only use backticks if you are actually doing variable interpolation.

[1] [https://github.com/team- emt/razorframe/blob/master/lib/Razor...](https://github.com/team- emt/razorframe/blob/master/lib/Razorframe.js#L224-L238)

[2] [https://github.com/team- emt/razorframe/blob/master/lib/Razor...](https://github.com/team- emt/razorframe/blob/master/lib/Razorframe.js#L8-L10)

</comment></comment><comment><AUTHOR> Razorframe is a Node.js library for enabling the effective backend scaling of your real-time application. Built on top of Socket.io, Razorframe's simple server-and client-side API allows you to easily employ the task processing of multiple, parallel Node instances in conjunction with an in-memory queue.

Our team set out to deliver on pushing the impact of real-time web through maximizing backend resources provided by multi-core server systems. By allowing your Node.js server to run on multiple threads and ensuring data consistency through an evented queueing system, Razorframe makes your application's backend more resilient and performant under duress.

We'd love to get some feedback on Razorframe and ways in which we can make it a better solution for your next Node.js project. Feel free to check us out on GitHub!

Thank you!

<comment><USER9> Would this be a firebase competitor? If so, how does it compare?

<comment><USER10> Hey, it's Travis, one of the co-creators of Razorframe... Firebase is a paid platform-as-a-service that includes realtime database hosting (what it's primarily known for) as well as numerous other services such as app analytics and hosting. It's a great platform and we definitely drew inspiration from them.

Razorframe, on the other hand, is an open-source project that addresses 2 of the main trends we see in modern web applications: real-time client UIs and flexible server-side scaling. We built a Node module that you can bring into your server-side code to quickly get up and running with websockets (via socket.io) and Node clusters in order to accomplish both.

Check us out on GitHub and let us know what you think:)

</comment></comment></comment><comment><USER11> Congrats on the launch! Glad to see more people working on these kinds of problems.

As someone who hasn't built one of these systems before... What does Razorfish give you that running Socket.io as a separate microservice that talks to your existing API service over an existing message queue doesn't? Is it for people with architectures that don't have an existing queuing or API services already? Or does it handle sharding the Socket.io part easily which usually has to be vertically scaled?

(Sorry if these questions don't make sense, I haven't dug into my requirements for these things yet but I know they're coming up!)

I think a very clear explanation of that would help me (and maybe others) understand its value and how hard it would be to roll your own here.

<comment><AUTHOR> Hey Ian - this is Edward, one of the co-creators of Razorframe. Thanks for your thought provoking question! Developers can certainly utilize the architecture you've described to great effect, but our solution aims to deliver a lightweight option that integrates technologies that don't normally play nice (Socket.io and clustered Node instances) but can have awesome scaling potential when they do.

By keeping all the features within a familiar environment in Node, we've experienced that development time was vastly reduced in a potential project that expected a high volume of Websocket communications. For example, the incorporation of an in-memory queue reduces the need for developers to incorporate an external piece of tech (and any new language adoption) into their Node.js projects

</comment></comment><comment><USER12> What happens when one or many Node processes die with items left in the queue? Related, how are graceful restarts handled? (These are issues solved by existing message queues.)

<comment><USER10> Nothing happens to items in the queue in such a case. New workers will automatically respawn, and the adapter that links all the workers on the back- end will re-attach to newly spawned workers. Clients formerly connected to workers that are now gone will have to re-attach to new workers by socket.io.

</comment></comment><comment><USER13> Nice but why not Primus instead socket.io?

</comment><comment><USER14> Really interesting. I still have some doubts on Socket.io on large scale though!</comment>


Google CEO tells employees return to office won't happen until at least June 1 - <AUTHOR> https://www.cnbc.com/2020/04/28/google-ceo-says-return-to-office-wont-happen-until-at-least-june-1.html <comment><USER2> Genuine question: do people really expect to be back in the office at all this year, given how high the risk is and that those jobs can almost certainly be done from home? Why?

<comment> m-ee Not all jobs can be done from home, and it's not all or nothing. I work with hardware, just having one person be able to work alone in our lab would be a massive improvement as there's test equipment we couldn't move. I don't see much risk there. Others might face similar challenges accessing materials (physical or virtual) that need to be kept somewhere secure.

EDIT: Also need to remember the challenges for parents. It can be incredibly hard to be productive at home with kids around, and ability to trade off the responsibility of watching them and working would be huge.

</comment></comment><comment><USER3> Natural given bay area shelter in place extension to end of May

</comment><comment><USER4> What was the reason GOOG didn't have work from home before March?

<comment><USER5> Because there were hardly any Covid-19 cases in Santa Clara County (where Google is based) before March

[https://www.sccgov.org/sites/covid19/Pages/dashboard.aspx](https://www.sccgov.org/sites/covid19/Pages/dashboard.aspx)

<comment><USER4> I meant, why can Google run now with WFH, but they didn't allow it before. That is, what was the motivation for forbidding WFH?

<comment><USER6> Wild but fun speculation: WFH decreases housing prices because people can disperse further. The higher the tenure & seniority within a company, the higher the likelihood of real estate ownership (both primary and rental properties). There is a conflict of interest in having more control on WFH policies and seeing your house not appreciating as much in value or not bringing as much rent. I wasn't able to find data on this but it is hard to imagine any Bay Area exec not having real estate positions in the area.

More realistic reason: Middle management struggles with perceived lack of control and justifying their existence through wider WFH. Their business is their reports, and there is simply less control surface exposed through WFH to them. It is harder to carry out impression management from home. It is simply a higher friction, higher anxiety scenario. Ultimately they influence WFH adoption, whether at team-local levels or upward influence in company-wide decision making.</comment></comment></comment></comment>


"In Haskell we think for quite a long time before starting typing" - <AUTHOR> http://hackage.haskell.org/trac/ghc/ticket/4864#comment:1 <comment><USER2> A) It's kind of presumptuous to show up in an esoteric lisp community and ask them to adopt C-style comments for your sake.

B) "We think for a while before typing" is the worst excuse ever for a hard- to-type construct. Why not just make it easy? Especially for comments. Make bad code hard to type.

<comment><USER3> "A) It's kind of presumptuous to show up in an esoteric lisp community and ask them to adopt C-style comments for your sake."

haskell isn't a lisp.

<comment><USER2> I'm not sure whether to make the haskell strongly-typed joke or the functional programming snob joke :)

<comment><USER4> Just let lazy evaluation deal with the problem.

</comment></comment></comment></comment><comment><USER5> I was wondering how the waterfall model would be justified when the pendulum started to swing back from manic styles like XP and TDD. The idea that you can't play around with your code and experiment with it right away before thinking too hard is just silly. Many of the nice points about functional languages are precisely that iteration time can be really low. A dev should smack this person for messing with the bugtracker of a project that should be better than this.

<comment><USER6> bzflag!!!! This is like seeing someone you kind of know at an airport far away from home. please forgive the off-topic post.

</comment></comment><comment><USER7> did anyone else get a double meaning of typing?

I was thinking: well, of course you have to think, you have types! You have to align the universe to a representation which is no easy feat.

</comment><comment><USER8> That made me want to read a bit more about comments.

[http://www.gavilan.edu/csis/languages/comments.html#_Toc5371...](http://www.gavilan.edu/csis/languages/comments.html#_Toc53710127)

</comment><comment><USER9> Encoding system information into a string should be a last resort. That's why a good type system, where you can encode _EscapedString [Char]_ versus _UnescapedString [Char]_ as strings of different types, where you have to work hard to do a safe-to-unsafe cast, that good type system is vastly better than prepending esc and unesc to variable names, and hoping that you don't mess up.

Making commenting easy is like spending a lot on orphanages; good in the short term, but causes problems in the long term. You want to document as much of your intent in code as you can, and Haskell makes that easier than, say, assembler.

</comment><comment><USER10> That's no doubt true, but that can only get you so far. If you have to work with some buggy system over which you have little or no control, which is often the case, you are limited in how much you can think ahead. The more bugs in the system, the shorter you can think ahead.

This may be why so many Haskell examples are math-centric: it allows you to look the farthest into the distance.

<comment><USER11> I always thought that Haskell programmers provided so many math-centric examples because the language provides one of the cleanest mappings of math to code available in any language. You might as well code to the language's greatest strength.

I'm curious as to what you have in mind as a credible example in Haskell of a "buggy system over which you have little or no control." Haskell is such a marginal little language right now that it hasn't attracted the same level of programmer mediocrity as, say, Java has.

Also, the typing system tends to all but eliminate common errors in other languages -- your segfaults and NPEs and buffer overflows. Haskell tends to front-load the pain of development. If your code compiles, you can reasonably expect that any bugs in the code are due faults in your own reasoning rather than failing to accommodate some unplanned-for side-effect (like the uninitialized pointer in C). And unless you've made the mistake of locking up all your logic within the IO monad, finding and correcting these faults tends to be more straightforward, thanks to the math-like syntax.

My experience with Haskell is that, as hard a language as it is to learn, it is remarkably easy, once learned, to think in.

<comment><USER12> _common errors in other languages -- your segfaults and NPEs and buffer overflows_

I never see those in Smalltalk. I'd be surprised if that's an issue in Python, Ruby, or Lisp.

(But the number of DoesNotUnderstand errors in Smalltalk is quite impressive. This is why XUnit unit testing was first developed in Smalltalk. Unit testing with good code coverage is the only way to reliably prevent those.)

<comment><USER11> > I'd be surprised if that's an issue in Python, Ruby, or Lisp.

I'd be very surprised if there weren't similar issues in these languages, since these are all duck-typed and the topic at hand is "bugs prevented by rigorous up-front type checking." I don't have extensive experience in any of the above, so I couldn't include any examples of errors they are prone to.

<comment><USER13> Ruby's method_missing, the equivalent of Smalltalk's doesNotUnderstand:, is a plague on Ruby programmers. It might mean something returned nil, it might mean the wrong type got passed or returned, it might just mean that you forgot to include a module — but you will run into them more times than you can count while you're developing a Ruby app. (Or at least I will. I don't know. Maybe everybody else has better luck with their libraries or is just more studious than I am.)

<comment><USER12> Do you have unit tests with good code coverage?

</comment></comment></comment></comment></comment></comment><comment><USER14> Is this a pun on Haskell's strong static types? :)

</comment><comment><USER15> On my German keyboard, -- is actually easier to type than //.

<comment><USER16> And on my Swedish keyboard. It's right next to . and I don't need to hold in shift to type it.

I even need to press shift+7 to write /, so I'd actually prefer --.

</comment></comment><comment><USER17> I used to _have_ to think a great deal before typing, with Haskell and ML. Nowadays, I _should_ think a great deal, but the thinking goes on at a higher level in the design than I'm used to. Of course, I could be prototyping.

But the point is, there is light at the end of the tunnel. No one told me about that. These were languages that were supposed to discourage wild hacking. And they do. But that doesn't keep you from prototyping, or alternately, writing bad APIs.</comment>


TypeScript vs. Flow, part II - <AUTHOR> http://djcordhose.github.io/flow-vs-typescript/flow-typescript-2.html <comment><USER2> Neither

<comment><USER3> What do you suggest for static typing on the frontend?</comment></comment>