I've been working with React Server Components recently. A lot of the points here are applicable for RSCs too. The problem IMO, is Next.JS. Most apps don't need edge computing or fancy caching (which Vercel sells). Take those out, and I think we'll have a nice framework that's easy to use for everyone.
It was in kind of the parent post. I don't get his disdain for some implementations, especially when a monoculture proved so troublesome. He also missed NSS, which is quite an important one.
Important Difference.
1. Coin is based on Zerodha's kite platform and requires a demat account for investments. There are multiple disadvantages of using a demat account for mutual funds, one of them being transaction costs on every transaction from demat as well. The others are difficulty in estate planning and also your movement options to other services would be restricted if you don't like Zerodha services.
2. Try searching for popular Franklin funds on Zerodha! :)
3. Piggy is mobile first.
Hey, sorry for the delayed response. In case you see this, do you have any data that I use to compare the costs involved by investing through Coin vs Piggy? Also, since you're a start-up I'd be a bit concerned to give my money with doubts what'd happen if you shut down. How can I make sure my investments are secured even if you shut down?
Hello! We have an offer running currently where when you invite 5 friends to complete sign up through us then all transactions via Piggy are free for you for life.
Also regarding your investments. They are all in your name. You get the final allotment statements directly from the fund houses to your email. You can also generate consolidated investment statements by yourself. So in absence of Piggy you can still buy and sell your investments. We've just made it easier for you to do so.
Also, could you please expand upon demat disadvantages? How much is that demat txn charge? I think it's kinda insignificant.
Also, from a user point of view, if one has a demat account with Zerodha they can also do stocks with the same account without having to pay for demat again with another provider, right?
Our web is getting built as we speak. It should be up soon enough.
We focussed most of our efforts on mobile till now because as a country we skipped desktops and jumped to mobile first.
Regarding demat for Mutual Funds let's look at it this way. NonDemat MutualFunds is also paperless and you get consolidated mutual fund statements nowadays. So there is no additional advantage of investing in only funds via Demat route plus you have to pay for it.
Less than 1 % Indians have participated in capital markets and mostly through mutual funds. So at this point our focus is on keeping things simple.
As far as I can tell, it's "just" the relevant AWS services, repackaged in a more non-expert-friendly frontend, simplified for a DigitalOcean-like usecase.
Doesn't expose the full, intimidating complexity of the AWS management console and workflow.
This is more into AI than Ads. AFAIK Siri uses Wolfram Alpha for its answers. Given the way Google's knowledge graph is advancing, it totally makes sense for them to build their own AI engine.
Google Knowledge Graph is based on Freebase.com. Google shut it down, last month. IBM relied on Freebase for Watson, so they acquired Blekko last month, a real web search engine & knowledge base startup. Microsoft already owns Powerset company that powers their Cortana. Apple needs a up-to-date knowledge base too, currently they rely on WolframAlpha and Freebase, afaik.
Shutting down Freebase was a big hit for many projects in the AI space, Freebase had 2,903,361,537 facts in comparision Wikimedia's Wikidata has just 13,924,224 facts - that's still a huge difference.
> Sky opens the door to use Dart on the server side, on the web as well as for highly performant native apps for Android (and eventually for other platforms like iOS).
What's wrong with using GWT and J2ObjC other than the fact that there are people who don't enjoy building stuff in Java?
I don't see anything 'wrong' with GWT, just as there is nothing inherently wrong with writing iOS apps using Ruby (http://www.rubymotion.com/).
For example the Inbox team did a fantastic job re bringing a great user experience to multiple platforms and I guess they were glad that they could use one language throughout instead of having to jump between various tools and idioms (see http://gmailblog.blogspot.com/2014/11/going-under-hood-of-in...).
It's just that like you mentioned people do have different preferences when it comes to languages/tools/ecosystems. That's all.
There are people building web services using PHP, Ruby, Python, Java, Haskell, Elixir, Erlang, Go, C++, JavaScript, Dart. Why not also have this choice on mobile?
