VGG is a cross-platform UI development toolkit that advocates the Design-as-Code concept. The underlying VGG runtime is a graphics engine capable of accurately rendering any UI design draft embedded within your application as a fully functional user interface.

While there are many advantages of VGG and the Design-as-Code workflow, in this post, we are going to discuss only the rendering capability of VGG. We will see the high-quality static rendering effects achieved by VGG, along with the minimal effort required for design recovery, compared to other solutions.

The Figma Design

Let's look into the VGG home page example, which was designed in Figma.

This design contains complex vector graphics as it can zoom at any level without mosaic defects. And there are also many advanced visual effects, such as multiple shadows and corner smoothing, to name just a few.

The Developments

Given such a design, if a developer wants to develop these visual effects with HTML and CSS, it could be tricky, time-consuming, and the final implementation could be less performant.

And if we prefer to avoid writing code, we can utilize low-code tools to publish this design as a website with just one click. For example, we can use the popular low-code site builder, Framer.

Framer provides a Figma plugin that allow users to easily import a Figma design to its own workspace.

By using this plugin, we can effortlessly replicate the same design within the Framer workspace through copying and pasting. And with Framer's publishing ability, we can get a running web site in no time.

Hey there! Have you ever noticed the peculiar visual artifacts on this page?

The most texts are at wrong positions. Some borders have unpleasant black color. There is a strange gray border around the big VGG logo. And all these problems are identified just by a first glance.

If we take a further look, we'll find more problems, such as the lacking of corner smoothing feature and incorrect text layout width

From the perspective of a designer, Framer cannot meet his original design intention. And in most cases, he has to compromise. Because the developer will tell him such effects are very complex to implement and it simply doesn't worth the time.

VGG could achieve the same development speed of Framer with a much more accurate visual effects recovery, thanks to its underlying cross-platform rendering engine. If you have interests, you can go to watch our YouTube tutorial of How to develop and modify VGG landing page in 6 minutes.

The below is how the final web site built with VGG looks like

Conclusion

In this post, we demonstrated the high-quality static rendering effects achieved by VGG, with VGG home page as an example.

But this is just the tip of the iceberg.

VGG has a complete specification of vector graphics that is a super-set of popular design formats, including Figma, Sketch and Adobe Illustrator. And VGG community is continuously incorporating these visual effects into VGG runtime. And there are also future blog posts planned for illustrations like the pitfalls of SVG and how VGG are coming over.

VGG is still at an early stage and we are building VGG community to push it further. Please join VGG community and follow us!

We are happy to announce that VGG 1.0 beta has been released, including the following features, demos, and video tutorials

• The VGG home page is built with VGG tech stacks including Daruma and VGG Container for React by directly using a Figma design as the source.
• We provides a brand-new documentation center for reference of low-level definitions of VGG Specs, and for demonstrations of capabilities of VGG Runtime with some examples.
• We now have stable VGG containers for web, with support for React/Vue/Svelte frameworks.
• We also have experimental containers for iOS and Qt

If you have interests in how VGG home page is made, please watch our video tutorial on our YouTube channel

Please note VGG 1.0 beta demonstrates only basic interactions like URL jump. This is not a finished product and more features will be added including responsiveness and adaptive layout. Stay tuned!

The birth of the rounded rectangle

There is a true story about how the rounded rectangle came to be. As the story goes, it was Steve Jobs who inspired Bill Atkinson, one of Apple's most brilliant early programmers, to implement the idea of rounded rectangles. At first, Atkinson was only concerned with being able to display circles and ovals on the screen, and didn't think rounded rectangles were really necessary. But when Jobs took him for a walk around the block, Atkinson realized that the real world was full of rounded rectangles. Thus, he began developing algorithms to draw rounded rectangles and soon, rounded rectangles were everywhere in Apple's software interfaces; graphics with this design element became an integral part of user interface design.

Why have rounded corners become a design trend?

We see the use of rounded corners in design everywhere in our daily lives. From furniture to electronic device interfaces, rounded corners have become part of the modern design language. Stop and look around to see what items have rounded corners and think about why this design was chosen. By reducing the number of sharp and straight edges, rounded corners make shapes appear softer and less visually jarring or potentially injurious. Whilst looking for features to implement these rounded corner effects, one will find that despite all design tools offering similar basic functionality, each is unique in its implementation and details.

