MuppetMaster42
Being able to have anyone just walk in the shower and say "device play music on Spotify" and have it just work is much simpler and requires much less thinking and effort - which is really nice first thing in the morning.
Also a speaker you can't connect after getting in the shower, but a smart speaker you can.
None of those are mandatory. They're mostly just syntactic sugar on top of existing features.
Every other change has just been things like new util methods on primitives like the string trim functions.
The build tools are separate, don't conflate them with the language. That being said, for ~4 years, most people's build chain hasn't changed; webpack with a babel plugin.
The problem is that JavaScript wasn't considered a stable and useful language until it really started to hit its stride in about 2009. So all of the changes that have happened are because the community is still figuring out the best way to do builds whilst things in the language are still changing.
As far as the ATO is concerned, unless you discontinue both, you're considered an Australian resident for tax purposes.
Even though the US considers you a resident alien, the ATO requires you to at least look like you won't be coming back for >1 year.
At my last company they had no equity going in, and added it on Jan 1st a year later. When I spoke to the founders about raises for the engineering team, the CTO looked at me funny.
"we just gave everyone stock options, why do they need a raise?"
Why?
Because a few of the engineers had young kids that were just starting school, and equity on a 1 year cliff won't pay those fees.
Because in Sydney there are enough start-ups that any one of the engineers could get an offer for 10-50% more base salary with options on top.
The founders were genuinely great guys, but they couldn't see the wood for the trees.
However disabling it entirely would break a lot of use cases.
Chat apps would stop working, push notifications would no longer come, web sockets would stop getting processed, feeds would not get refreshed. You'd break a lot of the web.
Doing so would force more companies to push out their own separate apps... Which would probably be electron (and I know how much HN hates electron).
[1] https://developers.google.com/web/updates/2017/03/background...
Unless the open source app is transparently built and app store deployed from a public build server, it's very easy for the owner to inject a back-door into it.
There's no mechanism built into the app stores to validate an app against its source code.
So the owner could checkout master, add a back-door, build and publish to the app stores, and you'd update, never knowing you're exposed.
Nothing is 100% safe. It's just dependent on how much trust you assign.
We rewrote our backend from rest php to graphql typescript.
I can tell you that it is amazing operationally. You push code to aws and it just runs.
A comparison with manually managed ec2:
- push code to lambda and lambda automatically handles the dns updates and VIP swaps. No need to worry about configuring multi region blue-green deployments and health checks.
- no chance of a server needing manual intervention because of an errored state - because you can't store state between requests (not entirely true, but true enough). But failing that you know that the container will die soon anyways.
- automatic scaling instantly. Our platform was b2b, so most of the traffic was 7-7. Instead of running load balancers and scaling the servers, we needed to do nothing. AWS starts and kills new instances to handle the load automatically.
- no need to worry about the server config. Only need to specify a node version and a CPU size. It's a godsend from a dev standpoint because ultimately you don't care about that. Why bother managing the OS config, drivers, installed software + libraries. Sure it me as you can't squeeze every cycle of perf out a box, but chances are you aren't in a position to need to.
- pay per call, not per second. We were serving hundreds of thousands of calls via lambda every month, and the bill came out just over a single digit. I've read articles about the crossover point cost wise but it takes some decent scale to get there.
Theres no rules about how you architect a lambda function, just rules about how long it runs for.
Like I said, we ran our entire graphql api via a single lambda function and it worked great.
Things get a little more complicated when you need to kick off background processes, but again that can be pretty simple if you want it to be.
We just pushed messages to an sns queue which triggered a different lambda off. Note though that all this code was in the same repo, sharing code within everything.
The tldr of this really is: imagine running a service was as simple as pushing code to aws. That is what lambda enables.
Theres no way for them to know whether or not the extra params on the URL change the result page. (i.e. example.com/index.php?post_id=1 and example.com/index.php?comment_id=1 could be very different pages, or they could be the same; you don't know).
So in comes the canonical url! This tells Google the proper url required for a specific page. That way if Google gets to a page using two different urls, it can tell that they are the same page.
You can list it by adding a tag to your HTML head.
You can even do face things like rewrite urls entirely (i.e. If the crawler hits example.com/?category_id=1&item_id=2, you can correct the ugly url by listing the canonical url as example.com/category/1/item/2)
Generics are a complex concept for people to grasp without some time playing and reading docs, but once you learn it, you can express almost everything you want.
But for simple projects you can get away with all but the most basic of generics, if any at all.
With the release of conditional types, I find most of my js typing cases are covered.
Though tbh I've always leant toward the side of "if you can't express it easily, then you're being to JavaScripty".
3 out of the 4 MBPs have a fault which causes the second screen to flicker and bug out. We tried every combination of the adapters but the 3 MBPs were consistently faulty.
After searching the web, it turns out this is a very common defect in them since at least 2016.
The repairs will be covered by Apple care, but it doesn't excuse the fact that our brand new laptops have to be sent for repairs before they're even used.
Plus we've lost time whilst we wait for them to be fixed.
Learned the hard way to make sure we buy stock in advance so we can test and repair it before it's needed.
We've used join-monster to handle the sql generation so it's been a breeze to get everything up and running.
Its surprising how fast it is too. We used to use sequelize glasses an orm, but we were getting 4-500ms r times on simple requests. Now for the most part we get sub 100ms responses on complex queries.
Service workers are designed to be run independently of your web page. I.e. Your service worker can run in the background and update your apps resource files (or even cached xhr data) when your website isn't open, so that it's ready when the user accesses your site.
This means your site goes from remotely delivered to locally served. Which reduces the load times to super low.
IMO it's also nice and clean because it lets you completely separate your app and network logic. Your web app itself can be built as if it is always online, and all the offline logic is in the separate code package in a separate thread.
It also has the added bonus of giving you more power in the workplace. If you can communicate well, you can get more ideas on the table and implemented. The more ideas you implement, the higher your worth clearly is.
The other thing I'd note is that your raw dev skills are a product of how much effort you put in. If you do dev purely as a job (minimal pre-job training and relying solely on on-the-job training and experience to keep up) you're going to be stuck as a mediocre dev.
To be truly successful you need to be seeking and actively consuming knowledge all the time (at least in your early career). This means keeping up with your chosen dev scene and languages, and actually playing with them and learning them in your own time.
Companies value someone who knows their shit, knows it well, and can communicate how to apply that shit to their product.
I think being a dev is a unique career because unlike most, there aren't just a few advancements every year to care about, there's several every month. And those advancements aren't just something you can maybe do in the future once a paper is vetted and reviewed, they're things you can read about, toy with and probably apply to your product straight away.
When burger king tried to start its brand in Australia way back when, they were unable to register the burger king licence in all states because in one state a man already had a long running burger place by that name.
So instead of having every state bar one with burger kings, they instead opted for a new name entirely.