Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Voila – From notebooks to standalone web applications and dashboards

voila.readthedocs.io

Post reply on HN
Print view View original

81–90 of 92 posts

Re: Voila – From notebooks to standalone web applications and dashboards

#81

Post by lmeyerov »

throwaway2568 wrote: post #63

Voila is quite nice but I find panel [1] is the best option these days. It has plenty of widgets, including those from Voila which can be used as a backend, a few different ways of defining callbacks and has added nice features lately like autoreload if you are using scripts instead of notebooks [2] and new fast HTML elements so it's super easy to define custom widgets straight from the web. They have a discussion pa…

We find that design decisions like forcing data scientists to code UI callbacks are big limiters to adoption, which is intuitive as that's pretty close to telling them to write JavaScript in Python. Same thing for styling ("CSS in Python".) They can in theory, but rather spend time on other things.

So far, the only low-code PyData framework we saw that avoids most "JS in Python" is StreamLit. However, even there, it is still awkward in practice, so we still see limited adoption by folks who are fine with notebooks, so rarely goes beyond a champion. So there is room to grow.

Re: Voila – From notebooks to standalone web applications and dashboards

#82

Post by throwaway2568 »

lmeyerov wrote: post #81
throwaway2568 wrote: post #63

Voila is quite nice but I find panel [1] is the best option these days. It has plenty of widgets, including those from Voila which can be used as a backend, a few different ways of defining callbacks and has added nice features lately like autoreload if you are using scripts instead of notebooks [2] and new fast HTML elements so it's super easy to define custom widgets straight from the web. They have a discussion pa…

We find that design decisions like forcing data scientists to code UI callbacks are big limiters to adoption, which is intuitive as that's pretty close to telling them to write JavaScript in Python. Same thing for styling ("CSS in Python".) They can in theory, but rather spend time on other things. So far, the only low-code PyData framework we saw that avoids most "JS in Python" is StreamLit. However, even there, it…

I would still recommend panel, it is perfectly straightforward to make a clean UI in pure python and the "depends" approach to interactivity works just by adding decorators to functions. You can prototype in either notebooks or scripts, particularly with the auto reload feature which I believe is inspired by streamlit.

Here is an example https://panel.holoviz.org/gallery/layout/distribution_tabs.h...

Re: Voila – From notebooks to standalone web applications and dashboards

#83

Post by lmeyerov »

throwaway2568 wrote: post #82
lmeyerov wrote: post #81

Earlier quoted context omitted.

We find that design decisions like forcing data scientists to code UI callbacks are big limiters to adoption, which is intuitive as that's pretty close to telling them to write JavaScript in Python. Same thing for styling ("CSS in Python".) They can in theory, but rather spend time on other things. So far, the only low-code PyData framework we saw that avoids most "JS in Python" is StreamLit. However, even there, it…

I would still recommend panel, it is perfectly straightforward to make a clean UI in pure python and the "depends" approach to interactivity works just by adding decorators to functions. You can prototype in either notebooks or scripts, particularly with the auto reload feature which I believe is inspired by streamlit. Here is an example https://panel.holoviz.org/gallery/layout/distribution_tabs.h...

I don't think you're getting the difference between possible & clean for programmers, vs. easy & straightforward for the target market. Most non-engineers don't want to spend time learning and tweaking this stuff, they want to work on the analysis, domain problem, and later, sharing it with others, not spending hours learning & debugging development & UI stuff. That's time away from their actual work & their families.

Ex: It took me awhile to appreciate StreamLit's builtin layout: it largely eliminates "HTML-in-Python", so one less thing. Likewise, decorators are weird magic, so yet another educational hurdle. If a tool could do excel -> dashboard, most would rather that! While I love that stuff, and I can recommend it to coders, I've learned to not recommend it to teams that can't guarantee everyone is... which is most. It sounds like Panel is slowly reinventing StreamLit, but as StreamLit isn't even there yet, for most corporate use, I'd be trying to do much more than catchup on this specific aspect if you want it to be relevant here.

