Welcome to VGG 1.0!👋

Today we are thrilled to announce the release of VGG 1.0 and officially make it available to everyone. 🚀

VGG 1.0 represents the largest milestone in VGG’s development to date: the next-gen vector graphics and embeddable cross-platform UI framework that advocates the Design-as-Code paradigm.🎉

The release of VGG 1.0 comes with a multitude of new features, improvements, and fixes.

What's new in VGG 1.0

Our new VGG official website showcases the latest dynamic capabilities：

• Responsive Layout

• Interaction

• Animation

At the same time, we have added a suite of new tools to help you get started quickly:

• Daruma Plugin for Figma: Supports rapid synchronization of static, interactive, and animation resources from Figma design files, publishing them as fully functional live websites.
• VGG CLI tool: A command-line tool that converts various design files into the VGG format.
• VGG Containers for Qt: A specialized VGG container library designed for seamless integration with the Qt framework.

Improved

• Enhanced Attribute Clarity: We've polished the attribute descriptions in VGG Specs for improved clarity and precision, ensuring a better understanding for users.
• Daruma Preview Upgrade: The design and user experience of the Daruma preview window have been significantly enhanced, providing a smoother interaction.
• Reduced Licensing Fees: Under certain conditions, we've reduced royalty fees for the VGG license, making it more accessible.

Fixed

• Bug Fixes and Rendering Improvements: We've resolved bugs and text layout rendering errors in the runtime environment, leading to a more stable experience.
• Front-End Styling Refinements: Multiple front-end styling issues have been addressed, ensuring a consistent and visually appealing interface.

Known issues

We’ve done our best to make VGG 1.0 as solid as possible, but unfortunately there are a couple of issues that we know about in the release.

• Accessibility.
• Runtime is laggy on iOS devices.
• Layout issues have arisen due to the absence of certain fonts in the font library.

These issues and bugs will be fixed and improved in future versions of VGG.

Supports

If you encounter any issues or have any questions during use, please contact us through the following methods:

VGG Community: https://discord.gg/89fFapjfgM

Acknowledgments

Special thanks go to all users who participated in the beta testing, as well as to every member of our development team. It is with your support and hard work that we have been able to successfully release the official 1.0 version!

In the previous post, we discussed about an interesting topic in SVG design: How to add rounded corners to rectangles and the challenges of implementing separate rounded rectangles. We learned that while adding rounded corners is a breeze in design software, there are a number of challenges when implementing this design using SVG code.

Today, we're going to delve deeper, exploring the challenges in implementing rounded corners when working with non-rectangular graphic elements and current solutions, especially for complex shapes made up of paths.

Adding rounded corners to complex shapes made of paths in SVG

Rounding complex shapes made up of paths is a technical challenge in SVG. This involves converting the vertices that make up the <path> element into rounded corners, creating curved shapes with smooth transitions rather than simple straight lines or folded corners. To better visualize the process of adding rounded corners to open path shapes in SVG. A simple example is provided below.

SVG code for an open path graphic composed:

<svg width="239" height="159" viewBox="0 0 239 159" fill="none" xmlns="http://www.w3.org/2000/svg"<path d="M2 123.5L51.5 30.5L92.5 153.5L146.5 1C149.833 34.5 157.5 104.5 157.5 104.5C157.5 104.5 181.167 65.5 192.5 44.5L237 108.5" stroke="#FF6600" stroke-width="3"/></svg

SVG code for rounded open path graphics:

<svg width="239" height="100" viewBox="0 0 239 100" fill="none" xmlns="http://www.w3.org/2000/svg"<path d="M2 88.5L40.5533 16.0665C44.6817 8.31006 56.089 9.26692 58.8676 17.6028L83.2988 90.8965C86.3082 99.9245 99.0357 100.043 102.212 91.0722L131.556 8.20392C135.122 -1.86714 150.001 -0.091437 151.132 10.5323C152.236 20.8981 153.344 31.2046 154.32 40.2328C155.346 49.7319 167.756 52.4491 172.615 44.2224C176.53 37.5947 180.725 30.4197 184.57 23.6949C188.271 17.224 197.53 16.7343 201.786 22.8545L237 73.5" stroke="#FF6600" stroke-width="3"/></svg

As we can see from the SVG code above, adding rounded corners to <path> elements in SVG is not a straightforward process. This is because the standard<path> element does not provide a property or method to add rounded corners directly. Instead, we must use SVG path commands to simulate the rounded corner effect. Specifically, this can be accomplished in the following steps:

