f34nk
The landscape of available Elixir packages for html tooling is overseeable but in that sense also very focused. Each library is there for a distinct use case.
For that reason I compiled a quick overview of the available html tools in Elixir.
Right now I only covered: Floki, HtmlSanitizeEx, Meeseeks, Myhtmlex, ModestEx
In my humble conclusion, I state that benchmarking is not very useful since the goal and main strength of each library is different. Also the tested methods are not really comparable, since the implemented overhead is very different between each library. It is safe to say that all libraries perform very very fast.
All in all, I would say, the focused nature of the tools makes it easy for the user to pick the right tool for the job.
However, the ecosystem of tools is still quite young. There is room for improvement.
Please feel invited to discuss missing features or differences to other libraries in other languages.
Best, f34nk
Trending in Discussions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #security










Showing Posts 18 to 9- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
f34nk
@mischov
I repeated the benchmarks and my benchee and benchfella results are different.
My benchfella shows the same result like you described. But the benchee measurements are somehow different.
I removed the benchee graphs from the repo and did some updates in the README. I hope this is better now.
Thanks for the feedback!
mischov
Hardware variation aside, it seems like the included graphs might just be a little wonky
The graphs I generated were more in line with the textual output and clearly showed Meeseeks parsing smaller input slower and larger input faster than Floki (which is not surprising when Floki is using the
:mochiwebparser).f34nk
Thank you! I will update that.
Also true. I will change that, too.
Interesting. I will check that out.
That’s odd.
One is the output of benchfella, the other benchee.
Do you have time to clone and repeat the bench yourself?
I actually did some benchmarking in
Cfor my package and came out with different results too. I will have to investigate further to be sure what’s going on.mischov
@f34nk Feedback for the updated benchmarks.
Meeseeks returns it as a
Document, which is a flat map of node id to node struct.You also appear to be using the
:mochiweb_htmlparser for Floki, which is the non-HTML5 compliant one, so you’re comparing apples to the HTML5 compliant oranges of the other parsers. Of course, AFAIK it’s impossible to run Floki’s HTML5 parser on the latest version of OTP, but that’s a different problem all-together.Also curious if when you’re benchmarking, are you disabling CPU throttling (as mentioned here)? I’ve found that can reduce variation in run times when benchmarking.
Finally I’m interested why the averages shown in the text results don’t appear to be reflected in the images: for instance it appears when looking at the images that 50k Floki is faster than 50k Meeseeks, but according to the text 50k Floki averaged 16633.17 µs/op while 50k Meeseeks averaged 12018.79 µs/op.
dimitarvp
IMO 90% of the JS devs just have no idea how to use them. And have in mind I am a JS hater so I ain’t gonna be one of these guys that tell you “just use it right” – but in this case it’s partially true. I’ve seen some rare JS website gems that are incredibly fast and smooth even on spotty 3G on an iPhone 5c.
That being said, I fully agree with you.
And I am going back to server-side rendering more and more with time.
f34nk
Hello!
I updated the parsing benchmarks on the elixir_html_tools repo and added some test cases with small filesizes - which was missing before.
To my surprise Floki and Meeseeks are incredibly fast for data sizes smaller 1kB. You can check out the runtime distribution here.
So, packages like Myhtmlex or ModestEx, that are using C Nodes, come with additional latency.
When there is time I will setup a dirty-NIF test, too.
Cheers
mbenatti
Drab is a framework, it handle with dom using websockets, he has your “own” controller caled “commander” and it uses Phoenix as a base, so is a complement.
GitHub - nico-amsterdam/phoenix_form_awesomplete: Phoenix text_input autocomplete (autosuggest) with on-demand Ajax calls, utilizing Lea Verou's Awesomplete widget. · GitHub, is like an “html component” to create (autosuggest) with on-demand Ajax calls, utilizing Lea Verou’s Awesomplete widget, he uses this lib GitHub - LeaVerou/awesomplete: Ultra lightweight, usable, beautiful autocomplete with zero dependencies. · GitHub behind the scenes!
f34nk
PhoenixFormAwesomplete looks interesting. How is it different to drab?
IMO those projects are born out of the unique connection of phoenix and websockets. It just makes it much more obvious that you can do something like that. Or do I miss something? I am not a UI or even frontend guy, so maybe I don’t see the full picture here.
mbenatti
You’r right, I agree with you!
I used both in my projects, including drab!
I miss more activity by the community for tools like Drab and for components like Phoenix Awesomplete form helper…
I like Drab and its powerful however I can’t see companies/projects showcases using it yet.
f34nk
https://github.com/h4cc/awesome-elixir#html