The way I remember, when flow was introduced, you had to do small changes to 3rd party dependencies your code might have had to make them flow-compatible.
With typescript you could just write a type definition file for any 3rd party library, so you could essentially make any 3rd party dependency "typescript compatible" without needing to change its code.
This small difference made a huge impact for adoption. Eventually flow also got that feature but by then the adoption difference was already too big.
But don't hold yourself too much if you think you're not too knowledgeable about something to present about it.
You may be deterred by watching some talks where the presenter seems awesome and seems to know so much more than you. You don't have to be the top expert on a topic in order to know a few things worth sharing.
This is absolutely the case, and I think an important addition is that usually there's only a very small percentage of the audience who are already knowledgable enough about something to benefit from hearing a truly world-class expert talk about it.
Most people go to tech meetups, even very specific or niche ones, hoping simply to pick up a few tips or an introduction to something from somebody who used it in anger. You don't have to be an authority on something to just learn a few lessons from using it and pass them along.
This article's direction makes sense for the task of 'writing HTML in JS'. I find that JSX true power comes when you actually start building reusable components for the many pieces of your UI.
This becomes even better when using a TypeScript capable editor with TSX, creating classes for the components and taking advantage of full autocomplete and syntax checking from your editor. Your code ends up pretty readable, composable and error free.
You can still get all of those advantages using React without JSX. Reusable components have nothing to do with JSX. Syntax checking/highlighting/etc. is arguably easier (in a global sense) without JSX since we don't need to fork acorn or esprima to get it.
Oh come on, you would really trust a site for which ads seem to come from NRA?
Also the debunk [1]: "There is an article circulating the internet that is filled with half-truths and misinformation. It is posted on a website called “Political Ears,” which is listed as a “satire website” here. Unfortunately, people are reading this article as fact."
SISCOG [1] is a company that has been developing such systems for quite some time now (since 1986).
In their case I know that the core of their systems is written in LISP and it's mostly AI optimizaiton algorithms. The guys who run the company are both professors of AI related classes in the CS dept of IST.UTL.PT.
I like your home page design and color scheme, but:
- the centering is broken: your information source sites are a bit to the right compared with the 3 steps
- you give me a search box and hint a location, but I don't really know for what... I guessed it should be a destination for a travel but was pretty unsure
- I read P2P as "peer to peer", and I can bet others will too
When I searched for Lisbon, Portugal, I got a ton of results about people that are planning on going there from Madrid, Spain, and offering rides. Clicking on them sends me off from Lisbon to Madrid and got me lost for a while. You should remove the rides from the searches and rework them completely, otherwise they'll provide too much noise and confusion.
Searching for things with spaces presents a lot of labels with the space encoded as "%20".
Many times the user is interested in what "ad-supported small businesses" and "small publishers" (or even ad-supported big business and publishers) have to offer, so if those can't keep themselves running, there's a chance that the user will not be happy.
Besides disabling cookies doesn't mean blocking ads, so if the lack of tracking makes ads less attractive, other (possibly more intrusive) techniques must be used. I, for one, surely wouldn't want that.
That said, I think IAB has a very reasonable point there.
The funny thing is that memory is a tricky bastard, and you're likely to remember yourself with no pride on something you did that went wrong, when at the time you were actually doing it you were very much committed and with a lot of pride.
The opposite is also true: if your endeavor did succeed, you'll probably remember the journey with the sense of "of course deep inside I always knew this was going to be great" even if in fact you didn't believe in what you were doing.
With typescript you could just write a type definition file for any 3rd party library, so you could essentially make any 3rd party dependency "typescript compatible" without needing to change its code.
This small difference made a huge impact for adoption. Eventually flow also got that feature but by then the adoption difference was already too big.