bfrydl

No TypeScript? Anywhere there is JS there is also TS, since it compiles to JS.

The author doesn't really suggest that Rust was chosen for any particular reason. A few benefits are mentioned but they aren't really specific to emulators.

Most C# developers who followed this path probably worked on enterprise-level custom software which is now web-based or they worked on ASP.NET applications which have been replaced by TS/JS web applications.

There's some stronger similarities between Ruby and Rust than some might expect. Ruby is obviously a lot less strict, but both seem obsessed with providing every method that could possibly save you time. Ruby's Enumerators and Rust's Iterators in particular are almost excessively comprehensive. You don't write many loops in either language.

Also they both use this_casing_style for most identifiers and ThisOne for types.

HTML is declarative, but it's also a string. It is faster to manipulate the DOM to make the changes you want than to generate an HTML string and ask the browser to parse it.

A virtual DOM allows you to use declarative _code_ instead of a string to get the same benefits as declarative HTML, but avoids the overhead of HTML by manipulating the DOM directly under the hood.

I believe this is also true for development tooling, not just actual code executing in the user's browser. There's no real reason why tools like webpack, eslint, and so on need to be written in JS for most use cases.

Members of the Rust community in particular are actively working in this space, building ES parsers, transpilers, and module bundlers. There's no all-in-one solution but even now with a little effort you could replace webpack with Rust-made tools, so long as you don't mind losing hot reloading or code splitting.

> However, a major drawback of this method is the lack of descriptiveness. When you see the dispatch function in your props, you don’t know the actions that you can invoke and you need to make reverse engineering. It would be avoided if we had passed each callback directly as a prop.

It's worth mentioning that if you use TypeScript, it is possible to strongly type your dispatch function to only accept valid actions. In fact TS is smart enough to type check the individual properties of different actions based on the string value of the `type` property.

You can use that with the new React Context API mentioned at the end of the article to build yourself a strongly-typed, self-contained mini redux and react-redux alternative.

For what it's worth, while I don't really disagree, Erlang's pattern matching is very powerful and covers a lot of the same ground as static typing.

Erlang is not in my opinion a “dynamic language gets us going fast” language. It's a language specifically designed to handle large scale reliably for long periods of time.

That was a very defensive response.

Look it's excellent for you that many people want to use your work and think it looks awesome. I am just not one of those people, for reasons developed over years of using Redux professionally.

It seems like you think I am just missing something, and that's why I don't agree with you. You should really be more open to the idea that others might think very differently from you and the people you surround yourself with, even after fully considering your ideas.

I also knew you were a Redux contributor when I first responded. I was wondering how long I could disagree with you before you pulled rank.

Sorry, I know you're heavily involved in this ecosystem, I just don't really see the need for any of this. create-react-app is mostly about webpack, isn't it? Redux works fine on its own.

I do think we need to agree to disagree. That being said according to the README for the Redux Starter Kit these are listed as problems it wants to solve:

• "Configuring a Redux store is too complicated"

• "I have to add a lot of packages to get Redux to do anything useful"

• "Redux requires too much boilerplate code"

I can't help but point out that all of these concerns can also be solved by not using any extra libraries and just doing what I suggested.

Configuration: createStore()

Lot of packages: Not needed, just pass dispatch around.

Boilerplate code: Pretty much just combineReducers calls.

Yes, I'm familiar with the arguments against it, but my experience using Redux has led me to strongly disagree with them. I don't think the proposed benefits have much value in actual practice, and limiting the use of dispatch to plain objects makes state logic easier to understand in my opinion.

Also, I think my primary issue with redux-thunk isn't that you dispatch a non-object but that the getState argument encourages async operations which are dependent on the current store state, possibly its current state at multiple different points of time. Personally I think that as much as possible async operations should be written to use only parameters as input and dispatch actions as output.

Plus I use TypeScript where things like this getState argument are really annoying for strong typing. You need to import the type of your store or store state in every file that uses a thunk.

I also personally think that the extra ceremony applied to Redux is a contributor to the difficulty new developers have understanding it, because they believe that Redux does more than it actually does.

The new hooks are a great way to use redux, not a reason not to use it. A “useStore” hook is much easier to understand than react-redux's connect.

