Modyfi | Engineering + Design | REMOTE | Full Time | US, UK, Global
Modyfi is building the future of collaborative image editing and visual creative tools on the web.
We are primarily looking for mid to senior level graphics engineers to join our team building our high performance image processing engine in Rust, WASM and WebGPU (though Rustcurious C/C++ engineers will also be very welcome!).
If you are passionate about image processing, Ai image generation, GPU programming, color, realtime graphics or interactive creative tools then please get in touch!
Our team is 100% remote currently spread between Los Angeles and London timezones.
I'm not at all surprised about the response here. We are a community of people who love function over form (the perfect emblem being the purely functional design of our beloved HN). And in all honesty, my initial reaction was the same.
But we'd do well to bear in mind that:
- Most of us are not the intended audience.
- The purpose of the site is not what most of us expect. They are not trying to create leads from this page (hence the lack of useful information and call to action).
- And tangentially, the internet isn't only about function or utility.
I sympathise with the compulsive need to pull-apart a website with >300kb javascript, scrolling to get more information and unnecessary animation when it gets in the way of you using a site that you need. But surely this is not one of those times. Instead why not treat it like you are looking at an abstract piece of art. Sure a 3 year old could have made it but that's not really the point, is it?
I already found it frustratingly ambiguous that there could be more than one Manchester in the US, then I checked and it turns out there are more than 30
My only feedback is the gray text (#808080) on the dark gray background (#222222), has a contrast ratio of ~4:1 which some people may find difficult to read (and slightly below WCAG recommendation for regular text[1]). I think you can lighten the text slightly without disrupting the surrounding color hierarchy.
> Should you review the code of all imported modules? This is virtually impossible.
I wouldn't be surprised if this was exactly the direction that Deno was trying to move towards. Fewer direct dependencies with some amount of transitive trust.
I.e. "[Deno] has a set of reviewed (audited) standard modules"
> Windows CP without SP 2 and Internet explorer bellow 6
I get the point you're trying to make with this hyperbole but browsers still let you view http pages (by default).
> Deno must disable http by defaulkt and provide a flag to re-enable it. This is factually a security issue in Deno.
Again I agree with your idea about disabling by default but there is another perspective (and I think Ryan deserves some empathy).
> ... there's a tendency to start over when the development gets hard to maintain or support instead of just fixing the mistakes.
The thought that Node.js should have been 'fixed' instead of creating Deno is where I disagree. At a glance I can see a few reasons:
- Node.js maintainers + community may not even think there is something to be fixed (see various discussions in this thread about module resolutions)
- Politics, death by committee, inertia
- Effectively a dependency with npm registry (although not technically)
- Lack of backwards compatibility with changes (e.g. module resolution)
> The thing is, I can see Beepboo 1.0 being announced in 2025
Node.js was initially released in 2009 so it's probably fairer to suggest Beepboo 1.0 will be released in 2030. And yes, if it improved on Deno and solved inherent problems that couldn't be solved internally, I would wholeheartedly cheer it along.
I think it's also worth mentioning that Node.js is at a level of stability and maturity that people who plan to and have already built on it, aren't left abandoned.
I find it amusing that you use the example of Python 2 -> Python 3, a breaking change in a widely used language, that has famously been very difficult and long for organisations to deal with.
Compare that with javascript which has never had a breaking change. On top of that Typescript is a backwards compatible superset of javascript.
More to the point, Ryan has a humble explanation of what regrets he has about Node.js[1], why they exist and in some cases why there isn't an easy fix.
The point that I assume you're making, that sometimes it is better to spend significant energy to fix something, rather than throwing the baby out with the bath water, is a good one. However I'd suggest this is not one of those cases.
Would you say linux is insecure because a user can download an arbitrary shell script and run it?
I know it's not an identical problem, but it does demonstrate that we probably agree that the onus is on the user to assess the risk of any arbitrary code they run on their machine, including the risk associated with the transport they use to obtain that code.
Funnily enough I actually agree with you that I would prefer to prevent http imports by default. However doing so won't make importing a library secure, and conversely allowing it doesn't mean it is insecure.
As an aside, I noticed you have posted the same one line message about the risk of a MITM attack with http imports 4 times in this thread. You might find it more helpful to contribute to the discussion by explaining why you think that.
Any possibility of a way to purchase outside of the AppStore? I appreciate this is extra effort for possibly little extra reach but I have managed to survive without signing into my icloud and hopefully won't ever.
Interesting to see the comments suggesting that we should expect the NHS to pay if there is a problem that needs solving. It seems the implication is that labour should never be done voluntarily (even in a crisis situation) in a free economy. I find it bleak that we expect our societies and markets to function, solely driven by "selfish" value-chasing individuals.
As someone who has grown up benefitting from the NHS, I will sign up to volunteer, and am glad to do so. I wouldn't be surprised to see ample response from the rest of the nation.
Interestingly, in the past I've also experienced private health-care in the US, and yet wouldn't consider volunteering in the same situation on that side of the pond (and, of course, they likely wouldn't ever ask).
I've worked with a number of bootcamp graduates and I've found the experience extremely refreshing. There are perspectives, skillsets and domain expertise that can come from having transitioned into an engineering career later or from other fields, that more conventional computer scientists often don't/can't have. Whilst there are situations where pre-requisite CS knowledge is crucial, my experience is that there are equally many where that doesn't factor heavily into your ability to effectively work in a technical role.
I don't mean to be disrespectful (but will risk doing so as I thought the original question was negative), but ironically as an employer I would place preference over the ability communicate effectively and respectfully, unlike the way the question above was asked.
N.b I'm a "vanilla" CS grad (although wouldn't claim to have an in-depth knowledge of the areas you've listed twice).
It's refreshing that the author acknowledges the nuances around tradeoffs of using, and not using, GraphQL.
Having used REST (with swagger/openAPI), gRPC and now graphQL, the most painful thing has been the tribal militance from supporters of each, defending their own vested interest.
It's almost like different tools are useful for different things.
I'm surprised there's no mention of Kessler Syndrome[1]. Launching, possibly multiple, high volume satellite networks is worrisome to me. Is the increase in number of satellites negated by the reduced launch debris from using reusable rockets?
Is there an implication that an increase in global cargo capacity also increases our ability to "launch" debris reduction/removal efforts?
Modyfi is building the future of collaborative image editing and visual creative tools on the web.
We are primarily looking for mid to senior level graphics engineers to join our team building our high performance image processing engine in Rust, WASM and WebGPU (though Rustcurious C/C++ engineers will also be very welcome!).
If you are passionate about image processing, Ai image generation, GPU programming, color, realtime graphics or interactive creative tools then please get in touch!
Our team is 100% remote currently spread between Los Angeles and London timezones.
Also hiring for front end / full stack roles.
Tech stack:
- Typescript
- React
- Rust / C++
- WebGPU / WebGL2
--> See all our job postings here: https://angel.co/company/modyfi