Fun story: a PhD friend for a much-lauded company on HN led a team of ~20 analysts. About ~2 people loved Python, and the rest would write pages of SQL to avoid it.

Re: Voila – From notebooks to standalone web applications and dashboards

#84

Post by hereforcomments »

abdullahkhalids wrote: post #42

I have a question about hosting costs - not a SW. Suppose I write some educational Jupyter notebooks, which are not particularly resource intensive, say 100 seconds of compute time per notebook. I host them on some cloud server, using something like OP, and get a 1000 people to learn from it. Maybe they end up using say, 1000 people x 5 notebooks x 100 seconds/run x 20 runs of each notebook = 10 million seconds of co…

Just use Google Colab. It's completely free. I used to teach 300 people on it while sharing my notebook with them and live streaming my sessions.

Re: Voila – From notebooks to standalone web applications and dashboards

#85

Post by SylvainCorlay »

fxtentacle wrote: post #16

Tried their example link: "Problem: package xeus-cling-0.12.0-h5a79028_0 requires xtl >=0.7.0, sigh I don't know when it started, but it seems to be a recent trend to add dependencies for anything and to package everything on demand. It's probably for security or something. But I do miss the days when people would link a static binary that "just works" even without internet and that'll keep working a week later, beca…

Voilà author here. This is fixed. I was requiring a wrong version of cling in the example.

FYI, xeus-cling is a Jupyter kernel for the C++ programming language.

https://github.com/jupyter-xeus/xeus-cling

Re: Voila – From notebooks to standalone web applications and dashboards

#86

Post by qayxc »

abdullahkhalids wrote: post #60
qayxc wrote: post #48

Earlier quoted context omitted.

