We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf London, dedicated to all things web performance.
Ilya is a full stack developer that loves meeting new people and motivating them to build awesome things together. Formerly working as a back-end engineer, he is now very passionate with front-end technologies and JS frameworks. He currently works as a Senior Software Engineer at Redbooth.
React is one of today’s most popular ways to create a component-based UI. It helps to organize an application into small, human-digestible chunks. With its “re-render the whole world” approach, you can avoid any complex internal interactions between small components, while your application continues to be blazingly fast due to the DOM-diffing that React does under the hood (i.e. updating only the parts of the DOM that need to be updated).
But can we apply the same techniques to web graphics — SVG in particular? Yes! I don’t know about you, but for me SVG code becomes messy pretty fast. Trying to grasp what’s wrong with a graph or visualization just by looking at SVG generator templates (or the SVG source itself) is often overwhelming, and attempts to maintain internal structure or separation of concerns are often complex and tedious.
I hope that by now, in 2014, there is no need to explain why SVG is a blessing to developers who want to ensure that their graphics look sharp on all devices, especially with their huge diversity of resolutions.
But just like any other technology, SVG has its limitations. And in this article, we’ll talk about how to bypass some of them. Well, what’s the problem? Why would you even need to generate SVG on the server? The technology is entirely client-side, so what would motivate anyone to move it from there?