Solid – A declarative JavaScript library for building user interfaces - <AUTHOR> https://github.com/ryansolid/solid <comment><USER2> I recently rewrote a small toy project from Preact to Solid. It went from spinning my fans and consuming over 25% of my cpu to practically idling. Solid is legit. I could have optimized my Preact, but I didn't have to think of it with Solid. Same is true of Svelte.

Edit: I see the author is here, and lots of typically negative comments are being thrown at him. Ignore them and keep up the good work! We need people like you to push performance forward.

<comment><USER3> This sounds like a really atypical project. Consuming 25% of your CPU is a lot! I hear people mention those kinds of numbers only for Slack, which does have a lot of functionality.

I'd just point out that for the average project, the main advantage is that with something like Solid or Svelte, it will load in less than a second, vs. a few seconds for React, especially for something simple like a blog where you don't want to think about perf or optimize much.

<comment><USER2> It is atypical, yeah. It's a speed-reading app, so it flashes a new word on the screen every nth of a minute, where n is how many words per minute you want to read.

Still, I'm tired of using a normal web application and feeling the UI lag when I type, etc. I suspect that if you start off with a project like Svelte or Solid, you'll have a longer runway on your app before you get to that level of suck.

</comment></comment></comment><comment><USER4> Solid is another smart-compiler, virtual-dom-less frontend component building library.

If you're wondering how this is different from Svelte, the author has a Medium post on it[0].