Next, we explore the similarities and differences between the corner rounding features in popular design tools such as Figma, Sketch, and Adobe Illustrator (AI), and how these differences affect the designer's workflow and final design solution.

Creating rounded corners

In Figma, Sketch, and AI, you can adjust the curvature of graphic corners to make them more rounded, as shown in the example below.

In addition, the smooth rounded corners feature in Figma, Sketch, and AI can make rounded corners smoother. In the example below, the orange rounded rectangle has a smoothness of 0%, while the blue rounded rectangle has a smoothness of 100%. One can see that the blue corners are more rounded than the orange corners. Therefore, the orange corners will poke out beyond the blue corners.

In the above example, the curvature of each corner is the same. So, is it necessary to set all corners of a graph to the same curvature? Is it possible to set only one of the corners? Of course, one can easily draw individually rounded rectangles in design tools. But it is not easy for developers to realize this. Our previous article on independently rounded rectangles detailed the difficulties of achieving this effect in SVG and demonstrated how VGG addresses this.

​Different types of corners

Different design tools offer their own unique types of corners to meet the needs of designers in different projects.

In Figma, the degree to which a corner is rounded can be changed by adjusting the corner smoothing feature to create a transition from sharp to fully rounded. This feature of Figma is especially useful for creating icons and interface elements that conform to a specific design language, such as the iOS squirrel icon.

Adobe Illustrator, a professional vector graphics editing software, has an equally powerful rounded corners feature. AI offers smooth corner, rounded corner, angled corner, and inside arc corner; these options allow designers to precisely control each corner of the graphic, irrespective of what it is used for.

Sketch, however, offers a wider selection of corner types, including smooth corner, rounded corner, angled corner, inside square corner, and inside arc corner, which give Sketch more control when working with different styles of corner design. These options give Sketch more flexibility when working with different corner design styles.

Uncertainty through difference

You're probably not too curious, at this point, about why rounded corners have become a design trend, given their benefits in terms of visual comfort, modern aesthetics, interactivity, brand identity, and scalability. More so, the varying functionality of rounded corners from one design tool to another comes into question. As a designer and developer, how should you choose?

In exploring this question, one may find that the differences in rounded corner functionality among design tools are due to a combination of factors such as technical implementation, market positioning, innovation needs, historical development, user experience, and cross-platform compatibility.

These differences not only affect designers' creative expression, but also challenge developers' implementation process. A designer’s carefully crafted rounded corner effect in Figma may require different parameter adjustments in Sketch, while an entirely new approach may be required to reproduce it in Adobe Illustrator. This incompatibility between tools not only adds complexity to the design, but can also lead to inconsistencies across platforms and devices, which can affect the consistency of the user experience.

Developers often face the challenge of accurately implementing rounded corner effects from design tools into code when translating a designer's vision into an interactive interface. Different implementations of rounded corners can lead to display differences across operating systems and browsers, increasing not only development costs but also testing and maintenance efforts. In addition, when designers need to switch between different design tools, inconsistencies in rounded corners can cause workflow disruptions and reduce the efficiency of team collaboration.

With this in mind, VGG was created to provide designers and developers with a seamless design environment that bridges tool differences and ensures accurate communication of design intent. With VGG, designers and developers can confidently move between different design tools to ensure that design intent is accurately communicated while maintaining project consistency and efficiency. With VGG, creativity is no longer limited by the boundaries and limitations of design tools.

So what exactly is VGG?

VeryGoodGraphics

The Next-Gen Vector Graphic Specs with Runtime

Learn More

VGG Specs is a set of JSON-based specifications for the next generation of vector graphics. It includes several specifications such as design, layout, animation and interaction to significantly improve usability and versatility. VGG aims to drive the future of vector graphics and serves as an open standard available to the industry at large. In addition, VGG Specs comes with an official implementation. VGG Runtime is an open source implementation of VGG Specs with cross-platform rendering and scripting capabilities.