This could cost anywhere from nothing (e.g. free) to 3-figures (in USD) depending on the specifics. How many users are accessing the notebooks concurrently (e.g. all 1000 or only a dozen at a given time)? Is there any downtime, i.e. do the users come from the same time zone, so that app can have inactive hours (say it's OK to be unreachable during the night)? Depending on the specifics, free hosting may be available…

We run a non-profit minimal-budget workshop where currently hundreds of people work together at the same time, but they run code on their own computer. But making people install Jupyter and other python packages on their computer is difficult. So we are exploring the possibility of the hosting the notebooks ourselves. We don't want options like Google Colab, because we want the experience to be tightly integrated (th…

Well, with that tight of a budget the best option would be to find a sponsor tbh.

Just contact local(!) hosting providers and ask if they could sponsor such events. This would mean advertisement for them (maybe even tax deductible depending on the legal status of your organisation) and free resources for you.

I can't think of any kind of on-demand service that will handle 500-1000 concurrent users for 50 hours that's under 100 USD. AWS nano instances are 0.256 USD per user per 50 hours (e.g. your workshop scenario), but that's still above your budget even with 500 users. Basically you'd need to find an on-demand hyperscaler that offers instances with ~1GiB + 1vCPU for less than 0.004 USD/h (500 users) or 0.002 USD/h (1000 users).

Working on providing a simplified local install method (e.g. a docker image or a VM image hosted somewhere cheap) is the only realistic way to stay within your budget.

Re: Voila – From notebooks to standalone web applications and dashboards

#87

Post by throwaway2568 »

lmeyerov wrote: post #83
throwaway2568 wrote: post #82

Earlier quoted context omitted.

I would still recommend panel, it is perfectly straightforward to make a clean UI in pure python and the "depends" approach to interactivity works just by adding decorators to functions. You can prototype in either notebooks or scripts, particularly with the auto reload feature which I believe is inspired by streamlit. Here is an example https://panel.holoviz.org/gallery/layout/distribution_tabs.h...

I don't think you're getting the difference between possible & clean for programmers, vs. easy & straightforward for the target market. Most non-engineers don't want to spend time learning and tweaking this stuff, they want to work on the analysis, domain problem, and later, sharing it with others, not spending hours learning & debugging development & UI stuff. That's time away from their actual work & their families…

Thanks for the response and context. I work in a different domain to data science and it's fair to say that most people I work with would prefer writing a few 10s of lines of python than many pages of SQL!

Regarding your second point, looking at streamlits announcements page [1] it seems many features being added, layouts/themes and session state/callbacks for example, indicate to me that streamlit is heading in the direction of panel/dash more than the other way. Streamlit also emphasizes using decorators for caching [2], which I agree can end up with some overall state that is a bit magic.

Overall I think the optimal use cases are a bit different for the sets of tools, and I find the approach of dynamically calculating a full script for every change of a slight widget quite onerous, and actually just not feasible for the use cases I have.

[1] https://blog.streamlit.io/tag/announcements/

[2] https://blog.streamlit.io/six-tips-for-improving-your-stream...

Re: Voila – From notebooks to standalone web applications and dashboards

#88

Post by mountainriver »

BiteCode_dev wrote: post #75
cycomanic wrote: post #72

Earlier quoted context omitted.

I think you are seriously overestimating the "programming proficiency" of many scientists. I don't think the OP meant that scientists should be experts in the web stack or even in the intricate details of the scientific stack. However, I do expect that they should know how to write reasonable maintainable code, i.e. use functions, modules, don't just copy paste code around between cells etc.. (this is seriously the s…

If you think functions and modules as an example of what makes a code maintanable, then I'm afraid we won't be able to agree. I've seen data scientists handling big code bases. The problem was not they couldn't use the language features. The problem is that they would be always lacking essential information for their mission because their is not enough time in a day for a regular human being. They would put a md5 has…

> If you think functions and modules as an example of what makes a code maintanable,

It’s definitely a part of it. This isn’t an all or nothing thing, one can learn good practices without encumbering their scientific work.

Re: Voila – From notebooks to standalone web applications and dashboards

#89

Post by SylvainCorlay »

raziel2p wrote: post #36
fxtentacle wrote: post #16

Tried their example link: "Problem: package xeus-cling-0.12.0-h5a79028_0 requires xtl >=0.7.0, sigh I don't know when it started, but it seems to be a recent trend to add dependencies for anything and to package everything on demand. It's probably for security or something. But I do miss the days when people would link a static binary that "just works" even without internet and that'll keep working a week later, beca…

Python projects around jupyter, pandas etc. seem especially bad at making reproducible environments. They lock to versions that don't work very well, only work with specific versions of Python (without documenting it)...

This has nothing to do with Python. The faulty package was xeus-cling, a C++ kernel for Jupyter.

Re: Voila – From notebooks to standalone web applications and dashboards

#90

Post by analog31 »

BiteCode_dev wrote: post #9
pavlovskyi wrote: post #4

I really like Jupyter notebooks to build a simple concept and then move to .py files. But what I observe, especially at the entry level or junior level jobs in data science is that people spend huge amount of its work on jupyter, which did not focus on how to plan flow properly. What I meant is that there is very short path from usefullness to overkill.

That's because they are not programmers. One should not expect them to be experts in 2 fields. They do their work with the tool provided, and if we want a better output, we need to provide better tooling or accept what comes out. I want my physicists to spend their mental effort on physics, not on software architecture.

Maybe there's a confusion here between programming and software development. One is a tool for the other, but can be used by itself too.

I'm a physicist (not "data scientist" though I work with plenty of data), and I've been programming since 1981. Anything I do, I want to do well, especially if I do it regularly or it could cause problems if done badly. I've made an effort throughout my career to keep up with good programming practices. I do that out of a combination of pride, curiosity, and professional ethics.

But I'm not a software developer, meaning that I don't create software for widespread or long term use by others. We have an entire department for that, and many of their techniques are quite specialized.

Naturally it wouldn't surprise me if further improving my skills also moves me closer to being capable of software development, and I'm happy to learn and apply their techniques at a pace that works for me. I think that a scientist who is capable of learning to program should receive guidance on how to do it better, but perhaps in stages, such as:

1. Writing code that has a better chance of working, even as it gets bigger and more complex.

2. Working with others on projects that involve sharing code, meaning that it has to be readable and conform to agreed upon standards.

3. Creating code that can be confidently "shipped" for widespread or long term use.

Post reply on HN