moo360

There was an awful lot of war in your "60 years of peace".

I don't know if I'm right or not but I tend to use the word "transpiler" to talk about something that transforms into the same language as before.

So for example Babel is a transpiler since it turns JavaScript into JavaScript - it just allows you to use certain features (usually of a later version, or a draft) in earlier versions. So I write es8 and use babel to turn it into es5 compatible javascript, I'd call that transpiling.

However, sticking with JavaScript, I'd say that coffeescript -> javascript is compilation since coffeescript is not the same language and very syntactically different.

So I guess converting one language into another syntactically different language is a compiler. While converting a language into the same language but transforming specific parts for whatever reason (such as interop or backwards compat) is a transpiler.

That's how I tend to think of it anyway.

But I agree, probably could just use compiler for all of them, especially if not using it means added ambiguity.

I just feel like separating the concerns of

1) Identity of the server

2) If the connection to the server is encrypted or not

would be a good idea in modern browsers. Because the article is completely correct, everything as it is right now essentially disincentives anyone producing IoT or any other kinds of consumer based lan devices from using https.

Completely agree with the author of the article. Would love to run https by default for lan without having to require users to install my custom CA cert. I don't really understand why self signed certs can't be allowed in browsers and the browser just notify the user that the website identity can't be verified while the actual communication between the two is still encrypted.

If anything I would say that a solution would be for browsers to adopt the following changes.

1) Make HTTP plaintext show the warning you currently get with a self signed cert (ie: warning of death)

2) Make HTTPS self-signed show a "not secure" warning in the address bar (currently what happens on HTTP plaintext) with more info available on a click

3) Standard CA signed HTTPS has no changes

Cool, but in JSX it's just javascript as you would write it anywhere else in your app, except encapsulated in braces. How is that not simpler for people who should be Javascript developers?

Since the logic inside of JSX is just JavaScript encapsulated in braces, you're basically saying that Vue's angular like attributes are better than just simple javascript syntax?

I don't understand how

    <ul>	
        <li v-for="num in listItems">{{num}}</li>
    </ul>

    <ul>
        {listItems.map((num, i) => <li key={i}>{num}</li>)}
    </ul>

What someone has to know to parse your vue example is the exact syntax for for loops in vue, evidently the syntax in this example is quite simple but what if they want to perform extra logic in that loop to modify which elements to show? In the react example all they have to do is know javascript.... in Vue they have to go look up how to do that in Vue.

Absolutely agree. Most front-end meetups/conferences I've been to have had the majority of people there expressing a dislike for JSX. I still don't understand that to this day, to me JSX is one of the best things about React.

You're right, but it's one of those things that you can basically treat it as html until you can't - and the points at which you can't are quite specific and other than className - are rarely used. Also the dynamically inserted html param being obnoxious is by design - they don't want you to dynamically insert html, and that's a good thing. Honestly you shouldn't ever be using that param.

First reason is we hate JSX.

I feel like this is often the reason people dislike React, and it mostly comes out of a misunderstanding of JSX and es6 syntax and interaction. Why do I say this? Because I've yet to hear an argument that came after a statement like above which was actually true in any way. Most arguments that come after actually expose the fact that the author of the statement simply doesn't understand the syntax usually because they've never really bothered to try to use it and instead are simply turned off by something new in their code.

It forces you to write loops, conditionals, etc, outside of the markup you are currently writing/reading

This is quite simply false, it doesn't force you to do any of these things. A lot of people seem to think it does which again comes from a misunderstanding of the syntax. You're quite able to either embed your logic into the JSX or not, whichever you prefer. I most often see people lean toward the former unless the logic in question is extremely complex in which case it could be argued it's best being removed from the markup anyway. But JSX itself does not force you either way.

It's like writing shitty PHP code without templates

I simply don't see a viable comparison here at all.

It also forces you to use a lot of boilerplate like bind(), Object.keys(), etc.

Again, this is simply untrue. In fact I'd argue that if you're using lots of .binds you're doing it wrong. .binds inside your render function are actually bad practice due to the fact that they mean you're adding overhead of creating new bound functions as each .bind returns a brand new function every time your render tree executes. The overhead of such is probably negligible, however it's still inefficient and cumbersome and thus is bad practice.

As for Object.keys() - While I share your dislike of the overuse of this particular method, I'd love an example of where you think this is forced on you by JSX because for the life of me I can't think of one.

There is no official React router

This I completely agree with, it is annoying, and I too am not a fan of react-router. However it's so easy to create your own routing setup and/or plug and play other lightweight ones that I don't usually think of it as a particular plus/minus point when comparing to frameworks like Vue.

it's

I made no comment on if it was right or not, I simply maintain that there is an important distinction there.

I think you mean ISO-3166-1, ISO-8859 is a standard for character encoding eg: latin1 (which is probably why you know it).

Are you being deliberately obtuse? It's a pretty important distinction that these were not some native tribesmen with millennia of ancestral history tied up in the lands.

Well this is the same people who gave you the cookie law.

Okay, but what about Aluminium?

While I agree they are lower, not much lower, but lower. That's simply because of the market rate. I have some experience hiring devs in London and NYC so can only really comment on those two cities.

You see approx ~20% reduction in market rate salary for a given full-stack position in London vs NYC. However there are factors that the simple NET salary comparison doesn't take into account. Do these factors negate the difference? No, not entirely - but they do reduce that percentage down quite significantly. The major one, which will be of no surprise, is healthcare.

The addition of free healthcare for your family is unlikely to be equal in value directly to the entire 20% salary difference. However, often the fact is it might be worth it anyway just to not have to deal with that, often stressful and extremely difficult to budget for, expense.

These aren't the only QoL differences between the two cities, others are often rather personal/bespoke to the candidate.

The point being comparing net salary between two completely different countries is often not even close to the full picture.

This is just complete rubbish. Sorry, it looks like you have extremely limited experience of tech jobs outside of the US, and/or are purposefully trolling.

Man, you have a very vauable asset for a tech career - a US Citizenship

This isn't really that important at all. I don't really recognise this as a specific asset in any way.

The tech career opportunities outside of US are really not that diverse and are heavily scattered across the world

That's an extremely biased and, in my opinion, incorrect view. Even if you just take the big tech capitals in Europe - London, Berlin, Paris etc - you have hugh tech opportunities in each. The opportunities in London alone rival those in New York. Sure there's not really a specific place similar to Silicon Valley - but that's really the only thing missing.

Of the Greenwich T3m92uGKhWMRV7Um0WVF50LKQNowpoe0FWwWryL2r9jkuAHyLTCY8QoY79iMiSjo6CHCZGWl's ?

I agree it is rather combative, however it's also true. To claim that X pattern is a reason to not use a library when said pattern is actually an anti-pattern you've used because of lack of understanding is going to garner these kinds of reactions.

Now if they would implement the HTML5 file drag & drop api like literally every other modern browser then may be people would actually use Edge.