Hacker News new | comments | apply | show | ask | jobs | submit | jarek-foksa's comments login

Security-wise, it's a rather bad idea to build a web browser on top of the Atom Electron framework at the moment [1], at least unless you are willing to fork or contribute patches to Electron each time when a new Chrome version with security fixes is released.

[1] https://github.com/electron/electron/issues/5210

The discussion looks "surprisingly civil" probably because admins were removing comments and threatening users with bans.


Which cryptographic algorithms are included in Atom Electron and NW.js frameworks? Does the page [1] list all of them?

[1] https://www.chromium.org/blink/webcrypto


"The Matrix and Quaternions FAQ" is also worth reading: http://www.j3d.org/matrix_faq/matrfaq_latest.html


I've been using quaternions for 15 years now and I still don't have a good mental image of why they work. I've just learned to accept the operations and what they do.


Visualising Quaternions is a book which goes into much beautiful depth about what they represent and how they behave, if you fancy digging deeper than the everyday practicality of them.


I had never heard of quaternions so I Googled the book title you suggested. In addition to the Amazon link [1], I also found a question on the gamedev SE where they talk about building a mental model of quaternions [2], which I found informative.

[1]: http://www.amazon.com/Visualizing-Quaternions-Kaufmann-Inter...

[2]: http://gamedev.stackexchange.com/questions/4801/how-can-you-...


SVG specification distinguishes two types of conforming SVG viewers: static and dynamic [1]. The static viewer does not have to support scripting, animations and user interaction.

A good example of a relatively small static SVG viewer/renderer is libRSVG which is used by GNOME project to render icons.

[1] https://svgwg.org/svg2-draft/conform.html#ConformingSVGViewe...

[2] https://en.wikipedia.org/wiki/Librsvg


"relatively small"

The library takes half a megabyte under archlinux: https://www.archlinux.org/packages/extra/x86_64/librsvg/

It also requires a 1.2 megabyte css parsing library: https://www.archlinux.org/packages/extra/x86_64/libcroco/

And of course also a 8.8 MB xml parsing library: https://www.archlinux.org/packages/extra/x86_64/libxml2/

Now compare this with libpng:


half a megabyte and the only real dependency is zlib, which is also in the dependency tree of librsvg


The main size is dealing with libxml, but that's readily handled by smaller xml libraries [http://pugixml.org]. I mean, maybe you don't want to do SVG on an arduino.

Directly comparing SVG and PNG libraries purely based on library size is misleading. PNG's aren't layered, don't contain semantic information, etc. For me librsvg is lightweight since its way better than installing phantomjs as I have been doing to generate embedable PNGs for documents.


textElement.getBBox().width and textElement.getBoundingClientRect().width should give you the text width in user and client space.


Have you tried them though? Now check it out with kerning and/or italics. Do you see overhanging when you draw the rectangular box found via the API? Good example is strings that end with a character like f.

Works in theory. In practice, it does not. That is what I found but again, I'd be happy to be wrong.


That's interesting, the computed bbox seems to be slightly off on Chrome when I apply "italic" font style.


When working on it a year ago at another employer, we had a list of edge cases. I don't recall them all but some were off by quite a bit. Enough so that the work around was to do everything in SVG except text and use plain DOM position on top for text. That was a bit better. It would be wonderful to do everything in SVG.


I'm currently working on an SVG authoring tool written in JavaScript. You can check the project on https://chrome.google.com/webstore/detail/boxy-svg/gaoogdonm...


SVG is a complex format, but it's not that bad compared to other widely adopted standards. Just for comparison:

