I'm working on something similar (i.e. a content editor for developers) with Vrite, that's already open-source: https://github.com/vriteio/vrite
It's not the same as acreom (leaning more towards a CMS-like platform with API, real-time collab, etc.), but is well-suited for e.g. creating knowledge bases.
MDX, with the custom content involved, is though.
I've been working on a hybrid WYSIWYG editor for MDX at Vrite (https://vrite.io).
Currently supports custom block elements and JSON-serializable attributes. Now looking into inline content and building an extension system to render custom previews for the nodes.
Check it out if you're interested - it's also open-source.
I want to think of marketing as a way of providing valuable content and explaining why your product might be just what the consumer needs (potentially helping them with their problems).
What's described above really doesn't fit into this view, but is definitely how I've seen people "play the game". ChatGPT-generated fluff, copied content, and the same tips & tricks, inspirational stories, etc. you see repurposed all the time on different platforms - especially LinkedIn.
I hope marketing can be good and value-adding but, the way it's going right now, we're due for a change.
Happy to see the SIM card go away. eSIM provides just so much better experience.
This also enables easier installation and setup for basically any carrier. Just download the app, configure eSIM and you're good. Maybe the easier switching is why adoption is kind-of slow on the carrier side? Easier to keep you locked-in with more obstacles in place.
Seen some comments mention potential issues with it vs physical SIM, but I hope these get resolved with time or standard solutions are developed. Personally I had no issues with it, using it for over 2 years now.
I often hear about people having issues moving their eSIM from their old phone to their new phone during new iPhone season. I don't see why I would want that failure mode to exist. With a physical SIM, it couldn't be more straight forward; pop the card out from the old phone and in to the new phone. You don't need permission from anyone, you don't need an app, you don't risk having something fail and having to contact support, you just ... do it.
And if your phone breaks or something and you need to use your old phone, or borrow a friend's old phone, or whatever, you just move the SIM over.
Perhaps you've never actually participated in "new iPhone season" but it never involved moving your old SIM to your new phone. New iPhones came with a new SIM, and part of the activation process involved deactivating your old SIM and activating your new SIM.
As a consumer, eSIMs are fantastic for international travel. I can have a prepaid international data plan up and running before I even get off the plane.
That must be a US thing. Any time I've gotten a new phone (be it iPhone -> iPhone, iPhone -> Android or Android -> iPhone or even Sony Ericsson -> Sony Ericsson back in the day) I've just popped out the SIM from the old phone and put it in the new. The most recent was iPhone 7 -> iPhone 12 and it just worked then as usual.
The only exception is when they've moved to a physically smaller SIM card format.
That's not true. For the last few iPhone upgrade cycles, everytime I got a new iPhone I just removed the SIM it came with, and popped in my old one. Everything worked. The only time i replaced the SIM was when 5G came out and it required a new SIM to work.
I change carriers so incredibly rarely (way less than once per decade) that I've never even considered that as an annoyance. Even if I did switch carriers, I can't imagine that I'd have found it to be much of an issue, switching carriers isn't exactly urgent. And the one-time cost of a new SIM is really low.
But I will admit that it's a potential advantage of eSIM. If you do switch somewhat frequently, I can see it being convenient (assuming all the technical stuff works out).
Depends on where you are, in a lot of the world a new sim is a few dollars from any convenience store on every corner, whereas I have no idea where I’d have to go to even talk to someone about an eSIM.
The main benefit is that it's easier to have multiple eSIMs than to have multiple physical SIMs. Sure you can only have one active simultaneously (I think?), but that's better than the status quo of physical SIMs.
I'm a US/UK resident, and I use an eSIM for my US provider and a physical SIM for my UK provider. Since I use both numbers for various localized services like 2FA, food delivery, etc., the ability to have multiple SIMs has been a huge improvement compared to just a few years ago, when I had to have two phones to be able to log into my bank.
Are the US eSIM only iPhone models rated better than the EU traditional SIM models? I was under the impression that they're all pretty water resistant these days.
No, it only provides a better experience if you change SIM card more often than you change your phone, which isn't the case for most people.
eSIM card transfer can be a hassle, expensive or outright impossible because it's up to the telco to decide it. I had to visit a store in Thailand to transfer my SIM card. I had to pay $ to re-download my eSIM for another operator. I was simply told "can't do" with a still-active eSIM I bought from Airalo.
Definitely nice to "download SIM cards" instead of buying them, but everything that follows is a pain.
Hmm, that seems a bit worrisome for someone like me that doesn't have Play Services and only uses software from F-Droid. I haven't really investigated this.. does it always require an app?
Oh man - My partner pre-ordered an iPhone 14 Pro on launch day, first iPhone with an eSIM. Set up was a nightmare and took over a month to get resolved. She thought she was going to lose her phone number at one point. Still don't know if the fault was with Apple or AT&T but leaning AT&T based on some of the conversations we had between the two teams.
Flash forward a few months and my upgrade and provider change went through without much of a fuss.
Of course there can be the chicken and egg problem of you need Internet to provision the eSIM, but until you get the SIM running you have no Internet. WiFi isn't always available.
I've seen quite a few Postman alternatives pop up recently (quite curious what's the reasoning behind that?). Currently I'm mostly using Hoppscotch - also open-source with pretty sweet UI, and Thunder Client in VS Code.
That said, I'd consider switching for type-safety (or more specifically auto-completion) if there was an ability to e.g. import existing OpenAPI schema and automatically pick up the types.
My guess at the Postman-alikes. Postman has evolved way past its original usefulness and is aggressively trying to push enterprise features and anything to make the business sustainable. I'm not mad at them for that but eventually you remember that you just wanted a graphical curl to mess with, not a team secret manager with workspaces and a test runner etc.
The basic functionality starts off pretty easy to build so there's a large pool of people who decide to take a crack at it.
I haven't really explored WASM hands-on (I'll give this guide a try) but, given that it's already been a few years, I think it's been hugely beneficial for web development.
Not the "JavaScript killer" some where hoping for, though it was never meant to be one. Instead it integrates pretty nicely within the existing ecosystem, optimizing existing use-cases and allowing new ones when heavy computations are required. Net benefit for all web devs - faster libraries, impressive dev tools and more portable node binaries.
I've been watching WASM from afar, and it's my understanding that it's not a JS killer because it doesn't have direct access to the DOM or to most DOM APIs. I'm curious if there's another reason I'm missing?
Is being a "JS killer" even a goal of WASM? From what I understand, WASM's goal is to allow computationally heavy workloads (e.g., image and audio processing) to the browser by providing a compilation target for C code. This is how we get nice things like Figma or MS Office running in the browser.
Let WASM do the number crunching, let JS do the UI.
It's not the goal from what it seems. But it's definitely what would make it the most interesting to a lot of people, and it's what I think most people expected at some point.
For a lot of companies the only place JavaScript is ever used is on their website frontend. And it makes you wonder, why does it even still need to be JavaScript? With the rise of SPAs and the fall of normal document based websites, browsers are basically just becoming their own platform like Windows Desktop, Mac, Linux, Android, iOS, etc. You could say it's been that way for a long time, but more and more apps are becoming web based only because the browser is now powerful enough to run what used to be a desktop application.
Browsers are literally just a VM with an address bar. We go to a URL and run a program, except right now there's basically the limitation that the program has to be written at least partly in JavaScript. Being able to deploy an entire website as WASM is just the next logical step from what I see.
DOM bindings in WASM would be awesome. I would be a happy nerd if I could do all of my web dev in OCaml.
In the meantime, WASM has real, just not for front end dev.
The two language problem is hardly unique to web dev. It’s also ubiquitous in the machine learning/data science space with Python and C/C++/CUDA playing the roles of JS and WASM, respectively.
> DOM bindings in WASM would be awesome. I would be a happy nerd if I could do all of my web dev in OCaml.
DOM is not enough for that. You almost certainly would like to be able to communicate with your backend ;)
Here is a list of the "usual" web APIs: https://developer.mozilla.org/en-US/docs/Web/API
And everything that needs network access or access to local resources (file system in the worst case) will never happen to WASM because of security considerations.
The issue here is the same-origin principle, which rules out most low-level networking (since you could just bring your own SOP-ignoring HTTP client).
Personally I think that enforcing the SOP at all cost (and even when no cookies or other authentication headers are injected by the browser) is misguided at this point and holding back modern webapps.
I find that these compile-to-JS languages are great until you want to bring in other JS libraries. Then you’re stuck writing bindings which is annoying, and often brittle if you’re not really careful.
You can certainly bridge the DOM to WASM with a virtual DOM. The problems with WASM are not just interoperability.
The biggest problem is tooling. You cannot build tooling for in-browser WASM because it runs in a browser sandbox. JS has the same problem but the difference is that JS has a known object model that the browser can provide good tooling for.
Whereas with WASM the browser has little insight into what those opaque Memory objects contain. So you need to bring your own tooling and run it inside the sandbox, and the sandboxing does not make this easy.
Let’s say for example you want to pause execution, inspect the object tree, and run a REPL while it’s paused.
Yep. Give access to the DOM - perhaps via a batch update/fragment mechanism and watch as it becomes a JS killer. But WASM is currently a starved prisoner locked up in a room only allowed to view the goodies outside the cell door.
It doesn't have access to _anything_ (in the browser, in other runtimes there is WASI with POSIX functions). Everything has to be imported from or exported to JS.
And currently using anything but C, C++ or Rust isn't feasible, as the runtime needed for a GC is way too big. A Haskell "Hello World" for example is about 1MB (even after running `wasm-opt` on the generated WASM binary).
I do agree things like the GC are very large if we're comparing against standard JavaScript, so I don't believe the technology is ready for standard customer facing websites. For things like internal applications/extranet type applications, I think that the runtime download cost is minimal compared to the functionality that you are given with a proper framework (I can only speak of Microsoft Blazor, but that's just language ignorance, and I know there are other that fit the model as well). As a web developer that also writes utilities to run on the desktop, for things such as ETL or fixing bad data, being able to not switch to another language or even really framework is a huge boon for my time. I know JavaScript, but being able to rarely have to deal with it keeps my head in what I'm solving, rather than having to context switch between interface and server.
This is kind of subjective, and in the context of "is this a JS killer" which is what you're answering, I'd agree, it makes sending the Wasm to the browser a bit of a non-starter that it requires a large bundle most of which is simply boilerplate for whatever runtime, without some type of local storage and persistent cache it's difficult to imagine using Ruby in a Wasm for example. If you're deploying to a container, where you're able to use a cache warmer to ensure the wasm is ready before it's called, then a 1mb binary might not be such a big issue.
(I mean, it is still a big issue because the point was fast cold starts, and big assemblies mean no fast cold starts, but again, subjective value judgments... 1mb isn't too big in many cases and I'd wager most of the cases that I'd really care about. But in a browser...)
But if you're not trying to run the Wasm in a browser then it's still potentially quite useful. You might not be running all of your Wasm in a browser and it might still be a JS killer, and all of those might not be in conflict.
Well, the main reason why I'm taking a deeper look at WASM is because I'm creating a language and compiler that is optimized to compile to WASM.
While I don't think that my compiler will be the JS killer, I do think that WASM languages using a (the WASM) GC have a future.
Virgil compiles to Wasm and brings its own GC as well, and the runtime is on the order of about 4KB. The GC is a simple semi-space copying collector and the compiler prunes away dead code from libraries, so binaries are pretty small. So overall I don't think this is a Wasm issue as it is mostly a language runtime size issue.
Depends what you mean by "integrate". It always has to import or export JS functions or memory. WASM (without WASI) has no direct connection to "the outside World", everything has to be routed via JS FFI. So you can import or export a SharedArrayBuffer to communicate with JS.
https://developer.mozilla.org/en-US/docs/WebAssembly/JavaScr...
But you need the WASM thread extension (for atomic access to the shared memory) to be able to use shared memory.
WASM essentially can call javascript functions that were imported, and I believe javascript is able to read WASM's memory (a big help for transferring strings). If you're using something like Rust, all the glue code to call any JS APIs can be automatically generated for you with wasm-bindgen, so it really isn't a huge problem usability wise. It's just not great for performance.
The fact that it’s available on mobile and that it allows for “embedding” a good-enough dev tools into your web app, does enable interesting use-cases.
Of course, it’s not the go-to for complex or extended debugging sessions but still impressive.
I’m building something in this space and I’m curious what’s the appeal of the former vs the latter?