In terms of web standards, Scalable Vector Graphics (SVG)serves as the de facto vector graphics format. It is currently supported by a wide range of websites and applications, making it seem very powerful and versatile. Here we discuss the problems with SVG and the kind of specifications that are needed for the future of graphic design on the web.

However, SVG is also a complex specification that attempts to patch together the varying needs of modern web graphics design. This has resulted in slow progress by the W3C, as well as conflicting requirements for different implementations.

Therefore, as a vector graphics standard, SVG no longer meets the needs of today's developers. It includes not only vector graphics, but also complex features such as animation, filters, interactivity, linking, and remote resource loading. This is in addition to embedding HTML, CSS, video playback, and JavaScript functionality. When dealing with such complex and diverse graphical functionality, SVG has had to rely on other web specifications, leading to a gradual erosion of its original advantages. Issues such as poor usability and a steep learning curve are becoming increasingly apparent.

Although SVG 2.0 was released in 2018, many features are still not fully supported. There are many reasons for this situation, but perhaps the most important is that the specification is difficult to read and complex. As a result, there is currently no fully functional SVG renderer – we have only seen partial implementations and no one knows for sure how SVG will develop in the future. For the time being, however, progress seems to be at a standstill. It remains to be seen how long users will put up with such bulky SVG.

Let us examine some of the problems with SVG more particularly.

Lack of consistency in SVG

SVG is a web standard with no official software or engine for implementation. As a result, there are many inconsistent subsets in use, resulting in a lack of consistency in graphical properties for unofficial rendering engines. This means that the same SVG graphic can be displayed differently on different devices and software, and designers often encounter different effects when importing SVG into design tools or browsers.

Sometimes, when one tries to import SVG files from Adobe Illustrator into Inkscape or from Sketch into Figma, they don't display correctly or, even worse, they cannot be opened at all. This is because each editor has its own way of interpreting how things are drawn in SVG. As a result, certain attributes or functions may not be supported by other editors, causing problems when importing SVG files.

One might wonder: “Since SVG is open source, why not implement an SVG rendering engine yourself?” The amount of time and effort this would take are prohibitive; one will also face some challenges along the way. Anyone who wishes to implement SVG has to deal with a specification of more than 700 pages – a veritable mountain to climb. In addition to the SVG specification, there are cross-linking specifications for web standards such as HTML, CSS and JavaScript. This sounds like enough to give pause to most users.

Lack of graphical features in SVG

In addition to the consistency issues of SVG rendering, there are also some intrinsic shortcomings in SVG itself. Some SVG graphics drawn by designers in design tools do not make it easy for developers to achieve certain simple effects, and some complex effects are not achievable at all.

We can take some clues from the following points:

• Gradient mesh and hatching have been removed in SVG 2.0.
• No browser supports adjusting the Z-index rendering order of SVG elements.
• SVG is essentially a 2D graphics format and has no native support for 3D transformation and rendering.
• Text manipulation in SVG is not as easy or flexible as in other formats or web standards.

The reasons for this situation are also quite simple: some browser developers are unwilling to contribute, whilst some design tool vendors are still waiting on the improvement of SVG. The reasons for this situation are simple: some browser developers are unwilling to contribute, while some design tool vendors are still waiting for SVG to improve. This leaves users in a dilemma: unable to create content because design tools do not support it, or unable to render their designs because there is no official implementation.

The power of the new vector graphics standard

VeryGoodGraphics

The Next-Gen Vector Graphic Specs with Runtime

Learn More

Is the era of SVG coming to an end, and will it no longer be the future of vector graphics? We have seen a continued and strong demand from the developer community for vector graphics formats. What users really need is a compact, versatile and easy-to-implement vector graphics format, not an XML-based format. Users can rely on their graphics work everywhere without having to worry about implementing HTML, CSS and JavaScript. This saves bandwidth and computing power, and makes it possible to develop SVG compilers that support compatibility, responsiveness, animation and interactivity.

Fortunately, we have achieved this goal. VGG Specs is a set of JSON-based specifications for the next generation of vector graphics. It includes several specifications such as design, layout, animation and interaction to significantly improve usability and versatility. VGG aims to drive the future of vector graphics and serves as an open standard available to the industry at large. In addition, VGG Specs comes with an official implementation. VGG Runtime is an open source implementation of VGG Specs with cross-platform rendering and scripting capabilities.