- SVG 1.1 - 826 pages (http://www.w3.org/TR/SVG/REC-SVG11-20110816.pdf)

- HTML 5 - 1156 pages (https://html.spec.whatwg.org/print.pdf)

- ODF 1.2 - 1217 pages (https://www.oasis-open.org/standards#opendocumentv1.2)

- PDF 1.7 - 1310 pages (http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdf...)

SVG 2 spec is even smaller because it removes sections that are either duplicating other W3C standards (filters, styling) or not implemented by all major vendors (animations, fonts, path APIs).


You forgot that it also requires XML and CSS. I'm surprised PDF is just marginally bigger, considering that it's carrying around lots of legacy stuff is so much more than just a vector graphics format.

Anyway. SVG is not or only partly competing with the formats you listed. It's actually a format that's supposed to be included in those formats you listed. It's competing with PNG 81 Pages (http://www.w3.org/TR/REC-png.pdf) or EPS 31 Pages (http://partners.adobe.com/public/developer/en/ps/5002.EPSF_S... which is kind of cheated though because it requires the ~800 page postscript specification, at least it doesn't need XML and CSS additionally)

Removing sections that are standardized somewhere else doesn't make a file format easier, especially if you want to implement it outside of a browser.

There's still tons of features in SVG that are probably not used or not really needed:

Mandating IEE 754 binary floating point coordinates, while representing them as decimals that are usually rounded to 0.001 or 0.0001. This causes rounding errors all the time. The 16.16 fixed point format used in ttf seems more sensible for this usecase.

Including (parts of) external SVGs with <use>. <use> doesn't seem to be supported in Safari, Firefox or Inkscape anyway.

<switch> to make an SVG render differently on computers with different locale.

ARIA (accessibility) support, what happened to a description of the image?

Commas as optional separators in paths, but only at certain locations and only at most one of them. There have been several bugs in programs using SVG concerning the parsing path strings that were related to white space.

Basic shapes that can just as easily can be constructed using <path>, especially the polygon and polyline.

The total absurdity that is <text>. Text usually isn't the main content of images, yet the chapter about text is the longest in the SVG specification, containing stuff like text flowing along a path. And all this without supporting multi-line text. Just use <path> instead, bitmap graphics also uses rasterized text. If fonts aren't installed it may cause overlapping, or it might not get rendered at all.


XML dependence will become optional in SVG 2 and hopefully it will be deprecated in SVG 3. Chrome team is already considering switching to HTML parser no matter whether the SVG document uses XML or HTML serialization.

<use> elements with external references are tricky due to the same origin policy restrictions and various browser bugs, but referencing local IDs works just fine. Inkscape for example creates clones and symbol instances with <use> elements.

The most obscure part of the paths specification, i.e. the pathSegList interface, is gone in SVG 2. There were some plans to deprecate the "d" attribute and instead introduce a nicer function-based syntax such as data="move(10, 10) line(20, 20)", but AFAIK this idea has been dropped. Still, the path data grammar is clearly defined in the spec, I'm not sure why browser vendors don't follow it.

SVG 2 will support multi-line text and embedded WOFF fonts. This feature is important when you are authoring e.g. UI mockups or posters. Even low level drawing APIs such as canvas have the text primitive. If you express textual content with <path> instead of <text> element then it will not be editable and selectable, screenreaders won't recognize it and search engines won't index it.


I'm not really into the geopolitics and recent news, but what's wrong with this plan? Hopefully the future European governments will be up to something along those lines rather than balkanization followed by the final solution.

1. Move all illegal migrants to a heavily guarded area akin to the Gaza Strip. All EU members would pay for building and maintaining the camps. Base the camps in a non-EU country so that drastic measures could be taken in case situation gets out of control.

2. Don't grant any new citizenships to legal migrants from high-risk countries, instead issue permanent residence permits and then deport anybody suspected of radicalization.

3. Perform full-scale military intervention in the Middle East to restore the old order. Ideally make deal with Russians and Syrian government to take care of the most dirty tasks.

4. Move migrants back to their homeland.


One of the primary selling points of React is better performance of the virtual DOM, which apparently has no prove in benchmarks [1].

[1] https://aerotwist.com/blog/react-plus-performance-equals-wha...


That article has been discredited pretty thoroughly.

Anyway, it's not a panacea. It can't do much if you're forcing a reflow every few milliseconds.


As a complete outsider, do you have a link or two to support that so I could learn more?

It would seem to me, again completely without knowledge, that a virtual DOM seems suboptimal. Web browsers should be able to optimize for that use case a lot better.


Pete Hunt's talk is good. https://youtu.be/x7cQ3mrcKaY?t=1112 I'd recommend watching the entire video if you have time, but that's the gist of it. More detail:


It is challenging to make a large app with lots of state be performant when you manually mutate the DOM, and there's no way for the browser to fix that because of the way things work.

For example, if you move an element, and then request the position of another element immediately after, the browser will be forced to recalculate layout before giving you an answer. With lots of state and lots of updates, it's very challenging to keep this in the right order.

As virtual DOM is an abstraction over the DOM, you can make a vanilla app that is much faster, but as your app grows, that quickly reverses.


Shadow DOM will allow browsers to optimise their rendering code to re-render encapsulated DOM subtrees independently of each other.

Virtual DOM makes sense when (A) you have a huge tree and (B) you show only a small portion of that tree to the user at any given time.

For example a long scrollable list or a multi-line text editor would be better implemented with virtual DOM, but using it everywhere is an overkill.


If by discredited you mean lots of React fanboys whined about it then yes. If you mean anyone showed actual evidence to the contrary, then no.


Call people fanboys all you want, but after the code was released, numerous glaring issues were found, and still haven't been addressed.


The more correct selling point is that you should be able to get "good enough" performance (usually meaning consistent 60fps) with properly optimized React code.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact