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! 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.
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.
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.
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.
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.
This release of Ember.js integrates the new Glimmer rendering engine and stabilizes a year of work by contributors. It is a backwards compatible drop-in upgrade that should also yield a significant performance bump for many use-cases.
Additionally it unblocks other feature work Ember has coming down the pipeline!
For those who haven't been keeping up with Ember or the Glimmer effort, I wrote a list of five things you should know about this release: http://madhatted.com/2016/11/30/5-things-to-know-about-ember... It should be approachable even if you don't know the framework well.
Congrats to all the contributors for making such a difficult change so easy for everyone else to use!
Expanding the jQuery foundation in this way is an exciting change, and one I'm interested to follow and learn from. Ember.js for example has taken some tips from how jQuery grew and managed itself, however we've also avoided what we think were some missteps.
I hope the organizers of JSF can share what works and doesn't with the wider community. If they want to solve fragmentation in JavaScript projects, no one organization will do that. The need to share their ideas where they work well.
I asked a few questions on Twitter yesterday to this end, and if there is a JSF member around I would really appreciate some thoughts:
* What are the motivations for moving to Apache 2.0 as a default license? I expect something about IBM and the patent clause. Does adopting this license attract more corporate participation?
As mentioned in response to the other comment here, I was in error to use the term "bfcache". Yes, servers cache AJAX calls, this is described under the section "In practice" and there is a link to a server that can you use to replicate the behavior locally, probably in Chrome.
Sorry :-( You are correct. What I described is not be behavior of the bfcache, it is the network behavior described under the heading "In practice". And there is a link there to a server that can help you play with the behavior.
Apologies for using the wrong term and causing confusion.
> This is not necessarily what users want (as evidenced by discussions on this post).
HN not being representative of an average user aside, I don't disagree. My point is that there are two different expectations of what should happen and they can conflict and cause errors.
> you're complaining it doesn't work
I'm really sad you got that impression. I'm fascinated and think this an architectural problem of the web. My post is an attempt to describe the issue and raise awareness.
Author here, happy this popped up and to see the HN community thinking through it. A few people have brushed off what I sketched as uninteresting and don't see any issues. I'll try to explain it another way (with three years reflection to help).
Single page applications are now quite popular. Most single page apps use a different definition of "back" than browsers do, and there are times when the two treatments conflict.
Many, or most, use a local in-memory database to keep track of information without going to the server. They update that in-memory store as you make changes. For example you see a list of names: Mary, Robert, John. You click Robert and edit the name to "Rob", the name auto-saves. Then you click "back".
Because single-page apps control "back" when in the SPA, they do what most developers want. They return to a semantically correct page, showing Mary, Rob (just edited), John. Tons of apps do this. This is not what the browser does. The browser, if following the "back" specs, would show the out-of-date names of Mary, Robert, and John.
The theoretical conflict can also become practical. Think through this flow:
* Visit /names
* AJAX for GET /api/names
* See Mary, Robert, John
* Edit Robert's name to Bob, autosave
* AJAX for POST /api/name/4 with the new name Bob
* See Mary, Bob, John
* Click on a link, lets say to Mary's website URL
* Mary's website, new domain, loads.
* ...click back
The SPA loads up, and attempts to GET /api/names. However, the bfcache is at play since the native "back" behavior is running. So the stale API response, with the original names Mary, Robert, John is returned. The list of names on the screen is DIFFERENT than what the user saw after they edited.
Additionally most SPA apps presume AJAX calls return accurate data, however here the names are not the names currently in the database. They are only in the bfcache. You can imagine, with more complex data, ways this can cause complex and unforeseen failures.
This is a very poorly understood corner of JavaScript development even today.
Interesting, if a bit vegan shaming :-p According to the research referenced a vegan diet is about 1.8x as efficient as a normal american diet. Seems pretty good for humanity.
Limiting meat consumption by ~50% would have a similar sustainability impact to a vegan diet.
Seems like poor punishment to downvote Tom here. At the worst he made a blanket statement without backing it up, which is the exact same as what he was responding to.
> I think this is somewhat of a deceptive trap that people fall into. It's difficult to trial something like React unless you set up all the tooling around it, so Ember appears easier because it is blackboxed and sets things up for you.
> However, that means that six months in, when your app has outgrown the constraints of the blackboxed starter, you are trapped.
I have not seen a single company outgrow Ember-CLI. Imagine for a moment a big company with a huge app- Yahoo or LinkedIn or Twitch. These companies have apps that push the limits of Ember-CLI for sure, and have delved into the internals to add cutting edge features like lazy loading or optimized module loading, however none of them have abandoned it after six months.
Ember CLI has a public API for making changes to your build pipeline. Advanced users often reach for direct manipulation of Broccoli trees, another open source documented API with lots of example usage floating around. The "black box" referenced is non-existent. Ember-CLI is more like a car with a good manual. You don't need to understand fuel injection timing to get it out of the garage.
And Ember-CLI is fast. Out of the box it has great performance on Windows, Linux and OSX and there is even more room for improvement. Six months down the road, you will not find out it takes five seconds to rebuild your app. It will still be sub-second.
> it pays ridiculous dividends to understand the stack you're going to have to maintain for the next X years instead of having it hidden away from you.
We share software (proprietary or open) because it spreads the cost of maintenance. As a web developer I have plenty of work already, maintaining my own build pipeline is no more desirable than maintaining my own rendering engine or my own operating system. We always solve problems atop a certain level of abstraction.
Ember-CLI is the result of a concerted effort by individuals and the community that started in 2013. The project is clearly a massive success, demonstrated by its overwhelming adoption by Ember users (well over 90%, it isn't that popular because it sucks). It is a disservice to Ember-CLI to blow it off as "not scaling past six months" and to yourself as a developer to disregard Ember-CLI's hard-won lessons about how to build a good common build pipeline.
tl;dr please don't presume Ember-CLI is flawed because it "appears easy", making the hard look easy is a worthy goal.
Hopefully there is a Googler reading who can answer this: I'm curious why the README.md says
> Note: This is not an official Google product.
However the copyright is Google, and you must sign their CLA. That seems pretty official to me? Or is there some other implication to "official" beyond ownership?