Show HN: A tool to build real websites built exclusively in SVG
svija.love
svija.love
It's essentially a website builder that uses Adobe Illustrator for creating pages.
The results so far have been really promising: - building websites is extremely rapid - very little debugging or verification is needed - it's easy to create beautiful content
Techniques that were trivially easy for me 30 years ago in print are still impossible in HTML. With SVG, I can just design the page without worrying about interlocking invisible boxes.
You can try it yourself — it's free, but you'll need to create an account for the hosting part.
The only tool I could find to create the SVG's was Adobe Illustrator, because it enables linked images and fonts, like regular HTML pages.
As far as I know, no other SVG editor except for Inkscape does this.
For now it's Mac only.
What do the end results look like when used on devices with different screen sizes and resolutions?
Does a site laid out for a phone like gigantic on a desktop?
How does it react to different aspect ratios?
I revisited SVGs when redesigning a planetarium website (https://friendsoftheplanetarium.org/). I suppose I could have done all of it in CSS, but the code using SVG was simple and concise.
On the way I discovered a nasty bug in recent releases of the Blink engine (https://bugs.chromium.org/p/chromium/issues/detail?id=127442...). It should be fixed in the next release, but it makes me wonder if you are less likely to get correct rendering when using SVGs.
This means that fonts can't be reused throughout the site, that text can't be read (either by screen readers or Google), and it can't be selected or copied.
It also means that images are much larger than necessary and can't be reused (making the site more resource intensive).
All of this adds up to "not being a real web page".
The only exceptions I know of are Illustrator and Inkscape.
So far, the rendering with Illustrator has been pretty much perfect. There were a few idiosyncrasies that I addressed in the server program.
I haven't experimented much with Inkscape because I'm on Mac and it doesn't seem to be used much in commercial contexts.
Aren't those the two most common vector graphics programs?
I would love to be wrong about this.
Figma and Adobe Xd are pretty popular, as is Affinity Designer. Microsoft Visio is popular in certain contexts, and InVision Studio is also popular.
// Similar to the typical problem with HTML generators, they’d write nasty code, so most were write only rather than write/read. To be fair, I haven’t checked Illustrator output in half a decade, so it could be fine now.
/// Definitely trying your tool, thank you for sharing!
("People who hate abbreviationS")
There is a setting for each page for Google and Accessibility where one can include HTML text for those reasons.
It's a priority for me to write a script to create an accessible/searchable version automatically.
Long-term, the goal is to create a design program that creates hybrid SVG/HTML pages that are indexable and screen-readable by default.
Need funding.
good luck with the funding!
I'm planning to write a script to automatically convert the Illustrator text to HTML, based on font size and position on the page.
Also, any modifications take effect after 24 hours, or you can just unpublish a page temporarily — there are several options that permit working without going live.
If you aren't handrolling or compiling the SVG yourself you also need to look out for whatever your tool is doing. Illustrator and Sketch in particular do some wonky nonsense with filters to support things like inner/drop shadows, and you may want to A/B the SVG in different browsers to make sure they look the same. It's been a few years since I had to do this, but in my experience you really had to restrict what features of the SVG editor your designers used.
However, in the past 10 years or so, a bunch of Photoshop functionality has been added in to Illustrator, and none of it is compatible with SVG.
So, there are various and warnings and workarounds for drop shadows etc.
But, Illustrator has good support for SVG effects, so drop shadows in particular are pretty simple to use.
The long term goal is to create really clean SVG/HTML hybrid code with a new program, but I still have to write it!
---
There's also an issue where SVG's are slower to animate because they don't use hardware acceleration, but my understanding is that this is coming soon.
You have to be careful about what you mean by "SVG effects" since the spec is quite large and has many ways of doing things, and different software may not agree with how they work. I don't think any renderer passes the entire standard test suite.
How else would you implement that with SVG? And in my experience filters have been very well supported for the past years. They are part of the SVG conformance tests anyway, so any mismatch is also a broken SVG implementation.
I have had a lot of difficulty finding out how widely Inkscape is actually used. I look in the user forums etc., but apart from hobbyists, I don't hear about people using it for business.
If you have any info, links etc., I'd greatly appreciate it.
So yes it can absolutely be used for business!
If it's proven to be performant enough, I think it would work for 90% of sites out there (pages of information + pictures)
Theoretically you could even have a graphic designer build a site without much code knowledge instead of hiring a webdev.
They also have their own integrated web site builder as well.
But, the last time I checked, it can only create SVG content with images converted into inline code, and text reduced to glyphs.
This means that fonts can't be reused throughout the site, that text can't be read (either by screen readers or Google), and it can't be selected or copied.
All of this adds up to "not being a real web page".
If I'm wrong about any of this, of if Affinity Designer has been updated to enable linked fonts and images, that would make my day.
I love Illustrator but it's certainly a bit of an albatross around my neck ;-)
Out of curiosity, what techniques are impossible in HTML? I ask this because I too am working on a website builder, and wonder what might be too complicated or impossible for people to implement.
For example, https://svija.love/en/imagine would be almost impossible in HTML.
The main thing that makes HTML difficult is that everything is interlocking — you can't just drag the H1 headline down 20px and over 100px, because there's already something there, or there's nothing to hold the H1 in place.
I would love to know more about your project if you'd like to share. After today, I recommend posting to HN.
FWIW CSS is quite powerful these days - rotations, translations, overlapping etc are all trivial. You can absolutely position elements down to the pixel if you want.
People tend not to do these things any more though as they make for an annoying and potentially illegal website (accessibility laws), plus maintaing it is a pain in the arse as you lose all the reflow benefits of HTML that is screen size and shape agnostic
1. Fitting text to curves.
2. Wrapping text to curves.
That was pretty much the first thing I thought of when I started the project.
A couple of problems on my end (Firefox on Android, low-end device): selecting text is very wonky, noticeable stutter when scrolling, first load of the page had really small text (on a refresh it showed me a proper mobile version).
If I may ask, what's the biggest motivation? The easy of use of authoring through Illustrator or having a more distinct graphic design? (the curves, funny text wrapping, et cetera)
Edit: also an issue in Firefox on Windows 10: page width is larger than the visible screen.
When Flash plugins were on the way out everyone always repeated how this would open the door for equally powerful HTML5 tooling. But while HTML5 has gained all the technical capabilities of Flash, nobody has managed to make an authoring tool as good as Adobe Flash. With the loss of Flash we mostly lost the creative websites by people who can't code but are great at visual design. This comes close to enabling that again.
In fact, I wrote Svija because I took a sabbatical from web design. When I came back, Flash was gone and I just couldn't stomach the idea of twenty years of HTML and CSS. So, SVG.
Is it because we're shoving the SVG into the dom or something? Or using expensive SVG features?
I could list a bunch of links, but of course none of them work anymore.
Perhaps I could require some sort of SVG Licence to use Svija, or an oath to usability ;-)
On the plus side, it's a testament to how nearly anyone could build a website. I'm sure many many people got their feet wet in web dev making simple sites for local businesses because the bar was so low.
Making an html version of most of the stuff i'm talking about would have been much easier than the flash version. when the only interactivity is changing pages.
The web is not paper, don't design for it as if it as.
Oh, and this little page weighs 4.5MB
> The web is not paper, don't design for it as if it as.
People have said that for literally everything we have on the web now, starting with "the web is only for text and hyperlinks"
Hard disagree.
> People have said that for literally everything we have on the web now
What I meant is that here the intent is to design something once and display it in the browser as if it was an image (or printed media), i.e. without filling the window properly.
This is 100% like displaying a PDF in a browser and it does not belong in one.
Well, then I'm thankful people can still develop and test out radical ideas despite others not wanting that.
This is how all good tech develops, like PDFs. It just tends to be through the internet now.
If it was a proof of concept, fine, but it's not, the author intends to develop this further and is accepting signups. I do not want this web. Just publish PDFs if you want to design fixed media.
You may not know about them. Read them here:
Like this website? https://lab6.com/
(Hacker News discussion: https://news.ycombinator.com/item?id=27880905)
> Svija is intended for websites where the content creator wishes to have complete control over the final page. Therefore, a separate, fixed version of each page is created for each version of the website. In most cases this means a desktop version and a mobile version.
> Although it may seem like a sacrifice to create separate versions for different platforms, [...]
This is mostly* all well and good, but should really be a front-and-centre caveat on the homepage for people considering this approach (I took this quote from https://svija.love/en/wtf ).
---
*However:
> [...] the reality is that most companies who care about providing a strong mobile experience already construct separate mobile websites
This is absolutely not even in the slightest bit true. It's true that most large companies (e.g. FAANG, etc.) do this, but saying "most companies" here is outrageous.
But, it's true that I don't have much recent experience outside of Wordpress, and I have not had the benefit of working in large teams to learn best practices.
I wonder if there's some way to make this approach responsive, even if just using breakpoints (vs serving a completely different site requiring a pageload). Doesn't seem like it, but I haven't thought about it much.
Right now this project is a proof of concept: see, by doing real design we can make nice sites, very quickly.
I'm trying to get funding to create a new set of tools based around this kind of workflow.
Re-introducing breakpoints and some level of content reflowing is certainly going to be a part of it (I believe I mentioned it in the WTF page somewhere).
I have built many many HTML sites, but not many in a team context, so it's true that I lack relevant experience.
In my own experience, what ends up happening is that there are lots of situations where there's double content — on desktop show this block, on mobile show this other block.
But that's not the same as a whole duplicate website.
• Page is rather heavy to load.
• Page load felt a bit sluggish on even a fast device; but on review I think the massive background JPEG at the top (4000×8047!) was a large part of this: you should have an approximation of it (background colour plus radial gradient) underneath it so that its potentially slow loading and rendering isn’t so obvious.
• Resizing the window has a habit of breaking things, seeming to attempt reflowing most of the time but normally making a mess of it. (Not factoring scrollbars in may be contributing to this.)
• I’m getting horizontal scroll bars, sometimes for substantial amounts and sometimes because you’ve measured the wrong thing that doesn’t take scrollbar width into account: to experience that on macOS so you can fix it, you can disable overlay scrollbars somewhere in the system settings.
• I found myself disappointed that the document is served as HTML rather than SVG, though it probably makes sense because of things like meta tags that I don’t imagine most tooling will understand how to consume within SVG.
• Where text flow is concerned, it may be worth switching back to HTML with <foreignObject>. It would probably allow code size reductions and performance improvements in reflow, and would improve accessibility, hopefully to the point where you could stop maintaining a separate HTML alternative section, instead weaving it throughout the SVG.
But all up, I like the concept. It’s good to see experiments in doing things differently. I myself am preparing to start publishing content handwritten and -drawn via my reMarkable tablet, and will be toying with making it reflowable at some point, though I suspect I’ll only ever reflow very sparingly. (If anyone else is interested in the concepts, take a look at http://www.styluslabs.com/ and https://developer.myscript.com/docs/concepts/responsive-layo....)
I need to optimize the images more. There is a background color etc., but the main image is much too heavy.
Many people have noted the horizontal scrollbar issue — it's from a problem with Windows years ago and I will make a note to take care of it.
It's not really possible to serve the document as a pure SVG, because the browser automatically resizes the content to fit vertically. The user would just see the whole page, shrunkent to fit in the middle of the screen.
There will be text flow in the future, but our immediate plans are to concentrate on using the system of exact coordinates with both HTML and SVG — it has the potential to radically simplify the code necessary and to allow for much easier design.
Once we have that down, we'll add in reflow.
I loved styluslabs.com - instant bookmark. I'll have to spend more time with it, but I'm curioushow it will work with search engines.
Thanks again!
I just happened to launch a similar product today on product hunt (https://moos.app) that also allows people to build pages from SVG files but I take a more hybrid approach and focus more on animation (and the render actually uses WEBGL for performance reasons).
Will we still have the same boxy design in 5 years or will we have a completely new experience?
I really hope we get out of the boxy design in 5 years, and I hope it'll be thanks to Svija and Moos!
And, the website looks amazing in fullscreen mode on a big monitor, way better than other sites I've seen (within my design limits).
It's so fast to build pages that building separate versions is much faster than building a single responsive WP page (for example).
Most of the time, both versions (or more if needed) are in a single Illustator doc and it's quite simple to maintain both at once.
So, now I'm looking at this and thinking....what new amazing capability has this provided that we couldn't do before. I was expecting amazing 3D svg animations or something. But this is just a very average template style website. Why would I want this to be made as an SVG. The "illustrator to website" doesn't appeal to me personally, and I'm not sure I know why this would be valuable.
Maybe there are a lot of use case where this is good enough and perhaps better.
For example: If I'm starting a restaurant, I can have someone design a cool-looking menu, and then basically host that as an SVG-based site and be done with it. I'll probably want to get my own domain, but I don't need to pay someone who knows how to wrestle with HTML to make it look like the printed menu.
We were going to make a webassembly UI framework that worked across devices natively as well as the web.
George Santayana
It looks nice on my phone (although it's really slow to load, and laggy when scrolling). However, on my 1440p 32" monitor it's really bad. First of all everything is HUGE, and it seems like it just scales up/down with the size of my browser window. The content is not reorganized as I change the size of my browser window. If I scale my browser window up and down, everything just get larger or smaller, to the point where it's unreadable. Also, for some reason the page is just blank until I open DevTools, and if I "snap" the browser window in Windows 10, the page content doesn't scale to the right size.
Fun story-- awhile back some troglodytes living somewhere in the Linux font stack tripped some switch in their magical rendering engine. Whatever the change was, it caused even a mono-spaced font like DejaVu Sans Mono to have a significantly fatter width. So pre-trog Ubuntu perhaps would have X width for "Hello World This Should Fit Perfectly An SVG Rect" at size 10px, while post-trog Ubuntu would have X+7.
For my SVG-based UI, this meant I had to do a startup feature test for pre or post-trog Linux and scale the font accordingly on post-trog machines to make sure it fit properly into the box.
But honestly, I don't think you could do any kind of feature test like that with impunity. E.g., if the user created a page with no visible border lines drawn at the right edge of the text, they'd probably be surprised/irritated that the text is slightly scaled in a feeble attempt at cross-platform compatibility.
Anyway, all these problems go away when the fonts are converted to paths-- the user simply sees static output based on the rendering engine on the dev's machine.
Edit-- but of course if you convert to paths, you don't get text and text selection. Nevertheless, converting vector graphics output to SVG-with-text-content is not actually WYSIWYG, and that subtle truth will probably come back to bite your users.
There is one big fat glaring exception: Safari for Mac doesn't resize fonts exactly, but instead uses a series of steps.
This means that when the page is resized, the text changes size slightly. I had to do a little back-end magic to compensate for this.
You can see for yourself by opening this in Safari and resizing the window:
‹html›‹body style="font-size:5vw"›‹div width=100%›
Slowly drag the side of the window‹br› and watch when the font changes size‹br› ‹br› In Safari it jumps, in any other browser it's smooth
‹/div›‹/body›‹/html›
You'll have to swap out the tags — I replaced the real brackets with French single quotes to make it appear correctly (possibly not necessary).
It then works with a protocol, with implementation examples in different languages, to create/remove/hot update SVG files on any subscribed servers. The authentication can further allow viewing of content on those servers as well.
Any small Linode server could be your own private Google Drive for web-enabled Word and PowerPoint documents.
TOTAL ISSUES 220 AUTOMATIC ISSUES 220 NEEDS REVIEW 160 GUIDED ISSUES 0 Critical 1 Serious 55 Moderate 2 Minor 2
But, the fact that I don't a perfect solution right off the bat is not a reason to stop exploring!
Also: ALL CAPS.
Yes, the report is output in all caps. Nothing wrong with your eyes!
One thing I noticed was that your page always has a horizontal scrollbar on chrome (maybe others?!)
Good luck with it, I hope that your thing is a huge success so I can judge people even more effectively :)
I understand it's a technology demonstration, I'm struggling to decouple the clash with my aesthetic sense from the technology/framework. There are so many new UI elements (stuff floating, expanding, appearing on hover) that it really puts me off. E.g. on the navigation group that floats on the right, I guess theoretically it's cool that if you hover over "imagine" it offers a small "expand" button and then there's a neat animation as it drops down. All that feels out of place on a website though, as far as I'm used to them.
Can you expand on who you've found resonates with the tool? Is it mostly people who want a print poster on the internet, or similar image-first, single-page users?
I can turn a PDF flyer into a website in a couple of hours, and that's been really popular.
It's so fast to put up a site that it would be good for events, like album release parties, etc.
I'm hoping to find a company that would really like to explore the potential — with a good team we could do some amazing stuff.
The long term goal is to make a tool to replace Illustrator and just build regular websites using hybrid SVG/HTML pages (SVG as much as possible, HTML for text/search/accessibility reasons).
> The long term goal is to make a tool to replace Illustrator
As in your ambition is to have the original content creation happen in the tool you make, take Illustrator out of the process entirely? That's ambitious! (or it seems like it, with little actual knowledge of what functionality people use within Illustrator to produce content like this).
I'm assuming it's closed source to respect your business, but do you keep any kind of blog or progress updates online?
Any chances of open sourcing in the future? :)
Joking aside, if enough work is put into it, SVG might be a solution one day to build a website. But right now it causes more problems than it solves.
Hopefully it can be enhanced to produce gracefully-degrading accessible output.
Or in the other direction, we could add a Wasm PostScript interpreter, and explode fonts by default so we get a sea of inscrutable ‘path’ elements. A WebGPU shader could tessellate it further. :^)
It also reminds me of flash, which had a similar selling point. Back in the day (early 2000's?) there was a trend building entire websites in flash only (requiring a browser plugin to be accessable). But svg is supported by any modern browser.
The story of flash (the adobe / apple clash) is one of those classic tech industry stories where commercial interests randomly divert the flow, stall development for decades etc.
Like others said, the site scales, but isn't responsive and thus becomes unusable once you resize a browser window to a smaller size.
% curl -I https://svija.love/en/wtf
HTTP/1.1 500 Internal Server Error
Server: nginx/1.18.0 (Ubuntu)
Date: Fri, 03 Dec 2021 23:35:52 GMT
Content-Type: text/html
Content-Length: 145
Connection: keep-alive
X-Frame-Options: SAMEORIGIN
Vary: Cookie, Accept-Language
X-Content-Type-Options: nosniff
Referrer-Policy: same-origin
Content-Language: enIf you add a dark background inline style to the html root element, you get rid of the white background lurking from behind when pulling down. The white is blinding.
1 feature I love to see, if possible, is to implement either youtube videos or Gifs.
(Would be cool if there was a really basic keyframe animation tool bar, but thats a lot of work) So don't listen to me.
But overall i love this. Thank you for making this!
Text selection seems very wonky, sadly.
Lol wut? Does the author advocate keep their money under their couch?
Of course some bugs to work out, but for a new idea, damn.
Like Svija - not a real website.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ma...
very 1999 :)
EDIT: It works if I disable the shield/ad-blocker.
D3 can do it but it's really geared toward data visualization rather than general UIs.
One of the nice things about this project is that it's shown me to what extent the internet has become based on existing content.
HTML is such a pain in the ass for design that almost all projects are just recycled — variations on themes, existing controls etc.
SVG is much more open, and of course that might be abused, like Flash.
To be clear, I do understand that usability is key and that websites should function in a transparent and understandable manner.
Personally my principle is that the visitor should be empowered at all times.
But, the development process is so abbreviated that it takes way less time to make a mobile & desktop version than it would take to make the equivalent responsive version.
Also many (most?) serious sites already develop separately for different platforms.
So far, in 5 years I've been working on this, I've not had a single comment from a non-developer about the responsiveness being inappropriate.
Just because they don't complain about something specifically, it doesn't mean that they don't feel discomfort.
Those being said, it could be a viable solution for fixed screen kiosks.
I looked at the website on my big 1440p monitor. It looked cool.
I resized the window to a still reasonable size (1280-ish width). Now some of the text is waay too small for me to read. 1366x768 is a still pretty common laptop resolution..!
I can't zoom in the text like on a regular page, it just makes the whole thing bigger, like an image.
I also can't use my favourite a11y tool waspline reader [1] because the HTML is hidden :-( but... I'm not a blind person who uses a screen reader. I'm an ADHD'er with visual snow. I can't change the fonts to ones which are a little more readable for me - and the font rendering in SVG images on Firefox on my linux computer isn't the best.
[1] https://addons.mozilla.org/en-GB/firefox/addon/waspline-read... ^ tbh, considering a lot of stuff I read is in PDF form I am thinking about doing an equivalent of this that does OCR on the viewport and applies a shader so it works on anything, and it only really applies to long blocks of text, which aren't a feature of the kinds of things you're targeting (flyers, product landing pages etc) but I wanted to highlight some of the less obvious accessibility stuff that's around.
I get it, pretty much everything posted to HN gets the "I don't like the design of this site for technical reasons" treatment (especially when it's an article on someone's blog and nobody was asking lol), but I do wanna highlight the not-so-obvious accessibility stuff.
Lots of folk will get by without complaining, because they're kinda used to tech and design being a bit difficult, and they aren't aware how we can improve things for them! I've seen my mum pull out a magnifying glass to read stuff on tablets before - she finds it easier than trying to get pinch-to-zoom to work - "I hate the panning from left to right all the time. It's not like reading a book. I'll forget what the start of the bloody sentence was!". Some people will attribute it to just "not being good with technology", which makes me sad for the users.
SVG is great but that "20 years of HTML and CSS" shouldn't be dismissed because it makes designs take longer.
I think it's really exciting that we have such a powerful layout engine in web browsers these days; the best BEST site designs I've seen take the best of vector art and responsive design. It is SO satisfying having a good vector landing page where the text still reflows, different things are visible when you resize the window etc.
I think your tool is great though, I just think you should run with all the "what about responsive design?" HN comments - you could have a really, really really good tool if you can support breakpoints, fluid layouts and reflowable text sections. The kind that people would pay $$$ for...
Plus, it's gotten a lot better since flex layouts became a thing in CSS!
I think Illustrator etc are missing a trick here too because they're designed more for print media, right?? What would be awesome is if there was a similar editor + format where responsiveness and fluidity were baked right into the authoring flow, like at the layer / object-group level, so you could say "those layers have to be pixel perfect, this one will show up at these sizes, this other one will stretch this amount, that one will scale relatively compared to that one" and hopefully end up with designs that you, the designer, are always satisfied with, which require little or no further work to adapt to other screen sizes, DPIs, devices, etc....
In this case, we had to start somewhere, and we're excited to show it off. But it obviously needs work to be really accessible.
Svija might never be appropriate for content-oriented websites, which may be most of them. It was quite difficult to create the WTF page in Illustrator — it's not made for that kind of thing.
I am absolutely planning to build a tool, where, as you say "editor + format where responsiveness and fluidity were baked right into the authoring flow, like at the layer / object-group level".
As soon as we can get some funding it's off to the races!
Thanks again, you added an important point of view to the comments.
I've been having a lot of difficulty with messaging — the basic benefits are that it's super fast, and you can do stuff graphically that's just impossible otherwise — but I haven't found a good way to communicate that.
I won't put it in the next version of the site.
- no links
- doesn't resize to the window
- no headers, footers, menus etc.
- different pages don't reuse common fonts or images, making it slower to load
- proprietary format
Anything I'm not thinking of?
What do you do with keyboard tabbing? Do you mean form fields? For that it works fine, unless I just made an HTML mistake.