hmcdona1

lol it would work fine. I've had a joke app running Angular 2.0 in production for years. The code doesn't just expire and break. If you upgrade to Angular 8 in your package.json without running the upgrade schematics, yes it will break...because there were breaking changes.

In 2016 React was on version 14. Are you telling me that from version 14 to 16.12 React has had ZERO breaking changes? Because they definitely haven't. That ecosystem has also changed recommended patterns countless times. They just choose to leave a lot of the old implementation options around if they can while Angular as a frameworks tends to be more opinionated.

Same goes for any library or framework across major versions...

Although Ivy will bring nice improvements all around, you won't see the 12kb bundle sizes you are talking about in this initial release of Ivy. `renderComponent` is the key that will enable that down the road in some fashion (you can play with it now), but I appreciate the teams approach to easing the framework into major changes like that.

The architecture concepts behind Angular are very .net-esque in a lot of ways. It's often an easier transition for folks used to MVC style projects with a heavy reliance on dependency injection to wrap their head around Angular than some other SPA options out there so the two get related in this way a lot.

Microsoft also supported Angular early on as it was one of the largest early adopters driving folks to Typescript.

Fair enough, but I'm not sure you understand how nice schematics are. You can use them for a lot of things, but one nice use case is essentially update migrations. You literally just run `ng update @angular/cli @angular/core` and a majority of the time you're good to go...

This couldn't be more wrong. The team does a great job handling upgrade paths post 2.0.

First off, Angular versions post 2.0 are nothing like AngularJS/1.x -> Angular/2.0. They are much more incremental and even the two times the entire renderer has been re-written it was an incredibly gradual process over multiple major versions with seemingly few changes to component and template APIs.

Second, upgrading between Angular versions couldn't be easier thanks to angular schematics. The process takes seconds and for specific rarer exceptions the team maintains this fantastic guide here: https://update.angular.io/

Watch the talk linked above. He goes into a lot of the reasons. Security is definitely a big one. Other things seem to be addressing problems that originated from poorly informed decisions early in development that the node.js community has had to deal with ever since (require() based module resolution, npm, etc...).

Modern SPA frameworks are usually built on components. You can combine components to define a tree of elements that represents your UI. This pattern is also often referred to as a Declarative UI pattern.

GraphQL works well with declarative UIs, because you can define fragments and combine them to create queries that best match the data the current set of components you are loading require. In this way, it's flexible in a way REST isn't (at least typically) and syncs well with Declarative UIs.

I can't speak to datalog though.

have you never heard of urban dictionary before? they're all user submitted joke definitions...

FastAPI (built on Starlette) essentially generates your OpenAPI docs for free via intuitive use of decorators and type hints/Pydantic models.

async is more beneficial for when code is primarily network bound. WSGI is thread based which comes with a higher overhead for task switching. So it’s just not as efficient for most web server tasks.

We need to write a lot of small APIs in Python for SPAs. We ended up going with FastAPI which utilizes Starlette under the hood. I'm surprised neither of them are mentioned here.

Starlette was developed by the same dev who wrote the Django RESTful package. If you mostly just need REST APIs or even GraphQL, it feels far more light and modern than anything in Django and forms some better opinions around things than the usual roll your own stack in flask alternative. Not to mention it's ASGI based instead of WSGI and naturally faster because of it.

FastAPI just builds on that by adding some nice features like minimal dependency injection and really awesome integration with type hints via Pydantic.

"Normal" people don't know because they don't use niche software products like an rss reader or Google's latest messaging app.

If something is not an instant mainstream hit, Google might can it. That's a risk if you plan on trying out something new from Google before your uncle is asking you how to set it up.

In Texas, H-E-B sells exactly what you are describing. They have four types of meal kits: eat, heat, cook, and prep.

https://www.heb.com/static-page/meal-simple

I buy at least 3-4 of them a week because they're perfect for a single person who wants to eat in and maybe not prep as much but still wants a wide variety of meals to eat.

This is similar to the Conventional Changelog:

https://github.com/conventional-changelog/conventional-chang...

I often use a customized Commit Lint in combo with Husky to enforce conventional changelog messages:

https://github.com/marionebl/commitlint

https://github.com/typicode/husky

You can also throw in something like the Commitizen cli for newcomers:

