mixonic

A very good book on the zero-day market (amongst other topics) is 2021's This Is How They Tell Me The World Ends: https://thisishowtheytellmetheworldends.com/

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:

* Design Systems Engineer https://boards.greenhouse.io/addepar1/jobs/5449804002

* Web Architecture Engineer https://boards.greenhouse.io/addepar1/jobs/5449817002

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.

OpenEMR collaboration happens on GitHub: https://github.com/openemr/openemr

Yeah it started in CVS in 1998ish :-p

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!

Indeed, those who develop browsers are on it!

https://github.com/tc39/proposal-realms

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.

Try it out and let us know what you think. You can join our Slack: https://mobiledoc-slack.herokuapp.com/ or find me on Twitter as @mixonic.

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.

There was a lightning talk on TypeScript at EmberConf that also gave a status update on how TS and Ember work together:

* https://www.youtube.com/watch?v=ZCHFjGSCqP4&feature=youtu.be...

It looks like full support could be landing soon. I know TS 2.2 added flexible enough class modeling to handle Ember's object system: https://blogs.msdn.microsoft.com/typescript/2017/02/22/annou...

Of course we're attacking that from the other side as well, and experimenting with native ES classes in Glimmer.

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 does the "mentorship program" look like? It is mentioned several times but not with much detail. (https://twitter.com/mixonic/status/788046983437037568)

* Can provide context re: "Today the JS Foundation touts a new open, technical governance structure"? What are the changes, and what led to them? https://twitter.com/mixonic/status/788038708364587008

* 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?

Thank you!

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.

[edit]: formatting

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.

W.K. Kellogg funded the research. Their grant: http://www.wkkf.org/grants/grant/2009/02/foodprints-and-food...

Whoa. Getting pretty well shared around the web.

I want to be clear that it seems there is an attempt at accurate data: https://twitter.com/rikschennink/status/736618354098737152?s... but the implementation is a completely failure.

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.

[edit]: formatting :-p

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?

Np! There is also a #-fastboot room on the Ember Community Slack, directions for jumping in there can be found on emberjs.com: http://emberjs.com/community/

Opening an issue on https://github.com/tildeio/ember-cli-fastboot is probably the best way to get help tracking down a bug.

Hm, I don't think some of the things we're working on are easy to implement on top of Draft, but I've only browsed the (very good) documentation so far. Perhaps I'm wrong.

For a first, I'm not clear on how you would write a custom renderer against the data structure (we try to do this for Mobiledoc [0], and it has helped contributors). It seems straight ahead to derive looking at it in a debugger, but I would love to see a link to the docs on it in case I've missed them.

As for cards, we've worked hard to make sure cursors work well around cards, and around atoms. There aren't any demos of "Custom Block Components" [1] in readonly mode, but based on the inability to place a cursor after a "Code Block" with arrows when it is last, I think Mobiledoc might be a bit more robust at this date.

But conceptually custom block components are very similar to Mobiledoc cards [2]. Block based rich content with an object payload. We provide a non-block construct called "atoms" that are inline as well, for things like `@mentions` in text.

This is really neat stuff, but yup, we've been playing around with similar ideas for a few months! Happy to see so much life in the editor world again.

[0] https://github.com/bustlelabs/mobiledoc-kit/blob/master/MOBI...

[1] http://facebook.github.io/draft-js/docs/advanced-topics-bloc...

[2] https://github.com/bustlelabs/mobiledoc-kit/blob/master/CARD...

[edit] looks like http://facebook.github.io/draft-js/docs/api-reference-data-c... serializes the abstract of a Draft into something persistable, and potentially renderable.

(Mobiledoc contrib here)

One thing Draft and Mobiledoc seem to have in common is a robust programmatic API. Draft is pitched as a "framework for building rich text editors in React". Mobiledoc pitches itself as a toolkit for building WYSIWYG editors, so fairly similar goals.

Mobiledoc is designed to be very quick and easy to render, and additionally to support rich content "cards" and "atoms". These are runtime-implemented rich content sections, and our main sponsor for this work (Bustle Labs) uses them for image sliders, animated and interactive SVG features, videos, and more.

These runtime rendering points also make it easy to have multiple representations of a document. For example, we render Mobiledoc into text for ElasticSearch, into HTML for normal web visitors, and into AMP HTML. When rendering into text or AMP we can't use the normal card implementations, and runtime-configuration makes this easy.

And the rich cards work with copy paste! and undo/redo! Anyway, there is definitely overlap here, but IMO the goals of Draft are pretty narrow so far.

I've been pondering corporate roles in modern OSS projects for a few months, especially those in projects that have no single owner.

Supporting developers or community members of an OSS project your company uses through employee time or financial means is less of an investment, and more of a hedge. You've picked up a product off the shelf, however that product has a future direction decided by a number of people in a community.

A company that chooses not (through inaction or action) to participate in the project is relying on the existing powers-that be, and their existing influences, to make decisions that will benefit the company. This is a risk.

A company that chooses to participate cannot control a decentralized project, but they can absolutely influence the software and community by choosing what projects to fund, what kind of roles to hire for, what projects to sponsor, and what to publicly talk about. This influence nudges the community in directions beneficial to the company, and ensures the project doesn't head in a different direction.

For example in the last year the Ember.js community has seen an influx of larger companies hiring positions that include OSS time for employees. Large companies sponsoring OSS work is becoming more common. This means the parts of Ember that benefit large company needs (lots of devices, big dev teams) are getting more focus. The transition is exciting and fascinating to observe.

Support OSS projects important to your company, or accept the risk that comes with allowing foundational parts of your business to be managed by others (without your needs in mind).

There is no conflict in a "buy" button and having an open source app. Discourse offers paid hosting services if you don't want to run the app on your own server.

The version on their hosted service is the exact same as what you can run on your own server. This is similar to the model of other businesses like Ghost: https://ghost.org/

Matt here, one of the folks working on Mobiledoc and the related editor. This blog post definitely served as early inspiration for our work. I dare to say we do a number of things better than medium now.

Mobiledc-kit is on npm as amd and es6. I believe also as CommonJS for browserify, but open an issue if it isn't.

If you use Ember, this add-on provides a more complete UI:

https://github.com/bustlelabs/ember-mobiledoc-editor

https://api.monosnap.com/rpc/file/download?id=kelMhl0A6kbbaN...

Haha, yes this is a pretty high bar of entry.

An article about the rule change: http://www.huffingtonpost.com/steve-jarding/the-democrats-ha...

I noticed our companies Ember.js based SPA site not being indexed well until I added a sitemap. Then it quickly appeared in the rankings.

Historically Google has been using some fork of Chrome 10 when indexing. I'm unsure what impact that is having on the reliability of app rendering, but I also trust the Google search team has done reasonable checks ensuring common sites and frameworks render correctly.

I strongly suggest using a sitemap for JS rendered sites, based on my own experience.