1. Use the M command (moveto) to move to a specific point in the path.
2. Use the Q command (quadratic Bézier curve) or other Bézier curve commands (e.g., C for cubic Bézier curve) to create rounded curves that convert straight segments into smooth arcs.

With these commands, developers can precisely control the contour of the path to achieve the desired rounded corner effect.

Limitations of other SVG attributes for simulating rounded corners

The SVG 2.0 specification introduces the stroke-linecap and stroke-linejoin attributes, which provide more customization options for the styling of lines and polygons. stroke-linecap's round option simulates the effect of rounded corners at the endpoints of a line, while stroke-linejoin's round option simulates the rounded appearance of line joins. These properties visually produce rounded edges, adding a smooth transition effect to shapes.

Introduces open path graphic code implemented with the SVG stroke-linejoin attribute:

<svg width="239" height="156" viewBox="0 0 239 156" fill="none" xmlns="http://www.w3.org/2000/svg"<path d="M2 124.5L51.5 31.5L92.5 154.5L146.5 2C149.833 35.5 156.7 103.1 157.5 105.5C158.3 107.9 181.167 66.5 192.5 45.5L237 109.5" stroke="#FF6600" stroke-width="3" stroke-linejoin="round"/></svg

However, it is important to understand that the stroke-linejoin property does not create a true rounded corner effect directly on the geometry of the drawing. Instead, it achieves the appearance of rounded corners by changing the way the path is rendered. Specifically, when stroke-linejoin is set to round, it visually rounds corners by generating a rounded transition at the junction of adjacent line segments in the path.

Note that the stroke-linejoin property does not accept a specific radius value to define the size of the rounded corners. It is not used to specify the radius of the rounded corners, but rather to simulate the appearance of rounded corners by changing the rendering algorithm. Therefore, stroke-linejoin="round" does not directly control the exact size of rounded corners, but rather provides a way to create rounded transitions at path inflection points.

For designs that require precise and complex rounded corners, developers often need to manually manipulate SVG's <path> element. Traditional SVG has limitations when simulating rounded corners, especially in terms of visualization and design flexibility, because these rounded corners are not based on real geometric shapes, resulting in a lack of precision when scaling or displaying at high resolution. In addition, for non-linear paths, such as curves and Bezier curves, SVG's simulation properties do not apply, limiting their use. Manually editing <path> elements can be challenging for users unfamiliar with SVG path syntax, and even experienced developers may find the code lengthy and difficult to maintain. Any small numerical adjustment can result in significant changes to the path data.

To understand this more intuitively, here's a set of examples of adjusting the value of rounded corners, showing how you can precisely control the size and shape of rounded corners by manually editing the <path> element.

SVG code for open path vertices with rounded corners of value 3:

<svg width="239" height="139" viewBox="0 0 239 139" fill="none" xmlns="http://www.w3.org/2000/svg"<path d="M2 113.5L48.216 26.67C49.4545 24.343 52.8767 24.6301 53.7103 27.1308L89.7397 135.219C90.6425 137.927 94.4607 137.963 95.4136 135.272L142.017 3.66118C143.087 0.639866 147.527 1.16361 147.856 4.35184C150.643 31.3738 154.71 68.8971 156.542 85.7234C156.852 88.5729 160.58 89.4029 162.056 86.9457C168.837 75.6558 181.695 54.0744 190.16 38.7783C191.243 36.8216 194.009 36.6703 195.286 38.5064L237 98.5" stroke="#FF6600" stroke-width="3"/></svg

SVG code for open path vertices with rounded corner value of 7:

<svg width="239" height="117" viewBox="0 0 239 117" fill="none" xmlns="http://www.w3.org/2000/svg"<path d="M2 99.5L43.8373 20.8966C46.7272 15.467 54.7123 16.1368 56.6573 21.9719L86.0592 110.178C88.1657 116.497 97.075 116.58 99.2985 110.301L136.039 6.54275C138.535 -0.506986 148.932 0.73309 149.716 8.17054C151.622 26.2459 153.728 45.7905 155.269 60.0008C155.989 66.65 164.69 68.5672 168.11 62.82C173.9 53.0922 181.072 40.9087 186.984 30.4505C189.553 25.9082 196.021 25.564 199 29.8482L237 84.5" stroke="#FF6600" stroke-width="3"/></svg

SVG code for rounded corners of open path vertices with a value of 10:

