At the very high level, yeah that's pretty much what's happening. We generate IDs that we map to each of the elements statically and that we inject into the DOM so that we can capture metadata about the element. We're currently writing an in-depth explanation of how this all works, which will be uploaded on our blog in the very near future.
Wrt the VS Code plugin, it was an idea we were toying with. Ultimately we decided to go with a standalone editor because we didn't want to limit our market and run the risks involved with coupling our existence to them. That being said, a VS Code plugin is absolutely in our future and something we would want.
You're absolutely right that by targeting React we are mitigating some of those issues you've mentioned, but they are still issues that we still need to address, so we do need to adjust or introduce further tooling. All of these things are on our roadmap, but we're a small team so it's a case of prioritising, which is where comments like this come in to play as they help us add weight to those priorities.
We've got a long way to go, but thoughtful and constructive comments like these help us immensely along the way :)
That's absolutely true for sure, and I'd go so far as to argue that it's one of (if not the) primary driving forces behind development tooling decisions. Whereas some changes are well suited to e.g. unit testing (and where a passing suite of tests provides that instant feedback), when working on the design or interactions of an interface it's very important to actually "see" and/or play with the result of each minor tweak, so the faster you can make that loop the more pleasurable the development experience will be.
That's exactly our aim - if making a change via the canvas or inspector doesn't result in production grade code then the tool is failing in our eyes. We're well aware that there are parts where we're not hitting the mark there (effectively we're in an alpha stage here), but we're working hard to improve that.
Our goal isn't a no-code tool, but rather an editor that provides the tools for both developers and designers. We're iteratively improving the level of complexity of code that we can fully parse and expose to the rest of the editor, so you can expect these kinds of cases to become fewer and far between over time.
If you do have specific cases that you come across and are interested in following the development or just want to let us know of them, please do file an issue on our GitHub repo.
Hmmm that's incredibly frustrating. I'm trying to reproduce this but failing. Are you able to do this every time? If so is there any chance you could take a screen recording please to help us debug it?
This is ultimately one of our goals, to allow maintainers of those kinds of libraries to publish that kind of integration, or for us or even other users to provide it (thinking along similar lines to TypeScript type definition files)
> How would you hydrate the app with data while you dev?
This is precisely what the scenes are for in the storyboard.js file - it allows you to create multiple scenes that render your components with different data / props.
Yeah we wanted to go the open source route from the beginning. The thinking was that it would help us build a community with meaningful relationships with our users (or at least the ones that get annoyed enough to log bugs or even contribute), but also most of our favourite tools are open source.
We had this question earlier in a reddit submission so copying and pasting the answer here (so that you don't think I'm being insincere!) - We fully support styledComponents, or any valid React for that matter. You can even use utility CSS classes in code. The design tool can edit some of these today already (e.g. you can pass in additional styles to a component instance). Better support for creating and managing styledComponents / Emotion is high on our roadmap so watch this space!
Funny you should mention this, we were actually working on it for a while before SwiftUI was revealed, but taking a slightly different approach at the time (the original approach was more inline with Unity, meaning an engine would be required to run the apps). We had reached the conclusion that that approach was wrong (primarily because of the lock in and how much of an uphill battle it would be for us to move to away from it), and had just started working on the new code-first approach when Apple dropped that at WWDC. Our jaws hit the floor because we knew we were on the right tracks then.
Thank you! This is pretty much exactly the ethos behind Utopia - that there is ultimately some underlying thing that you want to make changes to, but you often want to be able to make those changes from different viewpoints (or in different contexts) depending on the types of changes you want to make. The React paradigm, especially with functional components, is absolutely right for this kind of a tool.
One possible path is to push for a senior developer role and then afterwards a tech lead (or similar) role (perhaps not at the same firm). That will then open up CTO or dev manager roles in startups. It won't "just happen" - it will require a whole load of work on your behalf (you'll need to learn your way around a broad selection of technologies rather than focussing on mastering one language and one platform, as well as learn a number of managerial skills including effective communication, negotiation etc.). Good luck! Disclaimer: I'm not a CTO but have been offered a number of CTO and dev manager roles at startups and small companies.
Thanks for the feedback! To answer your questions:
1) Currently, yes, though that is something that will definitely be implemented as we work on this further
2) Laziness there is something that we're going to look into. We need to first assess how much of an impact it has on performance - if that's big enough to warrant taking further (which it likely will be for more complex apps) then we need to figure out the best way to perform a deeper diff of the model
Good luck with the F# port - I'd be very interested to hear more!
This is still more or less at a proof of concept stage, so you won't be able to use it to build apps, but it will introduce you to some functional reactive programming concepts
We're actually aiming to build UIs that would match this level of complexity (if not even more complex), so it will be interesting to see how this pans out. I'm not massively concerned about it being an issue tbh (though thanks for flagging it) - the real issue that I'm concerned might swallow a lot of our time will be how we implement animations using this architecture (though we're currently looking to React JS for inspiration there).
Hmmm, sorry if it's not clear but we aren't replacing views after the diffing, we are updating them (that's what we use RxSwift for). The diffing is used to determine which views to add, which to remove, and which to update.
The hardware video game rental business is already (almost) dead. I'd imagine we will soon see digital rentals much the same way we currently have digital film rentals.
The list will only be sorted enough to find the minimum"
This may be technically true, but is a pretty bad example with much hand waving - what exactly does it mean to be "sorted enough to find the minimum" given that Haskell uses a merge sort implementation internally?
A better example of Haskell's lazy nature (taken from the Learn You A Haskell book) would be:
take 10 (repeat 5) - it's very easy to comprehend taking the first 10 elements of an infinitely long list without needing to compute the entire list.
This book looks very interesting, and one that I want to buy, but I'm going to hold off on buying it at the moment because (based on the comments in this thread and the preview) it sounds incomplete. Any chance of you selling a work in progress version so that we can help out (akin to the Manning Early Access Program)?
You don't have to release it via their distribution platform - you're free to distribute it as you like. They only take the 30% cut if you distribute it via them, which I'd say is pretty reasonable. FYI I'm not in any way associated with Turbulenz - I'm just at a conference where they demoed it.