allover

There's a huge difference.

The parens in lisps are significantly detrimental to its first impression, and 3rd, 4th ...

I have literally never met a developer I can show a lisp code sample to whose reaction isn't "what the hell is that?"

It looks totally alien compared to C-style langs, which is what most people learn.

With Python, that is not the case at all, basic Python can be interchanged with pseudo-code for the majority of developers from C-style backgrounds.

Pretending this problem doesn't exist, only exacerbates it, and really holds back lisp adoption in my opinion.

Then you can use `useHistory` (or `withRouter` if you're not hooks-ready).

I somewhat agree that the <Redirect /> component is not actually that useful, it's only useful in very simple cases like "based on one route plus conditional redirect to another", e.g.:

    <Route path="/">
      {usersPreviousShoppingGender === "women" ? (
        <Redirect to="/women" />
      ) : (
        ...
      )}
      ...
    </Route>
    <Route path="/women">

This Ryan Florence talk is a great talk that touches on this topic, especially in some of the more creative examples: https://www.youtube.com/watch?v=kp-NOggyz54

You can now use hooks for some things you might previously want a component for, e.g. useFetch instead of <Fetch />, but don't agree "this should definitely be the case". Dogma is never good.

Strongly disagree, and 'because the function is called that' is a very poor reason.

You're not using React to its full potential if you think like this.

Disagree there's anything really low-mental-overhead about bringing redux into your project.

It's not really bananas when you actually start to think of everything 'as components', and consider that 'render' can neatly, declaratively describe behaviour, not just the DOM.

There are the features a company "tries" to innovate on, vs those they consider uninteresting and just try to find a quality/cost balance.

I was referring to the act of deployment itself. A single deployment of a monolith, without needing to ensure a dependent service whose pipeline is owned by another team is "deployed first", can be a lot easier to organise.

As I say it can depend a lot on other factors like repo organisation, pipeline maturity.

I struggle to see how release coordination can be something microservices inherently improve upon, do you have an example comparison perhaps?

> Micro services don't only provide horizontal scaling but also operational scaling

I think it's more accurate to say that they don't necessarily provide any horizontal scaling, but can provide operational scaling. This is only if there's some natural team divide, and the impact of the introduced complexity does not outweigh the benefits of the teams being able to test and deploy independently.

Sadly in most cases I have come across, this is not the case -- the complexity introduced and/or problems caused by lack of ecosystem maturity outweigh any potential organisational benefit.

> release coordination

Microservices can make release coordination significantly harder i.e. when a feature release requires multiple deployments from separate teams, I definitely wouldn't list this in the pros column, it's very much an "it depends". Other tangential factors, e.g. monorepo vs multi-repo, can be more significant.

> The moment your monolithic frontend and backend need to start doing asynchronous work, you'll want to build a "microservice"

I agree queue-based background work is a case where services are a good fit (sadly this is not what a lot of people are doing with their codebases when they "go microservices"), ... but it can also be simpler to deploy the same exact same monolithic codebase to a worker, and only execute the part that is performing your async task.

(If your worker is a lambda, sure, that isn't going to work.)

Yep, see jwilk's comment re: history.replaceState() existing: https://news.ycombinator.com/item?id=21368314

> How do you even know all the permutations of personal data that came be stored in the logs. There are possibly infinite possible ways personal information can manifest in logs.

Nonsense. You write the log statements. You know what data structures you are logging.

If you're using some server's built in logging, or some logging library or middleware you don't understand, turn that off until you understand what it's logging.

> macOS is exactly where people expect native theme

Who are 'people' here? The strawman here is that 'average users' do not expect native theme.

I did say "non-technical", which is open to interpretation, but I did not mean 'computer illiterate' (i.e. only uses apps given by OS).

The discussion here is really about average users, and the baseline assumption here is that we are talking about apps that don't come with the OS, that we'd install, since we're devs, creating new stuff.

> I don't know any who does not have VLC or LibreOffice however [...] (but that may be a french thing)

It's a French or power-user thing.

I don't think this is very debatable. Consider the fact you might be in the vast minority of users.

I'm a dev/technical user, in the key audience for native look & feel powertools, yet the main apps I use on Mac are still Chrome, Spotify, Slack, VS Code. None of these use the desktop's native theme.

Imagine the case for non-technical users.

Average users expect apps to have a custom look and feel. Ever tried SnapChat?

Well it's the generalisation about a large community that is the problem, whether put arrogantly or not (the arrogance only makes it harder to scroll past and ignore). GP put it well:

> I'm always confused when someone calls out a large group of people for not having a consistent opinion.

Even imagining a world in which all the major browser vendors had agreed to constrain browsers to a pure HTML+CSS+flash-like-extension-free web, someone would've eventually come out with a heavily funded 'next gen' browser with their flash/silverlight equivalent, and we'd either be in proprietary-land, or right back here with an open JS equivalent, post-backlash. Ship sailed and always would have.

> While this assessment is somewhat accurate

No it isn't, and please stop perpetuating this nonsense.

1) As I said, it was not just JS in this situation at the time, it also applied to other major registries like PyPi. So your point does not reinforce the original attack on JS developers. Congrats to Maven for getting this right.

2) Namespaces were added later. It wasn't "a decision to make them optional". Also check out for the discussion here as to how namespaces don't solve this issue, this point is largely moot.

