41 comments

[ 3.5 ms ] story [ 92.2 ms ] thread
Really cool! I love simple solutions like this.
I would like to find something like this that is usable by Libreoffice Calc.
It looks like a simple html table, I think LibreOffice might be able to parse that. Else, it should be relatively trivial to change the output to e.g. csv which can be imported.

As for an alternative, and I don't know the options here, but maybe a plugin could be made that pulls the data into Calc itself.

I'm not into stocks, but like the way you coded it. We don't see this sort of good examples that combines the old school simplicity and new JS / DOM API features.
Looks like it gets an html page from https://iextrading.com/apps/stocks/#/<stock> then scrapes it. Not really an API. Edit: ok, I'm wrong.
You might want to look at the code, serve that html page from your local machine and console.log(url) inside the updateDataForBatch(symbols, addTitle) function to see how it works.
It uses the iex api. I have used the api before its really good.

Here is the code author uses to get data:

      const BASE_URL = 'https://api.iextrading.com/1.0/stock/market/batch';

        let url = `${BASE_URL}?types=quote&symbols=${symbols.join(',')}&filter=${filters.join(',')}`;
That url is just used to build a link. It uses api.iextrading.com for the quote data
This is great. I love the simple, succinct interface — I wish real financial companies like my trading account and my bank had even half this much sense when it comes to pragmatic design.

A few notes from taking a look at the code:

* I've very much started doing the same thing in my projects of just using modern JavaScript constructs like fetch and arrow functions without a transpiler. IE is never going to support any of them, but I've accepted that. Caniuse.com ranks most of them at 85%+ supported.

* It's neat to see that the IEX API supports batch requests (as opposed to having to pull one stock at a time) in its API which makes it possible to implement the project efficiently and in a way that doesn't have to store state.

* Nice work building it to support large users as well. A lot of installations probably won't have more than 100 stocks, but it'll break up requests into multiple batches of <= 100 if they do.

There's definitely something I can learn from this. By the way, Robinhood API also gives you quotes for free https://api.robinhood.com/quotes/?symbols=AMD,TSLA
I believe Robinhood doesn't have official API support so use it with caution.
More info is always fun but I gotta point out:

Why would you? Their volume is likely a fraction of IEX's:

https://markets.cboe.com/us/equities/market_share/

Worse all their stuff is effectively darkpooled. You'd be hard-pressed to find a worse source of market data.

Also:

https://medium.com/@Gangal/robinhood-robbing-from-the-poor-g...

Robinhood isn't a darkpool - they sell their "dumb" retail flow to the highest bidder wholesale to the likes of Citadel, Virtus, UBS, etc.. etc... Usually they just pick 1. This type of flow is called "PFOF" (pay for order flow). These PFOF players also provide marginal price improvement over the NBBO... marginal - because they always make more money than they pay out - and take marginal risk.
Do they not match transactions internally first?

Hence when they launched the terrible execution - not enough internal counterparties.

I don't know.. but it's a good question. Matching internally first creates huge overhead, compliance considerations, etc... Unless you already have the right infrastructure in place. For example, you need to report the trades. My guess is they wouldn't do this...
What makes this a "static page"? It's all non-interactive javascript.
Because it's served statically. No processing is necessary on the host side and it can be cached indefinitely without getting stale.
Static doesn’t mean no JavaScript or interaction. In fact many SPAs are just static pages served out of S3 and connecting directly to some API server to fetch data.

A static page means no processing is done on a web server to serve you the rendered content. This saves you time and money, and ensures scalability for any amount of traffic.

There are different meanings. Back in the day there was DHTML, where D stands for dynamic. So static page 10 years ago would mean no javascript.
One thing I've taken away from this is vanilla Javascript seems to have come a long way, or I've just never taken the time to fully appreciate all the features

For example I didn't even realise JS supported string interpolation

https://github.com/toddwschneider/stocks/blob/master/index.h...

I had taken a nearly six year break from JavaScript coding until about 7 months ago. It has definitely come a long way and is pretty great to use now.

There’s still a lot of “pain” left in the build processes, transpiling, etc, but they’re less painful than they were half a decade ago. Those are also less specific to issues with the language, and more with how we need to use the language.

While not plain JS, I’d strongly recommend trying Vue if you’re getting back into JS. Is a true pleasure to use on a daily basis, and I never find myself fighting it. It makes writing non static sites with interactivity a breeze, and even when I’m building near static pages, I like how it helps me to organize my code (from a structure standpoint, it isn’t opinionated on this stuff).

There's some really good examples of this in Wes Bos' (free) javascript30.com course - 30 short videos all using vanilla Javascript and showing some really neat new features.

Another really awesome new feature which I can't remember if it's in that course or not, is fetch - super simple AJAX API using promises. It's also used in this app: https://github.com/toddwschneider/stocks/blob/master/index.h...

... and I didn't realize that one could link to a specific line in code on a github file like you've done...

    index.html#L111
in

  https://github.com/toddwschneider/stocks/blob/master/index.html#L111
Very cool!

As everything is done client side how about adding some parsing of the URL #hash/?query to encode data of a portfolio? That way you could have a single statically hosted version serving multiple people. Could even have a portfolio builder page that generates the encoded URL.

The demo site is cool, wonder if IEX will appreciate the thundering herd from HN though?
Looks good! IEX API also has experimental support for websockets ;)
hmm, while this is cool i am not sure if it is a full-fledged replacement for the Google Finance "portfolios" feature. That lets you add the number of stocks you own for each symbol and shows you an aggregate gain/loss per day, etc. That was the main reason i was using google finance.

I have now transitioned to my own Google Sheet with the "=GOOGLEFINANCE()" function for getting the stock data. Works pretty well.

I'm no JS expert by any stretch but it seems pretty simple to add in code for that here. It'd be a chore to hard-code a big portfolio or one that trades frequently, though.
But if a website uses JavaScript, how can you say it is static? IMHO, static is only Html+css...
In this context they mean you won't need anything more than a browser or basic HTTP server.
Aren't they referring to it being statically served?
I had not realized Google killed Google Finance until this post -- the search replacement is abysmal.