Hey, we (David Beesley, @david on the elm slack) are excited to share with you a new open-source visualfront-end framework for building complex web applications. The funk web frontend is built 95% on elm. As an underlying UI layer we use @mdgriffith’s elm-ui. tips imaginary hat, also nods to @passiomatic!
funkLang, or funk for short, combines visual and code workflows allowing designers, developers, and low-code users to work together in a single environment. funk is different from WebFlow, Wix or bubble as it will fully-featured like Elm or React, rather than a limited templated low-code tool.
We would love to get your feedback on funk and support to help us continue to build it; please star us on GitHub, follow us on Twitter, and reach out to us on our Slack or the elm Slack if you want to chat more about using funk at your company or need any support.
Be careful with all the text fields though, that could give a fatal first impression. There are a lot of places where they overflow their parent containers. I don’t know if that’s a restriction of the current state of your product or just the way those sites were build. If they are based on elm-ui, it feels as if you were using el [] (text "some long text") instead of paragraph [] [text "some long text"].
Thank you, that is exactly what we are aiming for. I believe that our time as web developers is more valuable than just changing button colors and fixing layout bugs. We should use our creative energy to create personal or business value, not just be the messenger of an expert like a designer to translate things into code.
When we are commercially successful we are planning to invest resources into pushing elm as a language forward. That can mean bounties or hiring people to work full-time on ecosystem-critical projects like elm-ui.
Yes, JS appeals to the wide audience but it also lends itself better to writing smaller scripts. The problem with elm is the need of an installation/compilation step while with JS you can do everything in the browser, from importing packages to compiling modules and running them. That means for elm we needthe elm-in-elm compiler to be feature complete or ping elm code to the backend and compile it into an async JS function.
Right now it is not on the top of our list but we do understand the benefits. Probably the ellie-app source code will be of use when building this.
The typo is fixed. Thank you.
We are aware of the scrolling issue and it will be fixed in one of the coming releases
To share source code we plan to enable linking a GitHub repo as a source of truth. Funk uses git as a storage layer under the hood right now. This is part of the strategy to marry designer’s and developers workflows. This means you can just git clone funk projects and push them back to funk.
This is awesome!
It’s also quite funny coz I started playing around with something similar and told a friend of mine that most likely something like this will pop up soon since it usually does when I get an idea
Can’t wait to give it a try!
That’s interesting. Are you also working on a free-form drawing tool?
There are many products out there that try to make development more accessible so obviously we aren’t the first ones with the idea either. It’s always execution that matters.
I don’t know the definition of free form drawing tool tbh but my version is more comparable to https://openchakra.app I think. Given my track record on finishing side projects, I am not very confident that I’ll finish it, but it is fun to play around with! Regardless of that, I think it is gonna give me some insight into why these tools never seem to gain traction.
I see! Let me explain free drawing. We aim to make the experience closer to figma or sketch with a canvas and different modes to create and modify shapes. We believe that this UX more closely matches the mental model of design experts (one user group of funk). Funk aims to ease friction of handoff from design to development in ‘real/professional’ product teams. This is why we aim to cater a designer-centric experience for the web UI.
Drag and drop interfaces have advantages when handling pre-built components as non-design experts (e.g. marketing or management) and to communicate constraints of a platform (like we layout) but it’s not really intuitive when creating custom designs. We are evaluating this because we see that many users just want to “present my product” or “show a login screen” with least hassle. Drag and drop goes well with templated approaches.
For developers we are working on a CLI that will allow you to run funk locally and author code in your code editor. That will allow you to write custom logic and UI components. When designing this feature the same principle holds true - we are trying to come towards our users - devs can keep tools they are familiar with. That is their terminal, git, their code editor.
I think it is gonna give me some insight into why these tools never seem to gain traction.
It is indeed important to identify reasons for failure when trying to build something that big . We see ease-of-use, value-creation (what can I actually build with this?), developer acceptance (am I making sustainable tech decisions as CTO and can I still use familiar technologies?) and pricing as reasons for failure. One big problem we also perceive is that most tools are one-way . This means that once you go from design to develop and start coding things get out of sync. You can not transfer stuff from code back to design. We believe the work designers do should not be treated as throwaway-artifacts.
I agree! But then it is also very difficult to go bi-directional…
What I usually discover at work is that we get handed a design, we start implementing it but then have to tweak it either because what the designer made is not 100% feasable or because requirements change, we might get a design update but most likely not because the designers moved on to a different problem. And if they did a change then the exported data that a tool might create does not have the code tweaks in it that we implemented on the developer side in the meantime… It’s tricky. Hopefully your tool finds a nice new way of solving this. I am looking forward to the export code feature that I belive you had on your “coming soon” tab.
We are planning support for shareable component libraries. This would allow anyone to create styled libraries, including in the material design philosophy. I believe right now the styling tools are sufficient to create paper-like effects as in material design.
Of course you are correct that it would be possible to implement Material design using the existing tools where you can add any color and use them in any way you want.
According to my interpretation of what I have seen Funk does not currently have a theming mechanism where each color has has an intended use. The risk I see is that each developer chooses their own way handle colors in their components and it will very difficult to to mix components from different developers to make it become a coherent application.
Materal design is a well known and well documented design language that is easy to point to.
It contains 12 colors with specific use which can be used as a color theme that can be used throughout a complete application with components from different sources:
Primary
Primary variant
Secondary
Secondary variant
Background
Surface
Error
On Primary
On Secondary
On Background
On Surface
On Error
See two examples of color themes here. But naturally an infinite number of color themes are possible according to taste.
Personally I think that the possibility for Funk to make a breakthrough in the market depends on guiding developers to go in the same direction. If all components work together in theming then the devopment can be accelerated and thus the value will be much higher. If everyone does things their own way you would still have to rewrite shared components in order to make a cohesive application.
Naturally there will be companies that have their own designs rules. But it would be great if those that would like to cooperate could create common fast lane for development.
I hope you don’t see this as a criticism. I just want that all the really interesting and good work you are doing shall have as much impact as possible.
thanks for the feedback. I think we actually agree. The example of different colors and their usage inside material design is great!
Personally I think that the possibility for Funk to make a breakthrough in the market depends on guiding developers to go in the same direction. If all components work together in theming then the devopment can be accelerated and thus the value will be much higher.
Funk aims to solve a coordination problem, not a technical one.
I am frustrated that in UI development you often just translate designs and then fail to deliver to the quality that designers expect. Our respective expertise and human creativity can be used a lot better. Developers should complement the skillsets of designers, not be assembly workers further down the line.
Our solution: We want designers and developers to collaborate more closely. Designers set up the design system and components in funk and then developers can use them in their toolchain. Funk projects are tracked already tracked in git. This means that designers and devs can share the very same substrate.
What is possible right now? In the design system tab we have a colors tab. There you can define colors and name them. There is not reason why you should not be able to replicate the basic material design theme.
We plan to extend the color in the future with features like different themes, contrast / accessibility checks as well as color modification and generation tools…
We have to acknowledge that different design systems work differently and obey by different laws. We yet have to identify what are the best practices that UI designers use to craft comprehensive color schemes. This is a big topic ranging from accessibility through aesthetics to color theory. A guide that we will be following to instill best practice is the book ‘Refactoring UI’. A must-read!
but my version is more comparable to 
Drag and drop interfaces have advantages when handling pre-built components as non-design experts (e.g. marketing or management) and to communicate constraints of a platform (like we layout) but it’s not really intuitive when creating custom designs. We are evaluating this because we see that many users just want to “present my product” or “show a login screen” with least hassle. Drag and drop goes well with templated approaches.
. We see ease-of-use, value-creation (what can I actually build with this?), developer acceptance (am I making sustainable tech decisions as CTO and can I still use familiar technologies?) and pricing as reasons for failure. One big problem we also perceive is that most tools are one-way 
. This means that once you go from design to develop and start coding things get out of sync. You can not transfer stuff from code back to design. We believe the work designers do should not be treated as throwaway-artifacts.