3) I'm not the person blanket attacking a community. Or making unlikely assertions that "nobody" in the Java world installs direct from the internet.

4) Detail the exploit, otherwise this is FUD.

1) Same applies for npm (granted, this was only fixed after the left-pad incident, and npm was not the only language's registry to have that issue).

2) As mentioned elsewhere in this thread, npm supports namespaced packages, but they are not mandatory. There are other major languages' registries in same situation.

3) Can you back up 'nobody'. I would suspect a lot of companies don't use a proxy. Some JS teams also use an internal proxy for npm, but it is obviously additional infrastructure to setup/maintain which has a cost.

4) Never heard anyone raise this as a problem before.

> Not directly related to the incident of the original post, but I was mindblown when I realized that you can unpublish npm packages

You can't, with the exception of a 72 hour window, to allow for accidental publishing [1].

[1] https://www.npmjs.com/policies/unpublish

> Even PHP gets this right. It's not hard.

PHP had the luxury of coming out with a package manager (Composer) later, and learning from others before it. (2012 vs 2010 for npm).

Npm similarly improved on a lot of package managers that came before (e.g it's superior to Pip, which doesn't resolve dependencies [1]).

> It makes me wonder why npm hasn't already moved to namespaced package names.

Also, npm does have namespaced package names, the problem is that it was introduced later, so isn't mandatory. I'm not sure how they could make it mandatory without breaking everyone?

[1] https://github.com/pypa/pip/issues/988

> Mostly because the vast majority of JS developers don't seem to be aware of the rest of the software universe

Do you have any evidence to back up this statement, compared to developers in other languages? Or is this just business-as-usual JS bashing?

To be fair, that looks like their site's footer (see blog), but agree it would make sense to remove it on that page, to not contradict the message :)

Well, not all lazy HN commentary, like criticisms of 'scrolljacking' should be taken seriously. ;)

I mean, just one big reason Fortnite doesn't feel like a pubg rip is because Fortnite's building/editing mechanic sets it completely apart.

Watch one of the Fortnite world cup matches going on right now [1] and tell me that you're watching a pubg rip :)

[1] https://www.twitch.tv/videos/436713934?t=42m25s

The console.log was only there to illustrate that the code in useEffect's callback is only being run on the client-side (see the codesandbox I linked to).

I think it's clear from the parent I was responding to that they have better use-cases in mind :)

> and I still have no idea how I only do stuff on the client in a SSR environment (stuff that i did in componentDidMount)

The 'useEffect' hook - it won't be executed if you use e.g. ReactDOMServer.renderToString() for SSR

    useEffect(() => {
      console.log('Client side only');
    }, []);

Codesandbox: https://codesandbox.io/s/peaceful-dew-nvw83

In this case the author is suggesting a way to avoid it, for distributions to not theme and introduce the bugs in the first place.

> But when you have many similar repos (modules) with similar build steps you want to manage

How many teams do you have? In all seriousness, if you aren't talking at least one team per repo, have you considered a monorepo setup? Aren't you burning time managing those many similar repos with many similar build steps?

That said, even in a monorepo, I still prefer Jenkins compared to cleaner seeming cloud offerings due to its limitless flexibility.

So you're making the same change but taking longer to do so?