Echo JS 0.11.0

<~>

faceyspacey comments

faceyspacey 103 days ago. link 1 point
I'm not saying make a virtual DOM api. Make the react rendering model "THE API." And without JSX--just pure JS.

Also, 25 years of backwards compatability doesn't need to go away. They can build it into the browser as an option like WebGL. But it must support SEO, have a more efficient rendering engine like an iPhone app, and under a simpler API (similar to React). 

..In my estimation web components will never become big. Maybe something else like it. And browser folks are working on another "web component"-like model that truly gets it right by the way. And ultimately that's the point. So in general, I agree. Something truly "right" and high performance should takeover here. 

It's not one or the other--the 25 years can stay, it's gonna have to. But websites should be able to perform as amazingly as React Native does by now. The performance is horrible. You can't build animation heavy stuff like you see on your AppleTV or FireTV without encountering much jank, bar WebGL which isn't the right API and doesnt offer SEO. The best API to me is React. To others it's Vue. In terms of actual app building productivity, Web components falls short of both by a long shot. So that's its problem. Let's not marry ourselves to yet another crappy API when there are clear and far better alternatives.
faceyspacey 105 days ago. link 1 point
It's a great article and very good to be aware of these risks. It's always fun to see hacking examples. 

I sure hope it's not a "few years" though before css-in-js solutions become best practices. The pace of some things in webdev is super fast and the pace of other things is super slow. I also have been still recommending css modules, but have really been hoping these tools are fully ready, like, tomorrow.

On a side note regarding things that progress slowly, I still find it ridiculous how horrible performance is in the browser with the DOM, yet you can use JS in React Native for far better performance. It's time browsers get a high performance API. Keep the old APIs, but build a "virtual DOM abstraction" that completely skips the DOM. No more DOM. It stands to reason you could code React Native style code in a desktop browser--and if the browsers directly supported it--it would perform far better than React Native itself! My hunch is web assembly still isnt the answer. It's still predicated on the fact that the DOM and its dom/paint/layout engine is there. We need a whole other engine.
[comment deleted]
faceyspacey 106 days ago. link 1 point
what about synchronous resolution server-side? i.e. the require.resolveWeak stuff? ...i'd need to find a solution for that for Universal. Currently react-universal-component knows its running in webpack, and uses internal webpack methods to require "weakly" (i.e. without indicating to put the code split component into the parent bundle when the same code is run on the client).
faceyspacey 119 days ago. link 1 point
also, would love to figure out how to get React Universal Component + webpack-flush-chunks running in Fusebox. Do you have any way to "weakly" require a dependency so it doesnt end up in the parent bundle. The equivalent of webpack's `require.resolveWeak`, or ideally: `require.requirewWeak`?

The idea is for code-split apps with SSR, you get the additional chunks to the client manually. But you still need to be able to reference them in the parent chunk, as sometimes they will be embedded in the page.
faceyspacey 119 days ago. link 2 points
awesome stuff! I love FuseBox. Just an idea: at the top where u say "loves Typescript" it almost feels like Babel is left out. It might help for promotion to not leave the large React/Babel crowd out of the equation so early in the readme.
faceyspacey 125 days ago. link 1 point
So it's another way to accomplish what you might do with supertest right:

*server/index.js:*
```
export default function startServer() {
  const app = express()

  // ... regular app.use stuff etc

  const server = http.createServer(app)

  if (process.env.NODE_ENV !== 'test') {
    server.listen(process.env.PORT || 80, () => {
      console.log('Listening on %j', server.address())
  })

  return server
}
```

*__tests__/server.js:*
```
import request from 'supertest'
import startServer from '../server'

it('REQUEST: /', async () => {
    const server = startServer()
    const path = '/'
    const res = await request(server).get(path)
    expect(res.status).toEqual(200)
})
```

??
faceyspacey 127 days ago. link 1 point
Thanks brother. Can you tell me more about what you mean by:

"would wrap the main server entry point so that it only runs when `!module.parent` and can be fully tested."

??
[more]