I don't think redux-thunk is the simplest solution. There's really no need to add anything to redux to support asynchronous code. You can just pass the dispatch function around.

For example:

  async function getArticle(id, dispatch) {
    try {
      const res = await fetch(`/articles/${id}`);
      const text = await res.text();

      dispatch({ type: 'GET_ARTICLE_SUCCESS', id, text });
    } catch (err) {
      dispatch({ type: 'GET_ARTICLE_FAILURE', id, err });
    }
  }

In my opinion all this middleware business (thunk, saga, etc.) is trying to make redux do jobs it isn't supposed to be doing.

I used to feel exactly the same way about Ruby. Since then I have grown to value strict compile-time checks more so I don't really use it, but I still miss it.

I wonder though if you have evaluated Crystal?

In my experience as a long-term Firefox user, developers already don't care about Firefox. It's amazing how many websites I visit that break or look awful until I switch to Chromium.

One thing to note about create-react-app is that nearly all, in fact almost literally all, of those dependencies are development tools. They are also a pretty “normal” configuration of tools, based on standards rather than some custom framework.

This means that if you have a problem with create-react-app or it were to be abandoned, you could just get a different development tool and likely make zero changes to your actual code.

The only reason I know of to bother supporting NoScript users is so that when you announce your site on Hacker News you don't have to read that one angry privacy guy talking about how bloated your site is because it requires 200 KB of JS.

It's ten reads, but each of the ten reads is typically just an index into a big sequential array. Also, when you're reading components, you can run that system in parallel with any other systems that do not write to those components.

They are, but if you start a new project and you want a permissive license you should probably choose Apache 2.0. It grants the same rights as an MIT or BSD license but also includes an explicit patent grant and a section that deals with the licensing of contributions.

Forgive me if I'm missing something but this looks needlessly complex. Could you explain how this could be helpful, especially for developing React applications? The page doesn't really explain it besides insisting that this is closer to how we think, but I don't agree at all.

The site is giving me a 429, but discussion Reddit seems to indicate this is misleading. DuckDuckGo has code that includes calls to `getBoundingClientRect()` which can be used, most likely with other metrics since it just tells you the size of the window, to fingerprint visitors. However, inspection of the source reveals it's just part of normal layout code.

https://www.reddit.com/r/privacy/comments/ad4h0u/duckduckgo_...

I think you should consider that some people need money more than a goofy clandestine comradery with other “information seekers” on the internet and also that bug bounties frequently exceed “paltry.”

Your analogy has cause and effect reversed. The correct analogy is that if I know there is a reward for telling people their car doors are open, I will go around town specifically looking for open car doors. With no reward, I'm just going to go about my life not even looking at car doors.

Your service may be too small for this, but a company like Amazon typically saves money overall by running a bug bounty program because uncaught bugs can be extremely expensive.

Is this not usually how it works? Other than Makefiles, every language with significant whitespace I can think of just treats “more than the previous line” as an indent.

WASM always seems like the future until you find out how big the binary is relative to even a meaty JS app when it includes all the code needed to support things like GC or dynamic typing.

> Be vocal! Use your influence!

When I tell people to use Firefox they just laugh like it's a quirky personality trait that I use the underdog browser instead of the one everyone knows is best.

It isn't about “memes” or “ignorant coders.” Please grow up.

The way goroutines work isn't compatible with Rust's core language goal of zero-cost abstractions. In order for a goroutine to suspend and resume at arbitrary points in otherwise normal functions, each goroutine needs its own stack. This is convenient but comes at a cost, and I certainly wouldn't say that it matches reality or is close to the system.

The way Rust implements async ensures that there is zero overhead. You can think of the compiler as constructing an elaborate state machine. Each task is a normal structure in memory, just a few bytes rather than an 8 kb stack. This means that by paying the cost of dealing with a somewhat invasive language feature, Rust async code is more efficient than the equivalent Go code.

This is part of Rust's core design. The language should be as convenient or productive as possible, but never at the cost of performance or efficiency even if that cost is very small.

Honestly man I don't need to play an anime visual novel to know I won't like it. I don't like visual novels and if it's anime it's probably about high schoolers.

What? I've never been nagged for this. I forget the feature exists.