We will discuss a number of issues facing SVG as a vector graphics specification and demonstrate the power of the VGG Specification in the graphics space. Stay tuned-in to our blog.

VGG is yet another development toolkit & framework for building interactive graphical applications, which emphasizes the mind-blowing Design-as-Code workflow at its core. And it may hopefully unite two worlds of design and code for designers and full-stack developers.

The mainstream techs for building interactive applications are Web technologies, however, it is not straight-forward to build cross-platform applications on top of Web techs^[1]. That's why many platform-specific frameworks or cross-platform frameworks are still popular, the most famous and innovative among them being Flutter, which takes advantage of part of browser engine to achieve the goal of "Write Once, Run Anywhere"^[2].

So why do we need another framework? Before we dive into VGG and its workflow, let's have a look at other choices.

The Web Technologies

Writing HTML^[3] sucks.

It is very interesting. Because HTML, short for Hyper Text Markup Language, was originally invented thirty years ago for making link-able documents, rather than apps. It is more about a markup than a language. The majority doesn't even take writing HTML as programming, since it is not a programming language at all.

It was not until the advent of HTML5, which is commonly referred to as H5, together with CSS3 and modern versions of JavaScript, that people were starting to make real Web apps.^[4]

And thanks to the optimization team of browser vendors, nowadays the performance of JavaScript is boosted greatly so that the interactive web apps won't be bottle-necked.

Have you ever seen this remarkable picture? It's from Lin Clark when she tries to introduce the performance history of JavaScript. The performance started to boost from 2008 and is still not reaching the end.

The benefit is great for app end-users, however, writing HTML still sucks for coders.

When we use so-called Front-end Frameworks, such as React, Vue, Angular and etc, and is overwhelmed by the booming of tools in front-end ecosystem^[5], we still need to write HTML-like code and tweak styles carefully with CSS or one of its variants.

It's slow and boring.

Tens of thousands of outstanding minds are wasted on implementing those graphical interfaces, using a technology stack that was not originally intended for. Those tasks are not limited to tweaking styles back-and-forth, as well as handling browser compatibility issues, applying weird CSS hacks, looking out for performance caveats and so on.

And No-Code doesn't help either. Anyway, no No-Code products are solving problems for coders.

We may ask ourselves, why are we still sticking to HTML and CSS, and using sophisticated tools from over-grown NPM ecosystem to create apps, which is less efficient and more irritating?

Other Non-Web Frameworks

Because there is no other better ways.

Electron, though well-known with a proven application like VSCode, would be first ruled out from the list, since it is actually still a Web-based solution, thus we don't even need to talk about its performance issues.

What else do we have?

• Some are platform-specific frameworks since the beginning of golden ages, like MFC for Windows, Cocoa for macOS, and GTK for UNIX/Linux. And others are modern mobile toolkits like those specifically made for iOS, Android, or other mobile operating systems.

• The cross-platform frameworks, notably the widely-adopted Qt Framework. But it is mainly used for desktop software development. The cross-platform here initially means crossing different desktop operating systems, however, some endeavour is still being put into mobile/web targets for those frameworks.

• Upcoming brand-new solutions like Flutter, which is a mobile-first cross-platform framework, and may be promising for web and desktop as well.

As the ratio of web apps is increasing over the years, the platform-specific or cross-platform frameworks mentioned above are less used since they are often targeting traditional desktop applications.

And the developer experience is even worse than writing HTML because they may be obliged to write imperative and object-oriented code like this^[6][7],

var count = 0
let stack = new VStack
let text = new Text("Count: \(count)")
stack.add_child(text)
let button = new Button("Increment")
button.set_onclick(||
    count += 1
    text.set_text("Count: \(count)")
)
stack.add_child(button)

rather than writing declarative and possibly reactive code that programmer always dreams of, like this.^[6:1]

struct AppState {
    count: i32
}

VStack {
    Text("count: \(state.count)")
    Button("Increment") {
        state.count += 1
    }
}

That's why Flutter seems like a silver-bullet for developing apps:

• It is declarative and reactive in nature.
• It is truly cross-platform for making all of desktop, mobile, and web apps.

Though some people don't like Flutter because it introduces another new and unfamiliar language as well as extra VM burden, which is likely the result of technical bureaucracy.

The real problem of Flutter lies in the compatibility with existing ecosystems, as people tend to prefer reusing established resources and maintaining mature applications. And programming language matters for the same reason.

And it also explains why the JavaScript version of Flutter was tried by some gifted and insightful people. But it failed as Flutter itself is rapidly changing its internals so that it won't catch up. Thankfully, as all work pays off, it gave birth to the Kraken framework, which allows coders to write HTML, and uses Flutter Engine for cross-platform rendering.

Wait... What? Writing HTML again in non-web frameworks^[8]?

Design-to-Code

No, no more writing HTML!

Still, we have to admit that HTML+CSS is a good combination to represent UI, as

• HTML is responsible for the structure of the content,
• and CSS is individually responsible for the style of the content.

So that structure and style are de-coupled, which is good for engineering. The premise is that the engineering is necessary, however.

In practice, the engineering of UI is sometimes meaningless and unnecessary. Suppose we already have a high-fidelity design prototype given by designers, and what coders need to do next is

1. Re-implement the design prototype using code, which is HTML+CSS stuff in 99% cases.
2. Add business logic to the UI he or she just re-implemented.

The first part is always the source of pain. It has plenty of details. It is time-consuming. It needs discussions with designers, back-and-forth. The communication cost is expensive. If the design updates, the code needs update too, and maybe another costly discussion is needed.

And not to mention that, this kind of job is usually seen as low-ended, and thus the so-called front-end programmer is usually looked down upon by other non-front-end programmers.^[9]

Some clever people came out of the solution of Design-to-Code using compiler techniques, or more specifically, the transpiler techniques, which turns the whole high-fidelity design into machine-generated HTML+CSS code.

It sounds adorable, but it is catering for PMs and designers, rather than developers. The nasty intrinsics include but is not limited to

• The generated code is ugly, or conforms to existing coding style in the project.
• The integration of generated code is troublesome. What if it depends another 3rd-party library? What if the generated code got updated and whole chunk of changes is thrown to the version control system?
• The design tool like Sketch or Figma, is always more visually-capable than HTML+CSS for advanced visual effects, thus sometimes the generated code could not produce exactly the same UI of design prototype, and some patches are definitely needed. What if the generated code got updated and the patches won't apply any more?

All in all, the Design-to-Code is not a good technical solution from coder's perspective. Now let's look what Design-as-Code is.

Design-as-Code

In VGG's Design-as-Code workflow, no more HTML needs to be written, or generated. Even HTML itself does not exist.

Because the design just replaces the role of HTML+CSS, so that design is just code. As the first principle of VGG Workflow is to bridge the huge gap between the two worlds of design and development by eliminating redundant development efforts.

The obvious advantage is that the designing and developing of graphical UI needs to be done only once, because two things is actually one thing. And consequently less discussions are needed, which make both sides happier.

As for developer, he or she is able to write business logic directly on the design files, which is then runnable by VGG runtime as an interactive graphical application. This could save a lot of duplicated work so as to increase the work efficiency not only for developer but also for the whole team.

The concept of Design-as-Code is simple, however, it faces many challenges, especially engineering challenges from compiler implementations, programming interface abstractions and graphics renderings.

VGG is short for VeryGoodGraphics, which defines the next-generation vector graphics specification (VGG Specs) with its official implementation (VGG Runtime). VGG's Design-as-Code workflow is made only possible thanks to these two cornerstones.

Conclusion

In this post, we have discussed about the Web technologies, platform-specific frameworks, cross-platform frameworks, the Design-to-Code solution as well as the so-called VGG Design-as-Code workflow.

We proposed the Design-as-Code concept for escaping from the HTML world, and introduced VGG as a brand-new framework for developing interactive graphical applications. But VGG is still young, as many technical challenges needs to be overcome first.

This post is just an introduction, and more details about VGG will be discussed in later posts. If you have interests, you can continue to read our official blog and docs.