<svg width="239" height="100" viewBox="0 0 239 100" fill="none" xmlns="http://www.w3.org/2000/svg"<path d="M2 88.5L40.5533 16.0665C44.6817 8.31006 56.089 9.26692 58.8676 17.6028L83.2988 90.8965C86.3082 99.9245 99.0357 100.043 102.212 91.0722L131.556 8.20392C135.122 -1.86714 150.001 -0.091437 151.132 10.5323C152.236 20.8981 153.344 31.2046 154.32 40.2328C155.346 49.7319 167.756 52.4491 172.615 44.2224C176.53 37.5947 180.725 30.4197 184.57 23.6949C188.271 17.224 197.53 16.7343 201.786 22.8545L237 73.5" stroke="#FF6600" stroke-width="3"/></svg

VGG: Simplifying Rounded Corners for Complex Graphics

VGG Specs takes a different approach to path description than SVG by defining all curve points declaratively, simplifying the path representation and reducing the difficulty for users to understand and implement. VGG Specs' approach is more intuitive and concise than the command-based path description of traditional SVG.

VGG Specs provides an efficient solution for creating and adjusting rounded corners, with flexible methods for setting them for different types of graphic elements.

For rectangular shapes, VGG Specs introduces a radius field that allows the developer to specify the radius of the rounded corners for each vertex individually via an array. This design simplifies the setting of rounded corners and increases flexibility because different sizes of rounded corners can be applied to each vertex.

For complex shapes defined by the <path> element, VGG Specs further refines the control by providing a radius field for each curve control point that accepts a floating point value to precisely define the radius of each fillet. This design allows developers to fine-tune each corner of a path shape to achieve highly accurate visual effects.

In addition, VGG Specs also works with polygonal shapes such as triangles or pentagons. Not only does it provide a radius field to set a uniform radius for rounded corners, but it also allows curve points to be used to set different radii for each vertex in the graph, thus meeting a wide variety of design needs.

With these improvements, VGG Specs significantly improves the efficiency and quality of graphic design while lowering the technical barrier, allowing developers to focus more on the realization of ideas and designs.

For example, to add rounded corners to the vertices of a <path> element, simply specify a pixel value to the radius attribute, such as radius="10". Not only does this approach greatly simplify the creation of rounded corners, but it also makes resizing them intuitive and easy - just change the value of the radius attribute.

To learn about the specific properties and usage of VGG Specs, visit VGG Docs for detailed information.

Additionally, VGG has open-sourced the underlying engine, VGG Runtime, with cross-platform rendering and execution capabilities. We will continue discussions through a series of pitfalls with SVG as a vector graphics format, and showcase the graphical capabilities of VGG as well as its advantages over SVG. Please stay tuned, and we welcome everyone to participate in building the VGG open-source community together.

https://discord.com/invite/89fFapjfgM

Background

What is SVG: Simply put, SVG is a kind of vector graphics format. Unlike those vector-based design files that are large in file size, SVG is in pure text form and is light enough to be used along with code.

However, in practice, the exported SVG cannot accurately reproduce the rendering effects that the designer draws in the design tool. In this article, we will discuss the missing feature of rounded corners in SVG.

Rectangles of all kinds

In SVG, the rounded corners of a rectangle can be defined using the rx (horizontal radius) and ry (vertical radius) attributes of the <rect> element. When all corner radius are the same, it is called a unified rounded rectangle. The right figure in the following image is a unified rounded rectangle.

Below is an SVG example code for creating a unified rounded rectangle:

<svg width="300" height="300" viewBox="0 0 300 300" fill="none" xmlns="http://www.w3.org/2000/svg"<rect width="300" height="300" rx="60" fill="#0286FF" fill-opacity="0.75"/></svg

But there is a special case where it is difficult to realize using the SVG rx and ry properties. Let's take a look at the example below:

Notice anything different? Each corner of the rectangle on the right has been assigned a different radius. When it's necessary to set different radius for each corner to create an individual corner rounded rectangle, SVG's rx and ry properties fall short. This design can be realized uniquely with rectangles among all shapes.

In the following example, in order to implement a design effect similar to Figma's in SVG, we typically need to use the <path> element to create a rectangle with independent rounded corners.

You may notice that the rx and ry attributes used to define corner radius in the <rect> element are not present. Instead, a series of complex path commands are used. This is because the <rect> element in SVG does not support setting different radius values for each corner of the rectangle; instead, SVG path commands must be used to draw this effect.