https://github.com/commitizen/cz-cli

Fair enough, I fully admit to not being an expert on voting and don't know about any reforms taking place. I was simply stating that a blockchain solution might be better than just casting a plain paper ballot. The way OP worded his response made it seem like paper was the most secure end all be all solution. If there are other reforms in place I might agree.

Good point! If keys/addresses were assigned in secret, I don't see how blockchain forensics could identify someone given that voting is simply transactions going one way. The only way might be time, but that could be a big give away.

There's also people providing their public address as proof of a vote in exchange for something, but the risk for the buyer is that someone just hands over someone else's transaction and votes as they please.

A real potential solution would be to make the votes private and "untraceable" (A la Monero ring signatures or something of the sort), but that kind of comes with it's own pros and cons and could always be broken later. I still think it's worth investigating if this is more secure than plain old paper ballots.

If I am given a voterID, let's say an address from which I cast my vote. I can look at my vote on the chain to ensure it was cast correctly forever from that point forward. The node software would ideally be open source and publicly available. A full node could be run at each voting site, and potentially by citizens themselves even. You could run one to make the voting process even more secure.

A decentralized blockchain is far more trustworthy than a centralized database in this scenario. Say Russia controls the centralized voting database, they can just edit whatever value they want to say "Putin" and call it a day. It's not public. No one can verify their vote. It's under the control of one party. The entire point of decentralization is to ensure there is public consensus among multiple parties.

There are other discussions about how to allow or incentivize citizens to run nodes, mitigate lost or stolen IDs/private keys, prevent against spam attacks, etc...but it sounds like you aren't even open to discussing those because you equate the word "blockchain" with "snake oil".

What? I agree it works, but it's pretty insecure. Paper ballots can just be swapped out for other paper ballots. With a public blockchain (or something like it) you could always look up your vote and by nature it cannot be changed. The vote count could be tallied instantly as well and recounts are unnecessary.

Blockchains can't ensure no false votes are cast for deceased or unwilling participants, but it honestly would be better than paper in many ways. I am not advocating people use some third party token to do this. That I believe would be unnecessary. Am I missing something though? I don't understand the overwhelming hatred any blockchain related tech gets on HN. This is one area where I think it could provide real value.

My favorite is if you're from Houston you call on/off ramps "feeder roads". I don't think people use that term anywhere else.

The lightning network will be far less effective than people are hoping. You have to a) pay to open up a channel with each person you wish to use it, and b) each stake capital in that channel for it to be functional. This is useful only in specific scenarios like exchange-to-exchange transfers. Exchanges are going to be very unlikely to ever set up channels to customers. They haven't even implemented segwit yet, there's no way they are going to bother setting up the infrastructure needed to charge for and activate lightning channels.

Yeah, the author of this article likely just followed these TensorFlow tutorials. You don't even have to touch code.

Follow this to retrain the Inception network: https://www.tensorflow.org/tutorials/image_retraining

Follow this to run an image through your model for classification: https://www.tensorflow.org/tutorials/image_recognition

It's not even just that. I'm not sure about everywhere in the country but in parts of Texas good luck depending on a cab to show up within even an hour+ time frame you called in for it to. Everyone here has cars so there are very few cabs and the service is poor because of it.

I went to college in San Antonio and Uber was banned for about a semester or so after it became the norm. Too many people started drunk driving again. For all intents and purposes, you either found a designated driver or didn't go out. Many choose the illegal third option.

No matter what the price, the fact that you CAN get a timely ride via ride sharing apps is a game changer here.

You are clearly not from Texas. Nothing is 10 minutes away. Public transit is a joke. I realize this is a chicken/egg situation, but it's probably not changing anytime soon here.

Honestly, it's not an issue (in Houston) at all. I like driving and the fact that everywhere has parking is perfect. If I'm going out I just pay for the uber and call it a night. It's cheap enough down here anyways.

To be fair the average user doesn't ever need to see hidden folders. Who cares what the defaults are, set your Mac up however you want, I'm sure everyone here is plenty capable.

Also, people will spend days customizing their Linux systems, but think OS X needs to be exactly the way they want it out of the box. Why is that? I agree the software quality has declined over the past few years, but many people here seem to be nitpicking.