HN user

sim0n

761 karma
Posts11
Comments204
View on HN
VanillaJSX.com 2 years ago

I would assume that lot of people just find the JSX equivalent a lot more readable and familiar (a matter of opinion, of course.)

  <div>
    <p>this is easy</p>
    {list.map((l) => <li>{l}</li>)}
  </div>
> you automatically get loops, variable interpolation etc without having to invent a compiler and new syntax

To be fair to JSX, you use regular loops, interpolation, etc without any different syntax (`{}` accepts a vanilla JS expression), you just obviously need the compiler step to de-sugar the element tags to `createElement` calls.

Not exactly a framework, but a React app from 2014 will still work great in 2019 and can be updated with very little pain.

Build tools wise, a simple Webpack/Babel config from 2014 would be relatively straightforward to update to the latest versions.

Soccer would be a much better sport

Very subjective. I personally think having a limited set of substitutions helps keep the game more interesting as every change can be hugely impactful to the team's tactics and the result of the game.

PHP in 2019 7 years ago

Why is "map an array with a function" unintuitive but "filter an array with a function" isn't?

DOM APIs have much improved since jQuery first arrived, so while that was the case originally, it's become less true over time. It's definitely still less verbose though, for example:

  $('.my-component div').css({ background: 'yellow' })
vs.
  Array.from(document.querySelectorAll('.my-component div')).map(node => {
    node.style.background = 'yellow';
  })

I personally think that the syntax is great considering it's being added to an existing language. await/async allows you to opt-in to having your code behave in a synchronous-like manner, when you want it to.

One of the best things about JS/Node is that you can wait on I/O from different sources at the same time and since the async/await syntax is just sugar over Promises, you can do things like:

  const [user, notifications, messages] = await Promise.all([
    getUser(),
    getNotifications(),
    getMessages(),
  ]);
Instead of having to wait on I/O sequentially like:
  const user = getUser();
  const notifications = getNotifications();
  const messages = getMessages();
if awaiting were implicit.

You don't have to use the hottest new framework or language feature. The JavaScript you're writing now will still be supported while the language evolves and improves.

The backend where I work (Airbnb) runs on Rails but most of my projects use node on the backend since they usually just expose a REST API.

Since it only cares about UI, React is obviously not opinionated about your backend/server environment unless you're trying to do server rendering (then you need something in your stack capable of executing JS).

For view/UI, yes (if you can call React a framework). I personally do not use jQuery anymore as there is not much need to deal with the DOM directly when using React and when there is, I just use vanilla JS.

Since React only deals with UI, I use it alongside a bunch of other great libraries such as Redux (for state management).

For me, once I started declaring my UI as a series of components that simply render what they are provided (the common `v = f(d)` expression), it was hard to go back to the Backbone/jQuery way of mutating things all over the place and manually updating DOM nodes to try and reflect the current app state.

[dead] 10 years ago

Sounds like she imitated the behaviour of a 14 year old on the internet pretty well.

Thats the obvious solution, though how would that affect people using Netlfix while traveling?

For example, if you're locked to the US region and watch something that is only available in the US while visiting, say, the UK — would that break any of Netflix's license agreements?