<svg width="300" height="300" viewBox="0 0 300 300" fill="none" xmlns="http://www.w3.org/2000/svg"<path d="M0 96C0 42.9807 42.9807 0 96 0H254C279.405 0 300 20.5949 300 46V222C300 265.078 265.078 300 222 300H122C54.6213 300 0 245.379 0 178V96Z" fill="#0286FF" fill-opacity="0.75"/></svg

As we can see, while creating rectangles with independent rounded corners is straightforward in design software, implementing the same effect in SVG requires writing longer and less intuitive code. This difference may lead to significantly increased development time and efforts when dealing with more complex graphics and paths.

The complexity and challenges of handling rounded corners in SVG

In design and development collaboration, a common issue is the designers' lack of understanding of the SVG specification. They often expect the vector graphics drawn in design software to be directly implemented through code. However, developers may encounter challenges when reproducing designs in code, especially for special graphics such as individual corner rounded rectangles. This challenge becomes even more daunting when the original SVG files are unavailable.

In the handoff from design to development, although theoretically the SVG images exported by designers should be directly usable by developers, the reality is often not that simple. Especially when fine-tuning the values of individual corner radius, even if developers know the specific values required, they typically still rely on designers to re-edit the original design files and to export new SVG images. This workflow not only adds significant time costs but may also involve additional communication costs, as it requires conveying and confirming requirements between designers and developers.

Furthermore, attempting to bypass design and directly modify the <path> elements in SVG images through code is also challenging. For example, suppose we need to reduce the radius of the rounded corner at the bottom-right of a rectangle from 78 pixels to 28 pixels.

<svg width="300" height="300" viewBox="0 0 300 300" fill="none" xmlns="http://www.w3.org/2000/svg"<path d="M0 96C0 42.9807 42.9807 0 96 0H254C279.405 0 300 20.5949 300 46V222C300 265.078 265.078 300 222 300H122C54.6213 300 0 245.379 0 178V96Z" fill="#0286FF" fill-opacity="0.75"/></svg

SVG code example with a rounded corner radius of 78 pixels (left in the image)

<svg width="300" height="300" viewBox="0 0 300 300" fill="none" xmlns="http://www.w3.org/2000/svg"<path d="M0 96C0 42.9807 42.9807 0 96 0H254C279.405 0 300 20.5949 300 46V272C300 287.464 287.464 300 272 300H122C54.6213 300 0 245.379 0 178V96Z" fill="#0286FF" fill-opacity="0.75"/></svg

SVG code example with a rounded corner radius of 28 pixels (right in the image)

As shown in the example, fine-tuning the values of individual corner radius in SVG is an extremely challenging task. Developers need to have a deep understanding of SVG path data to correctly parse and adjust complex path commands, which is technically very difficult and almost impractical.

So, is there any other method that developers can use to create rectangles with independent rounded corners?

Other Solutions

You may consider using HTML and CSS to simplify such issues, but this requires developers to not only be familiar with SVG's limitations but also to master other web standards and find suitable solutions from them. While this approach is feasible, it significantly increases difficulty and does not thoroughly solve the problem.

What we want is SVG to effortlessly and efficiently implement any design created in design tools. If there are other convenient methods to implement individual corner rounded rectangles in SVG, feel free to share your experience.

A Better Solution

VGG Specs provides a simplified approach to create rounded rectangles. Through the radius property, developers can define the radius of each corner in a concise manner. Learn more about the specific properties at Radius | VGG Docs.

For example, to set different corner radius for a rectangle, simply specify the pixel values: 96 pixels for the top-left corner, 46 pixels for the top-right corner, 78 pixels for the bottom-right corner, and 122 pixels for the bottom-left corner.

The VGG specification enables the quick and easy implementation of rounded rectangles with independent corner radius through simple attribute declarations.

So, what is VGG？

What’s VGG

Just as SVG stands for Scalable Vector Graphics, VGG stands for Very Good Graphics.

VGG is the next-generation vector graphics standard based on JSON.

It includes multiple specifications such as design, layout, animation, and interaction, aiming to significantly improve usability and ease of use. VGG aims to drive the future of vector graphics and serves as an open standard for industry use.

Additionally, VGG has open-sourced the underlying engine, VGG Runtime, with cross-platform rendering and execution capabilities. We will continue discussions through a series of pitfalls with SVG as a vector graphics format, and showcase the graphical capabilities of VGG as well as its advantages over SVG. Please stay tuned, and we welcome everyone to participate in building the VGG open-source community together.

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.