[0]: [https://medium.com/@ryansolid/javascript-ui-compilers- compar...](https://medium.com/@ryansolid/javascript-ui-compilers-comparing- svelte-and-solid-cbcba2120cea)

<comment><USER5> One thing the article doesn't really dive too far into is that Svelte is template driven, while Solid is more about React's jsx-drive-components. As I've used both style methods for years, I think I'm growing fond of Svelte's template approach as the best general purpose solution. This is because usually my pages are 70% static and can be expressed as simple nearly vanilla web-idiomatic html pages. Being able to keep all that static code as close to vanilla web really helps to reduce other overall complexity, with the added benefit of being able to copy html with css from anywhere into my project, and then add dynamic behavior without "rewriting" basic html into jsx (which can lead to subtle bugs).

<comment><USER6> We use JSX identical to a Template DSL more or less. We don't use JSX at all like React does. That's why Solid so performant. It does similar thing to Svelte. We don't compile it into HyperScript. You can copy and paste html with one exception (void elements JSX makes you close input tags etc). But otherwise I support all the standard stuff pre-adding the dynamic bits. Solid supports `class` and `for` and `style` strings etc..

</comment></comment></comment><comment><USER7> I've been playing around with your library for the last hour and so far it's excellent, pretty what I had hoped for after working with React for a while. The performance of individual renders is one area of improvement but I think the main contribution is the clarity the update model provides.

React works well until you try to avoid re-rendering and then it really falls appart. For example, updating a context re-renders the whole component chain from producer to consumer, and trying to block useless re-renders with shouldComponentUpdate easily leads to mistakes where children don't update when they should. Since React rendering use lazy evaluation of JSX expressions, tracking who exactly updates and when is much harder than what it might seem initially (akin to tracking mutations in a language with lazy evaluation). As this library actually tracks dependencies and only re-renders what you want, all of this bloat is avoided. One aspect that impresses me in particular is that JSX expressions actually return real DOM nodes, making it easy to keep references to them for imperative operations (not a big deal but so much nicer than React refs).

I'm wondering why you opted for the setState API rather than a nicer imperative API like Mobx. From what I can gather, state changes are tracked by diffing? Why not just return a proxy?

<comment><USER6> I do return a proxy. It's just readonly. I really like the unidirectional data flow and explicit read write segregation of react. This adds so much control without having to add Framework like control mechanisms. I know it isn't easy, but it something that makes the solution elegant in the end. I think that passing data should also mean the choice of passing the ability to update it. That is a problem I have with almost all reactive implementations in libraries today. I think React has that part just right.

<comment><USER7> I'm not sure I understand your argument in favor of setState correctly. By splitting the state into two parts (a read-only view, and a setState function to update it), isn't the opposite being accomplished? It is now possible to pass the data without passing the ability to update it, or vice-versa. Which could very well be desirable but could be accomplished by other means (i.e. leaving to the parent the choice of passing a read-only or a mutable proxy). Settings aside the superficial issue of syntax, the main thing I dislike about the setState interface is for updating things like lists, where you need to perform a full copy just to insert one element. That being said I haven't yet looked into how exactly you handle lists.

<comment><USER6> I mean it's basically the same thing as you do with React. You create lens functions more or less to handle get/set over the state object. Solid's setState has a lot more capability than React's handling nested updates with an ImmutableJS or Immer inspired API. The clever part here is immutable libraries already have API patterns to describe mutation so I just apply them here. So instead of spreading everything and cloning you keep the mutation locality for performance but keep the control of immutability.

Also don't be worried about copying the array that much. I'm doing that in the JS Framework Benchmark and it's still about the fastest with 10k items. The real key is identifying where you don't need to update the list at all just the items in it. That being said you can do an update without copying the array like this:

setState('list', state.list.length, newItem);

Granularity of performance isn't a silver bullet. Being fine-grained doesn't necessarily make everything faster (especially creation). The power is that granularity is arbitrary so it can be maximized to the type of situation, completely independent of component structure.

<comment><USER7> That makes sense. It is mostly the O(n) rerendering which is expensive, not the array copy. With regards to superficial/syntactic issues now, I just don't see the advantage of:

`setState('list', state.list.length, newItem);`

over

`list.push(newItem);`

Considering that the two operations can be otherwise equivalent when using proxies (from what I understand).

<comment><USER6> It comes down to control and immutability. I know not everyone agrees with this but I believe it's fundamental.

You can use the "Immer" syntax of setState if you want:

setState(s => { s.list.push(data); });

But in some cases it is more expensive. Like a splice will per row will trigger the proxy to tell you they've all shifted a position. Where as just setting the array only hits the proxy once. Sure Solid batches the updates from the call but it's still unnecessary tracking. Solid lazily decides whether state should be made into a reactive atom based on whether it is referenced in a tracking scope.

</comment></comment></comment></comment></comment></comment><comment><USER8> The negativity in this comments section is astounding.

Personally, I was originally introduced to it by someone in the Mithril.js gitter chat, and think it's a great project. I wish the Solid team the best and look forward to trying out Solid in my next toy project. The performance benchmarks and relatively clean API are truly impressive.

<comment><USER6> Thank you for your kind words. It can a difference to have the kind words of a few strangers. I'm used to these sort of responses now. And welcome it to a certain degree. Insightful comment can lead to interesting discussion. Ignorant ones gives me a platform to educate.

But it wasn't always like this. Leo Horie from Mithril was always supportive early days when it seemed I only was receiving this sort of "feedback" on reddit if any at all.

<comment><USER9> Disclaimer: I'm that Leo ^ :)

Unfortunately, JS fatigue is real and it can be challenging for someone who has their hands full with just relearning new React idioms to also evaluate the dozens of other libraries out there, so it's easy to miss a gold nugget.

For those who are not seeing the value proposition here, think Svelte, but where the "reactivity magic" is encapsulated via Components to still allow React-like "it's-just-JS" component code, while also getting rid of a lot of runtime overhead and the complexities associated with trying to optimize a virtual dom (as has been the recent direction for React).

One great benefit over Svelte with this approach is that you can use Typescript in templates (something that Svelte still is not able to do).

Solid's performance claims to fame are also legit (i.e. it doesn't sacrifice good devexp, good engineering, unlike many of the top performers in the stephen krause's benchmarks).

The only thing I wish was better is docs. It starts off "spilling its guts", so to speak, and while that is an ok way to explain why Solid is different than others and to garner interest from library authors, it's also not super beginner friendly. One cannot, for example, easily find docs for `<For>` even though it's analogous to core syntax if we were to compare to a programming language. Putting a follow-along tutorial upfront would go a long way.

<comment><USER6> Thank you as always. Early days spent so much time justifying things, everything became these expositions. Time to tighten up.

</comment></comment></comment></comment><comment><USER10> People loved React because of VirtualDOM.

Now JS libraries advertise themselves based having no VirtualDOM.

Can someone explain this to me?

<comment><USER11> People loved React because it solved a problem. They just happened to solve it using virtual DOM.

but theses next generation frameworks are showing that there's a better way to solve the same problem.

<comment><USER10> VirtualDOM allowed you to update the dom with better performance than before. Is there now a better technique? Why is it better than VirtualDOM?

<comment><USER12> This is a good talk on the matter from the creator of Svelte himself, if you're interested: [https://www.youtube.com/watch?v=AdNJ3fydeao](https://www.youtube.com/watch?v=AdNJ3fydeao)

Basically, it boils down to moving from tracking the DOM state in a VirtualDOM to tracking what DOM updates can happen at the compile stage and then just doing those exact updates to the DOM.

<comment><USER13> My annoyance with that talk is he never compared Svelte with multi-threaded React. It was the natural next thing to look at but it was like "okay my point stands let's move on" haha.

<comment><USER14> Well maybe we should compare apples to apples. With React you go down a rabbithole of workarounds around their initial concepts (like hooks) until you wonder why you chose it in the first place.

<comment><USER15> why do you consider Hooks a "workaround around [React's] initial concepts"?

<comment><USER6> I think Hooks are genius truthfully. But they are definitely shoehorning something into a place that didn't expect it. You are calling these render functions with the purpose of creating new transformations every cycle, and the injection mechanism has to include the initialization the first time. So you basically have these slotted things that allocate memory every time to just use what's cached most of the time.

Now don't get me wrong I've benchmarked Hooks like crazy and I don't think they are much consideration on performance at all. It's just the mental model of always update on the outside with bubbles of things that don't update creating these closures is a little unnatural. By comparison the mechanism they ape (fine grained reactivity) works exactly the opposite way. You just need to be aware the stuff outside doesn't update. Wrap what needs to be updated. Done. There are no out of date closures. No inconsistent mental model. It's as straightforward as registering event handlers.

Still I have to admit the solution is genius. They have managed to get 90% of the benefits with simply repositioning things. At one point this was one of my biggest arguments against React. People didn't appreciate it before hooks. But can you imagine knowing you could write applications this way years ago and trying to convince someone using React classes there was a better way? I just sort of gave up and did my own thing.

<comment><USER15> thanks for the explanation! though i have to say i only have a vague idea of "fine-grained reactivity", any pointers for reading about this or systems that work this way?

in particular, i don't quite get this bit:

> _By comparison the mechanism they ape (fine grained reactivity) works > exactly the opposite way. You just need to be aware the stuff outside doesn > 't update._

inside/outside of what?

PS. my yet undeveloped pet theory is that hooks are (somehow) something like half a monad/algebraic-effect-thingy... though they're probably too tied up with the render cycle to analyze them this way

<comment><USER6> I have the article for you: [https://indepth.dev/finding-fine-grained- reactive-programmin...](https://indepth.dev/finding-fine-grained-reactive- programming/) It's a bit dense at times but I try my best to cover the whole spectrum and how it relates to familiar libraries.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> Maybe I just need to spend more time studying the material, but I struggle to see how these precompiled frameworks can handle any arbitrary state change one might write into their JS rendering logic.

For example: suppose I want to take an arbitrary JSON structure, walk the entire JSON tree, and render it on the page as a tree of nested elements - i.e. a new subtree of divs for each array or object. None of that layout is known ahead of time, and it can take any shape - be any depth, breadth, etc. Intuitively it seems like very little can be known ahead of time for compilation purposes. Can Solid handle this case? Genuinely curious.

<comment><USER17> It's my understanding that regardless of the complexity of your custom JSON data at some point while parsing the tree you have a line that says "if obj is of this type, then render this component for this node", all Svelte/Solid etc need to know is that this is the line where a Component is being assigned to a variable that is going to be rendered in the template.

Or are you saying you want a layout rendered from JSON without first defining the possible components as Svelte/Solid/React components etc? As I think that defining components explicitly is a central part of all of the front-end frameworks, compiler or otherwise?

<comment><USER18> Consider the following pseudo-code:

        list2 = bubble_sort(list1)
        render(list2)

Now suppose the user deletes one item in list1.

The question is now:

Will the update trigger a new bubble sort?

Will the update do something smarter, like just delete the DOM element?

<comment><USER17> There's usually no render function to call in these types of frameworks as far as I understand (my experience being a little Svelte).

I imagine in your scenario the psuedo code to achieve what you want would be written.

      list2 = bubble_sort(list1)
      removeItem = () => delete list2[random index]
      ...
      <for each list2 render div>

The compiler will see a change to the list2 variable anywhere that removeItem is called and annotate the code to make the appropriate changes to the dom in the function call and the bubble_sort line will never be re-run unless it was explicitly added to the removeItem function.

<comment><USER18> Note that the item is deleted from list1. The framework should (I suppose) track that list2 depends on list1 through bubble_sort(). Are the dependencies implicit? Or should they be declared explicitly?

<comment><USER6> Generally implicitly either through proxy or get method read. Solid provides an explicit API as well.

</comment></comment></comment></comment></comment></comment><comment><USER19> Good thing this came about. I looked through various JS frameworks for web components a year or so back. I now can't remember did I find Solid had web component support then. I see it has this support now, with Solid Elements. I remember reading Solid articles at the time from Ryan's blog and being impressed. Now it's time to take another look.

Also, I see it's small in size and ES module friendly. Very nice.

<comment><USER6> Web Components were what originally led me to keeping the Component side light in Solid, which eventually influenced some of optimizations in that area. I hope you find things have progressed nicely in the last year.

</comment></comment><comment><USER6> Here is an introductory summary of SolidJS: [https://dev.to/ryansolid/introducing-the-solidjs-ui- library-...](https://dev.to/ryansolid/introducing-the-solidjs-ui-library-4mck)

<comment><USER20> My 2c of insight: I found Svelte's docs & examples greatly sweetened the on- boarding.

While I presume writing specs is a boring collateral, a friendly / bitesized / WISYWYG documentation would make a world of difference for the enthusiastic but less-than-ninjas of us.

The smarter kids can catch up faster, and some might not bother, already do react/vue. I personally found with Svelte a way tamer learning curve.

<comment><USER6> I agree. I would love to do more. The truth is there is just so much to do. It's hard to find a balance between writing cleaner docs and say solving Async Hydration with Suspended Components. I had the luxury early on to prioritize the latter which is why Solid is so feature rich given how much of it needed to be researched and built from scratch. I always knew it would catch up with me. But that's a good problem to have.

<comment><USER21> Clear Docs is important because they say we spend 1x developing a product and 10x marketing it. In the developer experience world, docs are marketing.

Also, polished product and polished code deserve a polished set of docs. Just sayin'!

<comment><USER6> Volunteering?

<comment><USER21> Ahahaha I know it sounds like that. But I realize what a massive task that would be. Am I volunteering? No. I appreciate your invite.. I'll email you if I change my mind.

I think a cool thing would be if the docs site was made in it. Self documenting.

</comment></comment></comment></comment></comment></comment><comment><USER22> This (and similar libraries) is the way forward.

I joined the Svelte camp a while ago so I'm unlikely to try Solid anytime soon, but had I started with it I wouldn't complain, because the value proposition is the same: an abstraction which is runtime-inexpensive both in terms of CPU usage and bundle size.

<comment><USER23> I think, the "3rd Age of JS" [1] of frontend libraries are running directly in the browser without a build step. Like in the beginning. ES modules in the browser paves the way.

Svelte and Solid are actually the pinnacle of the "2nd age of JS".

[1] [https://www.swyx.io/writing/js-third- age/](https://www.swyx.io/writing/js-third-age/)

<comment><USER6> I read that article a few weeks back. It's interesting. I see the desire to lessen on tooling but it is going to be hard to match what these libraries are doing purely runtime. I know people want to get there again. But I think we are more likely to see lighter dev methods and then when it comes to actual production the real advantages of compilation and bundling.

</comment></comment></comment><comment><USER24> There is already a project named Solid led by Tim Berners-Lee: [https://solid.mit.edu](https://solid.mit.edu)

<comment><USER25> This is interesting (I'm doing something similar in a specific domain) but there is a bunch of issues: very scarce documentation, funded by Quatari money, and more importantly built on bloated, low adoption set of Semantic Web specs. Heck, the tutorial even acknowledges[1] "If all the above looks terribly complicated: that's because it is."

[1] [https://solidproject.org/for-developers/apps/first- app/4-dat...](https://solidproject.org/for-developers/apps/first-app/4-data- model)

<comment><USER26> Agree with the point about SemWeb. AFAIK, RDF/OWL/SPARQL is kindof a long-term pet project of TBL's, and now with SOLID IMHO he's kindof reusing parts of it as a 2nd chance to finally become mainstream (with weaving and creatively interpreting specs as is typical of SemWeb). What SOLID wants to achieve, though (a federated, less centralized web) is too important an initiative to let it become a case of puzzling out an utopian stack based on tech that has failed mainstream adoption, so unfortunately can't be taken seriously, and seems more like a project for fundraising TBL's pet project. Saying this as someone who has just recently worked with SPARQL and graph DBs in bioinformatics which is one of the domains where it actually has gained traction.

</comment></comment></comment><comment><USER27> I personally have only had substantial experience with react (and its hooks), but the replacements for hooks in this library look very exciting to me, though I'm not sure I fully understand them on a first reading. One thing that react hooks require is the placing of hooks at the top level of a function, which precludes dynamically creating hooks in a loop, or lists of effects. While usually there is a way to achieve whatever you're trying to achieve anyway, it's still a bit of a restraint on what you can write with React. I haven't tried Solid yet, but if its hooks are nestable and composable as the Reactivity page says, then this could enable some patterns that were previously impossible with react hooks.

</comment><comment><USER28> as an ex frontend developer. this looks like a great library. i'm sure people won't understand, why this exists i.e JS fatigue. reason, being the current libraries don't solve all problems. till you've libraries that have good cpu performance, no build steps, great syntax. people will keep spinning out JS libraries. anyways great big-up to the author.

</comment><comment><USER29> I am digging this. The main issue I personally have with svelte is that it goes into a completely different API design than React.

The closeness with the React design makes it better than svelte imo.

<comment><USER6> Thanks. I get criticism like "Why even make this? just use React." But it's so different. Yet I didn't want to throw everything away. People forget React came up when there were tons of libraries with similar reactive approaches and won our hearts and minds. It does a lot of things purposefully and it does those things well. We need to learn from the past it we are doomed to repeat it.

</comment></comment><comment><USER30> Can you use react components with it? All the libraries of beautiful components are the main reason why I use react. Like I know you can but with cross component comms and stuff.

Does the state thing have the same gotchas as react hooks? Not a big fan of how that's impl'd in react.

<comment><USER6> No Hook Rules. Hooks are an amazing feat by the React team as they basically come so close to emulating the behavior here with running through top-down VDOM reconciliation. But they can't be nested etc.. This reactive approach is similar to MobX or Vue Composition API and doesn't have those constraints.

That being said for the same reason. No React Compat. The library doesn't work even remotely similar. People have used them together, but this is no straight swap in.

<comment><USER30> Might be a good feature. One idea might be a standard way of wrapping a react component so that it uses an embedded iframe / postmessage to post messages back and forth with solid. Tho personally I would like to see this approach to managing state win: [https://github.com/colshacol/storage- changed](https://github.com/colshacol/storage-changed)

<comment><USER6> Solid doesn't re-render Components over and over.. so integrating React is as simple as wrapping a `createEffect` calling `React.render` on a ref. The other way around is a bit harder, but been at this for a while here is a codesandbox with a HOC for that: [https://codesandbox.io/s/solid-react- hoc-8m2yd](https://codesandbox.io/s/solid-react-hoc-8m2yd)

If anything there is just so much to document.

<comment><USER30> Any comment on that storage-changed lib? I think that's a massively underrated abstraction for high level state / comms. I want it to be more popular. :)

<comment><USER6> It's interesting to wrap the persistence in there as well and it's lightweight so that's a plus. But someone also could use say Redux(or Storeon) and achieve a similar thing. The challenge of interopt is more with conflicting update/render cycle and props (especially children). For global storage any event emitter will do. Although one so browser native definitely has it's perks.

</comment></comment></comment></comment></comment></comment><comment><USER31> Is there dedicated DevTools support for Solid like there is for React, Vue, Svelte, and co.? If not, is there a convenient way to inspect state, props, and the component hierarchy?

<comment><USER16> I actually think this is extremely important. One downside of these compilation-driven frameworks is that they would, I assume, make it much more difficult to track with exactly how your code manifests at runtime, and would therefore make it harder to debug. Even setting that aside, I'm a strong believer that "frameworks" (contrasted with "libraries") have a responsibility to bring their own tooling, because existing tooling is less likely to be useful against the new concepts they introduce.

<comment><USER6> It's easier to just open up and debug than say VDOM views since you can see your dynamic expression (what's not updating) and just drop a breakpoint. The template structure flattens so you don't have this issue of nested children and what you are debugging is the actual DOM nodes. It feels more like debugging jQuery. But it is no replacement for good dev tools.

<comment><USER16> I guess what I meant is that VDOM views (at least pure-functional ones like React) can have a much clearer separation between the view logic and the state logic. I don't have to understand how the VDOM works because it's never entwined with my code that might have a bug in it: I'm just creating a data structure and handing it off. If there's a bug, it's in the creation of that data structure, which is 100% my own code. That hard barrier exists even at runtime. Solid seems like it deeply entwines the two in a way that's very clever and has performance advantages, but would also, I expect, come with a cost.

<comment><USER6> Yes it's all the same thing. Your data is reactive and an be modularized. The renderer is reactive with the DOM basically being a side effect. There basically is no renderer just a reactive system with different types of data. It means there is an incredible amount of flexibility and raw performance.

The tradeoff is rendering isn't particularly special. So the systems consciousness of specific render specific concepts requires additional consideration. There is no "onMount". There are reactive lifecycles but they aren't particularly tied to DOM updates.

</comment></comment></comment></comment></comment><comment><USER32> I'm skeptical about the way state can change from under you within the same execution of the rendering function. This type of mutability will prevent all the help that typescript normally gives for complex components.

Also if anyone has used it, do you have to use this pattern if you have derived state?

        setState({
          displayName: `${state.user.firstName} ${state.user.lastName}`
        })

If you simply do `const displayName = ...` in the component, will the component update properly?

<comment><USER6> Feel free to shoot any issues or discussions on our gitter or reddit. You are correct because it doesn't work like that. It works more like MobX. There is no render function that runs repeatedly. Instead everything is split apart granularity and only those pieces update.

If you want to have derived state. Simply wrap it in a function or use it in a JSX binding.

Ex.

const displayName = () => `${state.user.firstName} ${state.user.lastName}`

return <span>{displayName()}</span>;

or:

return <span>{`${state.user.firstName} ${state.user.lastName}`}</span>;

or:

// this expensive to calculate:

const displayName = createMemo(() => `${state.user.firstName} ${state.user.lastName}`)

return <span>{displayName()}</span>;

</comment></comment><comment><USER33> Really cool, I should have a serious look at this non-virtual dom thing. All the examples make it look like this project is dependable. Sorry for the plug but I somehow explored similar path when creating the Blop language, maybe the author might be curious: [https://github.com/batiste/blop- language](https://github.com/batiste/blop-language) Maybe I should get rid of the virtual DOM lib. I use?

<comment><USER6> It's not unexpected at all. I've had several template library writers reach out to me about the potential here. And there is some. The challenge is figuring out how to hide the reactivity in a way that your end users would be happy with but still benefit. I think it is an interesting challenge.

</comment></comment><comment><USER34> I'm glad to see continued experimentation in this space. I'd hate to think that React is the best we can come up with.

</comment><comment><USER35> HTML - A declarative markup language for building user interfaces.

CSS - A declarative, domain-specific language for styling user interfaces.

<comment><USER36> Solid - A declarative JS library for building highly-interactive, logic-driven user interfaces.

Better?

<comment><USER35> Short answer: worse.

Long answer: It is worse, and it all boils down to two phrases which I classify as "marketing speak". Marketing speaks aim is to impress and influence you, "technical speaks" aim is to inform and educate you. When shopping for a library or framework for your next feature or project, it helps to distinguish between the two. Usually any time you see a buzzword, you've stumbled upon some marketing speak. The buzz-wordy term "declarative" has been popularized by React, so I just thought I'd apply it to HTML and hopefully encourage someone to skill up on the web fundamentals (HTML, JS and CSS) before tackling JS frameworks to avoid disasters like this [https://stackoverflow.com/questions/42464888/how-do-i- change...](https://stackoverflow.com/questions/42464888/how-do-i-change-the- background-color-of-the-body).

> highly-interactive

What does this mean? Are you talking about video games? Because that is what comes to mind when I see the term "highly interactive".

> logic-driven

Aren't all programming languages logic driven? Or are there some feelings- driven apps?

</comment></comment></comment><comment><USER37> For the life of me, I can't understand why there is so much emphasis on the virtual-dom and dirty checking.

DOM manipulation is expensive, so a check is made to see if it really needs to be done.

If you're guaranteed to need an update, then this check is pointless. But this depends on what you're doing. Its really not something that's tied to the technical identity of any library. React, vue, etc, could probably also skip this step if they wanted.

Also, this will almost never be the bottle neck. It's really low down on a long list of other things that will have a bigger impact. Web dev is in a really bad state - you're supposed to have something like 1.5k nodes according to lighthouse because of all junk that browsers have to do now. That's a puny number of checks for the cpu to do.

<comment><USER38> The problem is more in the huge number of renders react does if you don't do everything perfectly. In a large application it gets steadily slower.

</comment></comment><comment><USER39> [https://github.com/ryansolid/dom- expressions/tree/master/pac...](https://github.com/ryansolid/dom- expressions/tree/master/packages/hyper-dom-expressions)

Looks great!

<comment><USER6> Yeah JSX has its clear advantages. But I wanted to offer runtime only solutions as well. Tagged Template Literals is still the best runtime only solution for Solid, but I've got HyperScript too. Just remember it's reactive so wrap expressions in functions. JSX compilation sort of hides this detail from you.

</comment></comment><comment><USER40> Can this be used with things like mobx/mobx-state-tree? Absolutely having a blast with MST.

Also, does lack of vdom mean a project like react-native could never really come from this?

<comment><USER6> It can be used with MST with a bit of interopt. As for native it's possible but would require different compiler output. I saw an approach with another library mind you that emulated DOM API over Native script and used the same compiled output for both. Probably not the best way but interesting.

</comment></comment><comment><USER41> > Whenever any dependency changes the State value will update immediately. > Each setState statement will notify subscribers synchronously with all > changes applied.

If two things change that both trigger a third thing to change, how does this efficiently prevent the third thing from updating twice needlessly? I'm imagining this becoming an exponential problem in real apps, where hundreds of components are re-updated needlessly at every UI interaction.

<comment><USER6> The reactive graph is a push/pull system as it updates similar to MobX. This is a great article on the subject: [https://hackernoon.com/becoming-fully- reactive-an-in-depth-e...](https://hackernoon.com/becoming-fully-reactive-an- in-depth-explanation-of-mobservable-55995262a254)

</comment></comment><comment> torb-xyz Is it possible to use Solid with just plain JavaScript/TypeScript (like using createElement with React)?

I generally find those far more readable than JSX (and is one of the reasons I think SwiftUI and Flutter code looks nicer than React).

<comment><USER42> It sounds to me that you are looking for Webscript: [https://mudgen.github.io/webscript/docs/](https://mudgen.github.io/webscript/docs/)

Webscript does work with SolidJS nicely.

<comment> torb-xyz Probably should have specified, but a big ting I'm looking for is sull TypeScript support in this regard.

Webscript looks really cool, but it doesn't look very TypeScript-friendly.

</comment></comment></comment><comment><USER43> One minor thing I might consider is more examples with animation in UI --- it's a place where most apps want to go but have trouble doing elegantly/performantly.

<comment><USER6> I agree completely. I left an early github issue open with some examples. It just isn't my forte. I've worked with frontend guys who were mostly CSS ninja's and we never relied on framework mechanisms beyond applying some classes etc. I just lack the base knowledge to know what the expectation is here. I know Svelte has a very impressive system. I could look at doing something similar with Solid just not sure where to start.

<comment><USER43> It's a dumb example, animated lists transition are kind of a good go to... [https://svelte.dev/tutorial/animate](https://svelte.dev/tutorial/animate) as is [https://dev.to/buhrmi/svelte-component- transitions-5ie](https://dev.to/buhrmi/svelte-component-transitions-5ie)

<comment><USER6> Yeah I guess I mean more I don't understand what it takes mechanically to support those types of transitions. It makes sense to me but I also feel like there would be a lot of details in a generalizable solution. Super interesting though.

<comment><USER43> I think that's exactly right. it ends up being a LOT of super specific, fragile code --- so kind of interersting thought to see if you can make them elegant/easy/emergent in the library/framework itself.

</comment></comment></comment></comment></comment><comment><USER44> This looks very interesting!

With new projects and languages and frameworks a good angle to evaluate is, "what's the debug story like?"

<comment><USER6> Yep. I agree in practice Solid has some work to do here. The basics are think are reasonable in that we are dealing with your expressions in the template and real DOM nodes. So just drop a breakpoint in that sucker. Sort of return to how simple that was in jQuery/Backbone days.

It never is that simple mind you. I have an open issue around Dev Tools etc... We need to do better given the expectations of modern JS libraries.

</comment></comment><comment><USER45> Essentially react without virtual dom?

<comment><USER6> Syntaxually and philosophically. Implemention-wise it's more like MobX or Vue style reactivity without a Virtual DOM. It takes compiled reactivity past the localized component model of Svelte to new(ish.. the library has been around for a few years) heights in flexible templating with JSX and unparalleled performance.

The update cycle is the exact opposite to React Hooks. With React your Component needlessly re-renders over and over and your Hook dependencies explicitly whitelist change. With Solid your Comoponent is a basic function that executes once closing over state with it's Hooks, which are the only thing that run over and over as needed when state changes.

</comment></comment><comment><USER23> _" Using JSDOM or similar we can run Solid on the server"_

Doesn't sound very promising tbh.

<comment><USER6> I've been working in this area. Solid now has string rendering on the server without DOM emulation. I'm just one person so I went with what was cheapest first.

<comment><USER23> Nice, thanks for the quick reply!

<comment><USER6> Warning performance there isn't stellar there yet but it is my current active area of research.

</comment></comment></comment></comment><comment><USER46> How hard would it be to get this working with React Native backend?

</comment><comment><USER47> @ryansolid What minimum browser versions does the library support

<comment><USER6> As is probably evergreen browsers to use all features. I use proxies which are notoriously hard to polyfill. It is possible to avoid them but I was not taking IE in mind after that. So while possible to support older browsers with Babel unclear what all the polyfills that would be necessary.

</comment></comment><comment><USER48> Solid looks like Surplus.js mix react.js

<comment><USER6> Yep more or less. I was working with Adam, Surplus' author, for a bit before he didn't have time to work on the project further. I've take a different tact now with the reactive system and improved the rendering technique a bit. But he definitely deserves the credit for pioneering the JSX approach 4 years ago now. My initial JSX work was generalizing it for other reactive libraries and then it just grew to this.

<comment><USER48> I see Solid uses proxy to 'get' and 'notice update' the state. This seems providing a better DX than s-js. However, Solid require developer to explicitly use 'react style/hook' to update the state.

Why not also use proxy to 'set' and 'notice update' on the state?

<comment><USER6> I'm big on read/write segregation and explicit mutation. With simple signals you have this naturally. Once you move to a nested tree you can lose this. Keeping this control allows us to adopt immutability patterns and enforce unidirectional flow. To me this is the most sane way to deal complex reactivity.

<comment><USER48> I agree, then the way to read and update state with dependency tracing in solid seems meeting the sweet spot of the s-js and elm/react style.

</comment></comment></comment></comment></comment><comment><USER49> All these transient JS libraries all for what? Making state updates... _easier_? It's already easy with what's available from the standards.

</comment><comment><USER50> Explain the big picture abstraction differences between this and React in two sentences? I don't care about compiler vs interpreter implementation details.

<comment><USER6> With React your Component re-renders over and over and your Hook dependencies explicitly whitelist change. With Solid your Component is a basic function that executes once closing over state getters with its Hooks, which are the only thing that run over and over as needed when state changes.

<comment><USER43> Very cool work! And great performance. Funny - during quarantine I've been playing with the OPPOSITE. A no build, runtime only reactive JS engine...

Would love to compare notes - you can check out (very much WIP progress) at [https://github.com/sreekotay/reefer](https://github.com/sreekotay/reefer)

It's been only a few weeks of fun... but REALLY interesting problem space. I use a DOM memo-ish approach to help with performance...

<comment><USER6> Awesome I think so too. I love exploring this space in general. It's really interesting to see how you can model problems this way. Reactivity isn't a solution to a single problem but a way of modelling any problem

Solid actually can work runtime only too but I do put most of my effort on the compiler since I can use it to overcome most of the classic shortcomings of the reactive approach performance wise (and DX wise) with a bit of consideration.

</comment></comment></comment></comment><comment><USER51> At this stage, web components is no more than a glorified template string + a way to fill it, it seems?

Now only name it template separate it out into its own file, and build an "engine" around it. Then we are almost back, where we came from with backend rendering, which we should be doing anyway.

I've yet to see the JS framework that takes usability seriously and outputs a noscript block (during development) for me to copy paste and get the functionality for anyone disabling JS.

As it stands many web devs only see the JS enabled side of things and then are too lazy to, or not capable of implementing the noscript part. Or they are not even aware of the white page one gets for their oh so cool React apps, once JS is deactivated. It is very unprofessional amd exclusive, I must say.</comment>


New web apps are like new words: widespread adoption is difficult - <AUTHOR> http://factore.ca/on-the-floor/15-the-challenge-of-creating-successful-web-applications

<comment><USER2> What an excellent article. This should be required reading for anyone looking to get into web application development or marketing. I can't tell you how many half-baked ideas I've listened to where all they need is a "developer".

</comment><comment><USER3> I always enjoy it when people have "going viral" as an important step in their business plan because it serves as a great warning that you're not going to get paid.

</comment><comment><USER4> I would like to think of web apps being kinda like memes rather than words. Word's dont go viral, memes do.

<comment><USER5> I'm not a linguist, but I'm pretty sure you're wrong.

<anecdotal_evidence>I've seen slang terms go viral at a party in minutes or through a social group in a matter of weeks. </anecdotal_evidence>

</comment></comment><comment><USER6> I wonder if it's also because people name their apps with made-up words.</comment>


A Globemaker Navigates a Digital World - <AUTHOR> https://www.atlasobscura.com/articles/globemaker-digital-cartography <comment><USER2> I've kind of felt, that modern GIS software is very much still tied up to 2D map sheets and projections and their distortions. Why not entirely move to 3D globe based representations and processing?

<comment><USER3> Unless you are talking about VR, the visuals are going to be viewed on a 2D screen. And to get the 3D globe on 2D screen you need some sort of projection.

<comment><USER2> But that screen projection will not have effect on calculations performed on the globe. Otherwise also I fail to see why this is a valid argument. The viewpoint usually is manipulatable to view the globe from any desired point of view.

<comment><USER4> What you are proposing in practice is to always use some kind of perspective or orthographic projection, but make it easy for viewers to change the projection parameters (by rotating/zoomming).

But an orthographic projection is strictly inferior to other projections for essentially every purpose by every criterion except "draw a picture of what the earth might look like if viewed from space".

* * *

As for "calculations": these should not be done in terms of latitude/longitude if it can be avoided. Personally I think we should switch to using stereographic projection as an internal data format. Here's my draft writeup [https://observablehq.com/d/5e75dd8e56fe255f](https://observablehq.com/d/5e75dd8e56fe255f)

<comment><USER2> I am not suggesting using an orthographic projection. What I was suggesting was using a 3d earth model, which will be rendered on the screen using a perspective projection.

Does not the earth viewed from space indicate true shapes, distances, and areas?

<comment><USER4> > _Does not the earth viewed from space indicate true shapes, distances, and > areas?_

Of course not. A perspective projection distorts "true" shapes, sizes, and distances more than any other common choice of map projection, and in addition leaves more than half of the globe out of sight.

<comment><USER2> But in an interactive display that is not of concern. It allows us to rotate and move vantage point to see different parts of the globe, as much as a real globe would allow someone to peruse.</comment></comment></comment></comment></comment></comment></comment>


The app boom is over - <AUTHOR> http://www.recode.net/2016/6/8/11883518/app-boom-over-snapchat-uber <comment><USER2> I'm surprised it took so long. Integrated experiences almost always trump separate apps as far as user experiences go. I'm looking forward to more consolidation.

</comment><comment><USER3> Am I wrong or this just shows that downloads of the big old apps that are around since half a decade are slowing down/stagnating? It doesn't show any number about evolution of apps download overall...

Actually also shows that more recent apps (uber, snapchat, AirBnB, Hulu, HBO) is going up.

How does all this adds up to verify the claim of the headline? What did I miss here? :/ Is that just yet another catchy/fishy HL?</comment>


Show HN: Studenture - Education Search Engine - <AUTHOR> http://www.studenture.com/

<comment><USER2> Nice to see fellow Chennaite launch something on HN. Congratulations on launching.

The results specific to universities or colleges are nicely formatted.

It would help if you have an example typewritten in the box to help get me started. I was initially looking at a blank screen not sure what I need to search for, considering that I wasn't exactly looking & was seeing it through Show HN.

What is the intent of the site? I mean who is your target customer and how would they find studenture in the first place?

<comment><USER3> Hi Krish . thanks . you can search the same way how you search in google. Mostly degree courses & institutions to start with. eg , list of universities in India, mba in finance , BS in criminal justice , top 10 .... You can narrow them down by region etc - by default it will list the country of your IP as preference. if possible kindly leave your email id in the feedback form , so i can get in touch with you as we progress.

</comment></comment><comment><USER4> This is pretty cool. One thing that had me confused was the legend at the bottom of the search result, eg: US - U. The colour of the circle is different for each one. Is it random, or does the colour signify something?

And like Krish mentioned, it would be good to have the examples you mentioned in your reply shown in light gray as a hint text in the search box. It can clear when the user clicks on the box or starts typing.

<comment><USER3> Hi Siddhartha , thanks for your feedback ... the first legend is the country code , second one is the institution type ... colors are randomized for now .. ur suggestion on the placeholder in search box is taken and will surely implement. thanks .. Kindle fill in the survey too.. good day to u ..

</comment></comment><comment><USER5> Maybe I have missed something, but other than being a 'search engine,' I'm not really told your site is supposed to be used. Is it good for finding courses? Is it good for finding explanations on a specific topic such as Random Forests?

It looks like a great tool but I don't really know what I'm supposed to be searching for.

<comment><USER3> Hi there ... thanks . you can search the same way how you search in google. Mostly degree courses & institutions to start with. eg , list of universities in USA, mba in finance , BS in criminal justice , top 10 .... You can narrow them down by region etc - by default it will list the country of your IP as preference. if possible kindly leave your email id in the feedback form , so i can get in touch with you as we progress.

</comment></comment><comment><USER6> I'm not sure what exactly to do with this site. Maybe there should be an explanation on the main page? Do I search schools? Classes? Degrees? What's the point?

<comment><USER3> Hi David .. we are education search engine .. you could search the way you do in google .. yes , you can search for degree programs and universities for now .. we are cooking a lot of stuffs behinds studenture to make it more informative.. Kindly leave your feedback & ur email id in the feedback form (in home page) to keep you posted as we deliver new features .</comment></comment>


Ask HN: thoughts about NYT Page Not Found page - <AUTHOR> http://www.nytimes.com/2012/04/01/business/american-icon-examines-fords-rebound-review.html

<comment><AUTHOR> Wondering about the effectiveness of the phrase "We're sorry, we seem to have lost this page, but we don't want to lose you"</comment>


San Diego lab discovers COVID-19 vaccine in 3 hours - <AUTHOR> https://www.cbs8.com/mobile/article/news/health/coronavirus/coronavirus-vaccine-san-diego/509-e18e37f6-347c-4b08-ad33-910968abb04f <comment><USER2> This smells of #fakenews. Can anyone confirm/deny? No comments or feedback shown on website listed. Inovio Pharmaceuticals created a vaccine that is going through pre-clinical trials.

<comment><USER2> Looks like original post was 4 hours earlier - [https://news.ycombinator.com/item?id=22313320](https://news.ycombinator.com/item?id=22313320)</comment></comment>


Show HN: Make Things Now – Block-based 3D design tool for 3D printing - <AUTHOR> https://makethingsnow.com/beta

<comment><AUTHOR> Hey guys. I'm the developer of this. I'll be happy to answer any questions!

Also you might be interested to know that this is written in C++ and compiled to JS using emscripten and using WebGL.

<comment><USER2> Currently, Make Things Now: Blocks requires Chrome, Firefox or Safari on a non-touch device. We're working on support for both IE and touch devices and we will be releasing this soon!

Until then, if you have any questions or suggestions, please get in touch!

\---- I'm on a windows 7 machine running Chrome.

Once I manually disabled your blocking divs, and enabled the content div, I got the UI to display, and I think I understand what your app does...

It's a minecraft style voxel modeller with STL export capabilities, geared toward 3d printing! Cool stuff! You gotta disable all that target platform checking crap and just let it run on anything, and then see what doesn't work.

That said, it was throwing exceptions internally, so I never actually got to drop a voxel... I stopped short of trying to debug your emscripten stuff..

Edit: In your STL export, are you only exporting externally visible faces? Also, does your 3d printing integration allow printing on the fly? Curious how you are tackling that... Ive been kinda thinking about an app like this to make 3d printing more interactive.. it would be really neat to be able to draw and print stuff one layer at a time interactively! like... doing pixel art one layer at a time, and having it print each layer as you move to the next... Cool stuff! Let me know if you're looking for someone to collaborate with!</comment></comment>


Hacking a WordPress Botnet - <AUTHOR> https://www.wordfence.com/blog/2016/08/hacking-wordpress-botnet/ <comment><USER2> The Strange Tale of the Denial of Service attacks against GRC.com (2001): [http://www.crime-research.org/library/grcdos.pdf](http://www.crime- research.org/library/grcdos.pdf)

</comment><comment><USER3> This is some fun spy versus spy back and forth.</comment>


Detecting and monitoring Covid-19 in wastewater - <AUTHOR> https://nuadox.com/post/616328529965121536/covid-19-waste-water <comment><USER2> This content plagiarized directly from Richard Harth's article here:

[https://asunow.asu.edu/20200423-discoveries-novel- coronaviru...](https://asunow.asu.edu/20200423-discoveries-novel-coronavirus- detected-monitored-wastewater)

"By Nuadox Crew" is a blatantly lie. All content on this site is verbatim copied blogspam, with actual author uncredited.</comment>


Why Vanilla JavaScript Doesn't Cut It - <AUTHOR> https://peterhrynkow.com/javascript/2019/07/13/why-frameworks.html?v=2 <comment><USER2> Good read, so many people forget the problems of plain vanilla js as they knock all the new frameworks out there.

<comment><AUTHOR> Thanks for reading!</comment></comment>


Show HN: CrowdArt - <AUTHOR> https://docs.google.com/spreadsheets/d/1JwkDRjNOiiM2VuB17lUQDimISjmGkZYs0XKwv4SBFq0/edit?usp=sharing <comment><AUTHOR> Hi Guys,

Need few inputs on how to get more people to engage on this art project.

Any art related sites which might bring more viewers? Any other ideas to increase engagement?

<comment><USER2> There something similar to Hackernews for designers: [https://www.designernews.co/](https://www.designernews.co/)</comment></comment>


Pixar's gender problem - <AUTHOR> http://vastpublicindifference.blogspot.com/2008/06/pixars-gender-problem.html

<comment><USER2> Flagged. This is a lot of biased rambling. Assigning arbitrary low scores because the main character's never female? Maybe the fact that Pixar has a strong male team of writers/animators makes them feel like they are better able to write from the male perspective? Or is it sexist for men to favor writing men? Why don't more female writer/animators enter the scene? Then to knock them for finally _having_ a female lead because it's a fairy tale? Christ.

Why not pick on Dreamworks? They don't have that many female lead movies either, not in their animation. And David Lynch didn't have many female leads either, not until his movie with the lesbian lovemaking scene. Coen Brothers? Stanley Kubrick? All sexists?

<comment><USER3> perhaps the only insightful comment from the entire rant is that "males are general, females are particular."

an exploration into why this seems to be upheld in the minds of most people would be way more interesting than her rant that Pixar must be sexist for thinking the same way as the rest of the human race.

Pixar is a company that tells identifiable human stories mostly with non-human living creatures and animated inanimate objects. Giving them "generic human" properties in order to appeal to the general human condition just seem like common sense.

In fact, I am way more disturbed by the fact that most male characters in recent stories are portrayed as weak, flawed and/or immoral, and that most female characters are the embodiment of kindness, good sense and smarts. There may be more male characters, but are any of them adequate role models for our male youth?

</comment></comment><comment><USER4> I feel the need to pull up a quote from the comments, attributed to a Pixar executive (in a social setting):

 _"Gee," he said, "that's something we wrestle with all the time. We're very aware of it and we're trying to change. But sometimes it's just so hard to find a way to justify adding a female character to the story."_

If that quote doesn't singlehandedly demonstrate the accuracy of this article's analysis, I don't know what evidence possibly could.</comment>


Ask HN:Should I get the new Macbook Air to replace my 3yr old MBP? - <AUTHOR>

I've been thinking about seriously replacing my old machine which predates the unibody MBP. I've been hearing rave reviews about the new MBAs but mostly from non-developer/designers. I'm sure it's great for email and documents, but how does it stack up when you are running local dev environments, IDEs, Photoshop etc.
Would love your feedback, especially developers and designers who made the jump.
FYI, I probably wouldn't have any other machine.
Thanks <comment><USER2> If you don't need the 8gb of ram then yes. If you do then no. My old MBA was the c2d with maxed out specs and I used that as my workstation with win7 vm, visual studio, xcode, eclipse and monodevelop concurrently. The beefier CPU would make it more than adequate except I want the extra ram to run multiple virtual machines.

</comment><comment><USER3> This is the first MacBook Air with the performance a developer or graphics designer needs.

It's actually even faster than a 2010 MBP.

<http://osxdaily.com/2011/07/20/macbook-air-2011-benchmarks/>

<comment><AUTHOR> Thanks. these benchmarks are very impressive. As they say in the review, the drawback is gaming which doesn't matter to me.

</comment></comment><comment><USER4> I'm pondering the same question, only for replacing a 5 yrs old first gen MBP. Just bought a new 13" MBA for my wife and was impressed with the thing. Would probably do well as a dev lappy, the only drawback is that you're maxing out at 4GB ram.

</comment><comment><USER5> I switched from a 2009 15" Macbook Pro to the latest 13" Macbook Air. It's perfectly fine for development work (which for me is mostly Xcode/Komodo/Photoshop), and much faster than my previous machine.

The screen resolution is the same so basically there's no loss there (I haven't noticed a difference despite the smaller physical screen size), but the lighter weight and greater portability are fantastic. Battery life is about the same (~5 hours).

I would highly recommend it as a primary work machine, and cannot imagine going back to the heavier Macbook Pro.

</comment><comment><USER6> My opinion is that the current air is great for light weight development and travel, but not so good for heavy development. My use case is probably different then most, as I run 2 linux VMs, 1 win7 VM Xcode, Eclipse IDE, Xcode IDE, Komodo IDE, Adobe CS Suite and compile java, c, c++ in millions of lines of code. I'm currently working on a 17" mbp on 8gb ram and 480GB ssd. I'm usually 12 gb into swap, so I would love 16gb. I heard that the 15" air is in the pipeline, so that might be a good option.

<comment><USER7> 16 GB upgrades exist [http://blog.macsales.com/9283-owc-announces- industry's-first...](http://blog.macsales.com/9283-owc-announces- industry's-first-16gb-ram-upgrade-for-latest-apple-macbook-pro-models)

They are pricey but in the same range as a 480GB SSD...

</comment></comment><comment><USER8> That's easy: buy it. It's the perfect machine to get code done.

I wouldn't use it for stress tests though. IMHO it's a task for dedicated machines anyways.

</comment><comment><USER9> I would have bought an Air 15" yesterday. And today, as it happens. 13" is too small for older eyes. Looking forward to a 15" Air. I'm already in line.

<comment><AUTHOR> I guess that's my struggle - I am wondering whether I should hold out for a 15" Air or thin MBP.

</comment></comment><comment><USER10> This piece from 100 days ago: <http://news.ycombinator.com/item?id=2493319> has a lot of endorsements for the MBA as a primary work machine. I'd assume it has only gotten better since the latest upgrade.

</comment><comment><USER11> <http://www.reddit.com/r/firstworldproblems/> ?

</comment><comment><USER12> If 3D graphics performance is important to you, then don't get an MBA just yet, stick with an MBP. I've got a 2010 MBP, my biz partner has an 2011 MBA: for general CPU burning it's on a part with mine; disk I/O it obviously tears mine up. With an external screen it's pretty nice as a development machine, but personally I like the 15" high-res MBP screen too much to downgrade to an MBA.</comment>


Ask HN: Wallstreet News slinkset site - <AUTHOR>

HN:
I have made a slinkset for wallstreet news: http://bankertimes.com
With the financial crisis, it seems like hacker news is bombarded with the wallstreet news. Hopefully this site will allow the users who are  interested in finance to keep up with the news, while also keeping hacker news organized.
I am looking for some moderators who are willing to help out. You should be able to find my email in my profile. <comment><USER2> Can I shamelessly promote my Wall Street news aggregator (non-social but much more useful) -> <http://www.streetread.com>

Personally, I don't think there is much room for social news with regard to Wall Street. With general market news, what is important to some might be irrelevant to others, and so on. Stock-specific news can be extremely important, but only to shareholders.

</comment><comment><USER3> thanks for reminding me of slinkset. havent been back in a while. the site looks and works brilliantly. definitely going to use it for one of my projects.

</comment><comment><USER4> nonhackernews.com already kind of serves that need. Do people want a wallstreet only social news site?

<comment><USER5> with the number of links about fed bailouts, maybe so</comment></comment>


Why Upgrade PostgreSQL? - <AUTHOR> https://why-upgrade.depesz.com/show?from=11.8&to=12.3&keywords= <comment><USER2> We are planning to migrate from postgrsql 9.6 to 12.3 (or 13 once it's stable).

So far everything works well except the one query which is 2x slower in 12.3 (not sure if something is wrong with my docker image).

Query is generation visits data using a laltteral join over a date range. I was hoping it would speed up the query when jumping to 12.3, but that's not the case sofar.</comment>


Etsy: Announcing Direct Checkout. (No longer just PayPal.) - <AUTHOR> http://www.etsy.com/blog/news/2012/announcing-direct-checkout/

<comment><USER2> Having direct experience in being a third party payment aggregator, here's some notes based on this post and their FAQ (if anyone cares):

1\. Fraud will now be your #1 issue (if it isn't already). People will make fake Etsy accounts, add fake products, and then make "purchases" using stolen credit card numbers. They will have the $ deposited to an E*Trade bank account, a pre-paid debit card that accepts ACH, or use some rube's account they found on Craigslist. Most of the time, you won't catch it until the money is already deposited. Then the chargebacks start coming.

I don't have the luxury of having a $50M warchest of VC money. You will definitely have to spend money and engineering resources towards this soon.

2\. Based on your FAQ, you're requiring sellers to mark an item as "shipped" before depositing their money. We actually had to turn this requirement off because it annoyed so many sellers. When a seller gets an order (in our case, photographs), getting it fulfilled becomes their focus. Making them go back to the web and mark it as fulfilled is something they will often forget. Getting their money deposited is something they won't forget.

IMO, I would try to make this more automatic. Use something like Twilio to send the seller a text 5 days after the order ... "Has order 24039 (yellow scarf) been shipped to Suzie J yet?"

<comment><USER3> Dang, the bad guys found out about eTrade? We used to use them to get Japanese folks US bank accounts because their Know Your Customer policy was so incredibly... Never mind, I understand how the bad guys figured it out now.

[Edit for posterity: You could open a brokerage account from anywhere with minimal documentation. After having a brokerage account, one phone call from your "secretary" and they'd add a US checking account to it. No KYC verification required because of "preexisting business relationship."

It was a great way to set up US bank accounts for folks who had business dealings with American clients before they got the opportunity to visit the US.]

<comment><USER2> Yeah, we actually ended up blocking ETrade's routing number ... none of our legitimate customers actually used them.

Our biggest problem has been the people getting duped on Craigslist. Actually talked to a guy from Arkansas who gave up his entire ID, SSN and all bank accounts to a "business partner" in Africa.

</comment></comment></comment><comment><USER4> If any Etsy employees are reading, I am curious about why it took nearly 7 years to add direct checkout to the site -- Paypal is not known for being particularly kind to either buyers OR sellers, though perhaps there were all sorts of scaling/technical issues that took priority over something like this? It just seems like, with the amount of volume that Etsy does, Paypal's rates would be on the very high side.

Congrats - looking forward to trying it out!

<comment><USER5> Seems like it might be a pretty complicated thing to add... No other marketplaces that I know of have their own processing capabilities... Third party aggregation (taking payments on behalf of someone else) has many quite- complicated regulatory issues.

<comment><USER3> In addition to the regulatory issues, you're asking to get a bunch of customer support complaints over $25 transactions where your maximum upside is measured in pennies. And many of those complaints are going to sound like:

Buyer: "The seller never shipped the itemz!"

Seller: "I did, too! With no tracking number, because I'm new at this, like most of your users!"

Buyer: "I fell off the Internet for two weeks because I didn't pay my phone bill but I'm back now and hopping mad because the booties that just got delivered have WOOL instead of COTTON in them!"

Seller: "It says right in the description NATURAL FIBERS!"

Buyer: "There is nothing natural about FACTORY FARMS!"

Accountant: "Total cost to read this email thread so far: $14 and counting. Value of this transaction to us: $0.57."

Buyer + Seller: "YOU GREEDY CORPORATE BASTARDS."

</comment></comment></comment><comment><USER6> Is this because no one likes PayPal?

Personally I've been screwed over by PayPal using Etsy when a seller didn't ship. It's since made me hesitant to buy anything there.

<comment><USER7> PayPal charges more than working with credit card companies directly. I was talking to a guy who runs an app that sells music the other day, and he got a much better rate by cutting out the middle man (less than Etsy is charging, by the way). If you are running a startup, you probably shouldn't waste your limited implementation and support time with payment processing and all the customer issues that arise vs. just using a third party, though.

<comment><USER8> > PayPal charges more than working with credit card companies directly

You'd think so, but in the general case that's untrue. Most MOTO merchant accounts advertise better rates but the effective rate the merchants pay is more than PayPal's 1.9-2.9%. PayPal's rate is flat, but anywhere else it's not. Virtually all credit cards (all rewards/points/cashback cards, all business cards, etc) are downgraded to a higher fee schedule -- plus AVS fees, auth misuse fees, batch settlement fees, statement fees, customer service fees, PCI compliance fees (virtually everyone added at least $100 a year in PCI fees in the past 2 years), chargeback fees, etc. And these are all variable and will generally be raised, one piece at a time, every month you have your account open.

I've worked with 3 direct merchant accounts and my effective rate is between 4% and 8% of transaction volume. At PayPal it's less than 4% including the fixed ($0.30) portion of the fee. A company with the expected volume of Etsy can probably negotiate a contract with fixed rates for some number of years, but the other 99% of small businesses accepting credit cards online (card-not- present transactions) are not beating PayPal's rates.

</comment></comment></comment><comment><USER9> Does anyone know how AirBnB and Uber and their likes do this? Are they also "third party payment aggregators"?

</comment><comment><USER10> here's the pricing info: "Direct checkout will cost a 3% + $0.25 USD payment processing fee per sale."

<comment><USER11> This is worse than PayPal for sellers with products over $5 (after shipping, tax). I wish they could've come up with better pricing. I would think most shops would be selling things over the $5 mark, but I can't say for sure.

<comment><USER8> > I wish they could've come up with better pricing.

It's nearly impossible since their processing fees on some card types will be over 3%. They're already taking a loss on those transactions; most will be under 3% to balance it out, but not enough that they could offer better pricing than everyone else.

They're not going to be able to negotiate barely-above-interchange rates like PayPal probably gets from its banks with billions of transactions in monthly volume. Visa's interchange fee to the bank is still as high as 2.7% on some cards, which is the floor upon which the processor can set its markup to the merchant like Etsy.</comment></comment></comment>


Show HN: Learn Everything about APIs - <AUTHOR> http://apicoding.io/ <comment><AUTHOR> This is a website about my development experience for APIs. So, I curated them into one place. I hope this will help you. Thanks :)</comment>


An Introduction to Quantum Computation and Quantum Communication (2000) [pdf] - <AUTHOR> http://herpolhode.com/rob/qcintro.pdf <comment><USER2> If you'd like to read a thorough, technical introduction to quantum computing, Ronald de Wolf's _Quantum Computing and Communication Complexity_ is very good. It's de Wolf's PhD dissertation, published in 2001. You can find a PDF online[1] but the author will send you a bound copy for free if you email him :)

Obviously any introduction from the early aughts is going to be noticeably out of date compared to the current state of the art. But since the core fundamentals remain the same it's still a very good place to begin learning about the subject. It's also good reading to gain some perspective of what the cutting edge looked like at the turn of the century.

In particular, de Wolf's work lays out a cursory introduction to quantum mechanics before giving a walkthrough of several early quantum algorithms (Deutsch-Jozsa, Bernstein-Vazirani, Simon, Grover, Shor). Then he moves on to fundamental quantum computing and complexity theory, and finally to quantum communication. An appendix gives a refresher to the linear algebra you'll need to follow along (i.e. you should have familiarity with linear algebra before reading this, but you don't need to be adept with tensor analysis).

If you'd like a more recent and accessible (if not as complete) introduction to the subject, de Wolf also published the lecture notes for the graduate course[2] he taught in 2011. This has been continually updated with errata and additions through 2018. The lecture notes for this course largely take the survey material from his dissertation and build upon them with research results from the past 17 years.

_____________

1\. [https://homepages.cwi.nl/~rdewolf/publ/qc/phd.pdf](https://homepages.cwi.nl/~rdewolf/publ/qc/phd.pdf)

2\. [https://homepages.cwi.nl/~rdewolf/qcnotes.pdf](https://homepages.cwi.nl/~rdewolf/qcnotes.pdf)</comment>


Apple's Lower Prices Are All Part of The Plan  - <AUTHOR> http://www.nytimes.com/2011/10/24/technology/apples-lower-prices-are-all-part-of-the-plan.html?_r=1&hp=&pagewanted=all <comment><USER2> Price is the reason why no manufacturer has been able to compete with the iPad. It's not only a tremendous product as far as tablets go, it's relatively cheap. Look at the latest high-end tablet offerings; all subjectively "worse", most more expensive than the Apple product.

The market-share argument against Apple will disappear as they strengthen their supply chain and become more efficient. They will become great AND cheap products. As someone who recently purchased his first Mac (decked out 13" MBA) and loves it, this is good news for everyone.

</comment><comment><USER3> I call BS. A macbook air might be "cheap" if you decide to limit your comparisons to "thin" notebooks but Best Buy has 40 models of notebooks for $200-$299 and another 40 models for $300-$399. The $300-$399 aren't bad either. 3-4gig, I3, AMD 6910, DVD player, etc. etc. You can get 3 of them for the price of 1 macbook air. Got 3 kids, how about 3 notebooks instead of 1?

iPad? The competition hasn't really even started yet. It's only a matter of time before the $200-$300 tablets that don't suck start appearing. Will Apple lower the price of the iPad to match? I doubt it.

Phones are a different market. Because almost all phones are bought with contracts there's been very little incentive to make the phones cheaper. Unlike notebooks which you just buy outright.

I'm not saying in any way Apple's products aren't worth it. I have an iPad, 2 Macbook pros, A Mac Mini and an 8 core Mac Pro. But I'm not under any delusion that they are cheap compared to the alternatives. I'll still buy them because I like them but claiming a macbookair is a cheap notebook is like claiming a BWM is cheap car. It's only cheap if you massively restrict the options you are comparing them to.

<comment><USER4> The article does mention that you can find cheaper alternatives. The point is that other manufacturers have problems competing with Apple in the premium market.

Will Apple lower the price on the iPad? They will, if they can without compromising on quality. They did so with the iPod and the iPhone. They did it with the MacBook Air. Right now, they don't need to it with the iPad because it doesn't have any real competition.

If Audi and Mercedes had problems matching BMW on price while making more crappy cars, you'd say that a BMW was cheap compared to the competition, even though it's an expensive car.

<comment><USER5> As an aside, it is often possible to buy laptops from competing manufacturers vastly lower than MSRP (40+% off), especially on craigslist. Apple laptops seem to not exhibit this effect.

Used ones are extremely cheap. My 2 year old (and extremely usable) Dell E4300 model can be had for ~$320 on ebay, while weaker macbook airs go for double that.

<comment><USER6> Apple product resale values make it a no-brainier to buy Apple.

<comment><USER5> Well if you must buy a new product at retail pricing, then yes. :)

</comment></comment></comment></comment></comment><comment><USER7> The challenge for Apple here is to maintain both the 'premium' cache while remaining competitively priced.

As this article states, they've done very well in marketing the Air. Everybody seems to be comparing Apple's $999 11" Air with competitors 13" products. The 13" starts at $1300, so the competitors are often priced $300+ less, with the exclusion of the Samsung Series 9.

<comment><USER8> I think Apple has proven it can maintain the premium _cachet_ [1], making healthy profits as well as offering competitive pricing. It has sold more than 300 million iPods, and yet, they look and feel like luxury products.

Also, it is only through Intel's $300 million stimulus fund [2] that computer manufacturers other than Apple have finally started making slim notebooks that can compete with MacBook Air on price. Whether they can actually compete on quality remains to be seen, the 'ultrabooks' haven't exactly gotten favorable reviews. Read for instance Engadget's review of the Acer Aspire S3, their conclusion is "If you absolutely must buy a laptop of this ilk right now, you'll get better performance and longer battery life from the MacBook Air" [3].

[1] <http://www.merriam-webster.com/dictionary/cachet>

[2] [http://newsroom.intel.com/community/intel_newsroom/blog/2011...](http://newsroom.intel.com/community/intel_newsroom/blog/2011/08/10/intel- capital-creates-300-million-ultrabook-fund)

[3] [http://www.engadget.com/2011/10/14/acer- aspire-s3-ultrabook-...](http://www.engadget.com/2011/10/14/acer- aspire-s3-ultrabook-review/)

<comment><USER7> Sorry about the spelling on cachet, I was wondering about that.

I'm not sure if you intentionally left out the review of the UX31, or just were unaware of Engadgets positive review yesterday. <http://www.engadget.com/2011/10/21/asus-zenbook-ux31-review/>

My biggest disappointment with all of these 'ultrabooks' is that they are MacBook Air clones. I don't think PC makers are going to go very far competing with Apple by copying their designs. PC makers need to start innovating themselves.

Ultrabook is starting to be a synonym for MacBook copy, but there is a great opportunity to create products like the Lenovo U260 (which I'm typing this on now) which are as light as the Air, with warmer materials and don't have the wedge shape.

<comment><USER8> I hadn't read Engadget's review of the Asus Zenbook. I have now, and I also read the review at Anandtech [1]. Both sites really try hard to like the device, but they agree on several points:

\- incoherent case design (did you see that blue USB port?)

\- uncomfortable keyboard with barely any travel

\- trackpad is laggy and inaccurate

\- display is TN, not IPS, and has high black levels.

Anandtech's conclusion: "if you don't care about OS X and just want a good, ultra-thin Windows machine the Zenbook is a viable alternative. If ASUS can fix the trackpad issues then it's worth considering, however the display in the MBA alone is reason to opt for it over the Zenbook, even for Windows use"

[1] [http://www.anandtech.com/show/4985/asus-zenbook- ux21-review/...](http://www.anandtech.com/show/4985/asus-zenbook- ux21-review/1)

<comment><USER9> To be fair, blue USB port = USB3 port in PC parlance. No excuse for the trackpad though.

</comment></comment></comment></comment></comment><comment><USER10> I'm definitely in the minority here but sometimes it's good to have some counterpoints about the new MacBook Air. I recently bought one with 13" thinking it would be my best computer ever. Well, hardware/power-wise it is incredibly fast! But I found out some things that make it almost unbearable.

There are only three ways to interact with a laptop and I believe it fails deeply in two of them.

The trackpad is very much ok, probably the best one I ever tried. But the keyboard... While the design looks amazing, keys are really thin and feel cheap. As soon as I turned the laptop on and needed to enter my Apple ID, the first time I pressed the Alt key it just came out! This hasn't happened yet to any other key on this laptop but I used to have an iMac with a similar keyboard and three keys stopped working. You can feel the fragility of the keys by putting one finger on the top of the key and another on the bottom, and then press them alternatively: the key bounces like a boat. While I can't say it's the worst keyboard I ever had (because I owned an iMac), I never had such problem with any other laptop or external keyboard. I could also talk about the really small size of the arrow keys. I miss them all the time. And the return key is also much smaller than every other keyboard I have tried before.

The other way to interact with the laptop (more like it interacting with me) is the screen. I was crazy about having a really good definition screen and it is. But operating systems are not made for resolutions like that so it all ends up with really really small text everywhere and zooming all the time because you will mostly never get into a text properly sized for a screen like this. If you use Windows you can set the DPI to whatever you want but webpages text will still be incredibly small.

So I have a hard time typing and reading on it. I can't recommend it to anyone.

<comment><USER11> Regarding your complaint of rocking keyboards.

I went and checked my ol' T60 and by god, do T60's keys rock like a drunk sailor.

But it's universally regarded as one of the best laptop keyboards available.

<comment><USER10> I'm replying to you again but with a different view. Is the T60 keyboard the same as the X200? Because it's what I am using now and it's an amazing keyboard. This is important because if you say these keys move a lot then we are definitely not talking about the same feeling, probably because I can't explain myself much better. My only problem with the X200 keyboard it the documents keys near the arrow keys, even after almost one year working on a X200 everyday I still hit them. It used to be so good when the arrow keys were a little bit apart from the main layout of the keyboard. I do love my Sony Vaio for that.

<comment><USER11> Oh, I didn't mean to imply that its not good keyboard.

I love Thinkpad keyboards I even profess my love publicly (<http://www.janezstupar.com/the-best-keyboard-for-programmers>).

There are two major beefs with Thinkpad keyboards. First the positioning of _fn_ key and lack of option to remap it is inexcusable. Second the page keys you mentioned.

<comment><USER10> Yes! The fn key is so annoying there. I didn't mention it because it seems like that's the standard now, so wrong...

</comment></comment></comment></comment></comment><comment><USER12> What were the well-regarded elements to creating a successful product again?

Be the first. Be the best. Be the cheapest.

The iPad has all of these elements in the tablet space at the moment.

</comment><comment><USER13> I'm surprised nobody (including the article author) has mentioned Tim Cook, particularly as this new shift to lower pricing that he talks about coincides with TC taking the helm. This is what Mr. Cook does - squeezes every last bit of optimization and efficiency out of every step in the supply line, reducing costs, hence giving them leeway to reduce their prices while keeping their enviable margins.

<comment><USER14> Not only that, but IIRC Apple uses their size to bankroll plant manufacture in the far east in exchange for exclusive access to the first product run for a period followed by guaranteed sweetheart pricing deals thereafter (or at least so an article I read somewhere like TechCrunch claimed: I don't have a link handy unfortunately). Unsurprisingly, this gives Apple a huge commercial advantage: they are able to maintain profit margins whilst undercutting their competitors thanks to the clever use of their strong cash position. Apple's competitors seem to be completely incapable of taking the longer term view of product development that leads to these kind of dividends down the road.

(Whether doing these deals was down to Tim Cook, Jobs or some other Apple exec I've no idea, but I'm guessing Cook.)

</comment></comment><comment><USER15> Doing a little digging, it seems that it's $199 on Verizon with a contract. But you need a data package on top. It's $60 for 450 minutes.

Go for the Droid Bionic and it's $300 with a 2 year contract. So that _looks_ more expensive, but it's not, because it's $40/month for 450 minutes.

So over the two years that's an extra $480 dollars you spend on the Apple, to save $100 up-front.

I don't see how that's cheaper.

<comment><USER5> I'm surprised you don't need a data package for a Droid Bionic.

On Sprint, an iPhone 4S and highest end Android phone offered (Galaxy S 2) are the same price ($200) - contract details seem the same. My best guess is that highest end Android phones cost about the same as an iPhone 4S.</comment></comment>