Addepar | Full-time | Front-end/Web architecture/Full-stack | Remote available (offices in NYC, SLC, MV or Edinburgh) | https://addepar.com/careers
Addepar brings data, technology and people together to help investors make more informed and timely investment decisions. Advisors across the globe manage $3 trillion in assets on our platform. Addepar is backed by 8VC, D1 Capital Partners, WestCap and Valor Equity Partners, and earlier this year we raised a series F at a $2B valuation.
We're investing in engineering and growing rapidly. There are a lot of open roles, but I'll call out these two on my own teams:
In the 2.5 years I've been at Addepar we've steadily extended our product from a monolith SPA into a constellation of deployed codebases. Next up is a unique project to help existing apps deploy faster and new apps compose into a cohesive product.
Come build it with me! If this doesn't sound like your area but you want to hear about other roles, feel free to reach out.
Howdy there! I was one of the original authors of OpenEMR back in high school. I'm still good friends with at least one of the other authors. We're always stunned to see OpenEMR in the news, and watching it creep up on HackerNew today has been fun.
I've always been curious why OpenEMR seemed to dominate in the OSS space after we walked away from it. I can only theorize that the code was more approachable than other projects (PHP), and that the GPL kept the work from being captured by any one business. I can't imagine that the code was the best, I'm painfully aware of how poor the security practices must have been in hindsight.
You've given me the chance to ask a question I never knew who to ask: Why, back in 2003 (just after we stopped giving the project attention), was OpenEMR the project you decided to spend time on? What made it the attractive thing to invest in?
If you can tell me I'll bottle that elixir and pour it into every OSS effort I work on today.
Hi. James? I was CTO of Pennington Firm in that era and it was one of many industries where "internet modernization" was happening to a sort of sleepy status quo. OpenEMR with FreeB were the furthest along open source project at the time and so we started there. There were a lot of legacy type problems inherent in the OpenEMR codebase and I think the change to PHP 3 ultimately is what lead to starting fresh with ClearHealth. I'm dating myself but that's around the time that browser AJAX starting opening up a lot of UI possibilities.
Howdy! Nope, I'm one of the two Matts from the Synitech, the original publishers. IIRC the codebase as we left it was heavily into iframes. iframes and SQL injection attack surface.
I'm not sure it used CSS :-p in 2001 or 2002 I actually did a lot of systems work building a version of OpenEMR which booted from CDROM but wrote the database to an attached USB storage device. The idea was that small offices had to start thinking about HIPAA compliance, and could take the disks home from their server each evening for improved security. I think that was probably the last thing I was working on in OpenEMR.
The results there are using Ember 3.11, not Octane, so I'd also say those results are out of date :-p I will try to get the benchmarked Ember codebase updated over the winter holidays. I've always love looking at these microbenchmarks.
At large app scale Ember apps perform very well, and I would happily pit the performance of a full-complexity Ember app against any other framework. At the end of the day the goal of the Ember project is not to be the fastest, especially at microbenchmarks, but to have competitive performance with an API that any level of developer can be successful with. To have a fast Ember app there aren't any special tricks or APIs to learn, it is simply fast out of the box with performance that scales.
Thanks for the reminder about this benchmarking project!
The interesting story in this post is not about JS frameworks. It is about StackOverflow.
The Ember community made a proactive decision to abandon StackOverflow around the 2.0 release (about 2.5 years ago). StackOverflow simply does not provide the tools we needed. For example when you answer a question: Are you answering for version 1.0 of a library? 2.0? Perhaps the "correct" answer for each is different. Perhaps, over time, an answer that once was correct is now suggesting something deprecated or not in line with best practices.
StackOverflow doesn't provide any features for dealing with versioning and changes in what is correct over time.
If your community has a StackOverflow moderator, perhaps you can update all the answers you want on a regular basis. I don't know, because our community had no such person, and the StackOverflow team was disinterested in helping us come up with a solution (the Ember project reached out).
Additionally as a tool matures (Ember is over 5 years old) you take more of this stuff under your own wing. Ember has a robust set of companies offering video training, in person training, and books. We have a community chat, a forum, and very active meetups. All of these things are controlled by members of our community, meaning they can respond to changes more fluidly than StackOverflow (moderated by some people outside our community) ever could.
StackOverflow just is not designed for long-lived multi-versioned software. So guess what happens? Users of that software don't stick around on StackOverflow. For living projects the short-term trend will almost always look better than long-term trends.
Ember's story here is not universal. I'm glad there are developers finding StackOverflow useful for other libraries. I think the story StackOverflow should tell is one that focuses on what they do well. But to draw a meaningful lesson about the JS community as a whole from such a idiosyncratic data source is a fools errand.
I think this is the most important takeaway. It's especially true for smaller libraries and commercial libraries. And even for huge ones like Rails, questions answered 6 years ago might be little more than a catalog of improper practices by now!
For a hard numbers example of "trends" being poor, I develop a JavaScript diagramming library, GoJS: https://gojs.net
It has competition, such as JointJS, jsPlumb, etc. If I look at StackOverflow tags, I would think we're in big trouble:
* 180 questions tagged gojs
* 449 questions tagged jointjs
* 518 questions tagged jsplumb
These aren't even enough to show up on StackOverflow's trend tool, and they make the case look pretty dire for GoJS!
In search interest GoJS is clearly ahead of these other two libraries. What's more, if you compare the forums for each product, you'd see that GoJS gets 10x-100x the traffic of the others.
StackOverflow is simply not the a good place to gauge library interest and activity over the long term, and its not a good place as you say to ask or find answers to questions for products that have ecosystems which continuously improve their APIs and evolve.
StackOverflow is not a substitute to writing an API reference guide. Are you saying that Ember never planned to document anything of their framework? That sounds like a big problem.
Mobiledoc dev here. Mobiledoc is used at Bustle (who funded initial development) on two properties, at Upworthy, Daily Beast, and on several other sites. We're extremely proud this work has also been adopted by Ghost and hope to continue working with them for a long time :-)
One of the benefits of Mobiledoc is that we provide a documented and versioned file format for serialized documents. This allows developers to share renderers for Mobiledoc content. Bustle for example publishes Mobiledoc articles to it's own HTML, to Google AMP, and to Apple News.
Mobiledoc also supports runtime-customizable "cards" for rich content. For example a writer might add a video to an article- but for each rendering environment the runtime version of that card must be different. The cards API allows developers to offer custom editing and embedding interfaces without breaking the general text editing interface.
Yeah, it's the "card" functionality that appeals to me. I was planning on building something using slate.js but Mobiledoc sounds like it will fit my needs. Thanks for responding, I'll check things out.
Is there a roadmap for Mobiledoc available anywhere? I vaguely recall seeing a 1.0 feature document at some point, but development seems to have slowed from looking at commits.
For one, JavaScript code is actually pretty verbose. It both has a large payload size and high parsing overhead. Earlier versions of Ember's rendering engine worked this way and the change to a data based wire format in 2.10 made a large improvement: Intercom saw a 28% reduction in their whole application payload size. LinkedIn's uncompressed compiled template size dropped by 71%. As the wire format is all data (arrays for the most part) you would expect some parsing speed improvements as well.
And second, generating imperitive code makes it harder to perform runtime optimizations. For example during initial render Glimmer could note if a property lookup yields an Immutable object and use that knowledge to disregard change tracking for properties off that object. There are some fun things we can do here.
It turns out JavaScript engines are very good at iterating flat arrays and running small, highly optimized functions and that's what Glimmer is doing at its core. When your compiler output generates functions, you're creating lots of functions specialized for each template which means a larger surface for the v8 JIT to worry about optimizing. By instead shipping lots of small, hot functions to be re-used (instructions fired via opcodes), we can get a better optimization result from v8 and other engines.
