Live data from Hacker News

Do Not Follow JavaScript Trends

pragmaticpineapple.com

271–275 of 275 posts

Re: Do Not Follow JavaScript Trends

#271

Earlier quoted context omitted.

Streamlit is magic and I don't want this to come off as a dismissal, but it can be unpredictably unreliable. I keep having this issue if I run > 0.58: https://github.com/streamlit/streamlit/issues/1440 It's over a month old now, with multiple people reporting the same bug and iterating on the problem with no apparent narrowing towards a reason for why this happens, let alone a solution.

Thanks for clarifying. Since HN isn't the right place for a detailed discussion, I would invite you to comment on that issue and try to help us work through it. As one of our engineers mentions in the linked issue, this bug is hard to trigger (as is the nature of many bugs), and she is working on a solution[1]. This issue has also been reported here[2], with the solution of adding time.sleep(1) inside the loop usuall…

Yeah. What I should have added here, but didn't want to sound brash and rude, is that Streamlit should focus on having a reliable working product before spreading out as an org with a Dev Relations department.

I know this is a complicated problem domain (because it's the web, Mathematica did this well with complex graphs in the mid-90s), but as it stands now my project has an input on which the graphic depends and a default value; the image breaks before the input control is touched. And it's not a slider, it's a dropdown that makes the app query a db first... I mean, I think I can do this in plain Ajax if I get my story right about sending images. But it's a hobby project meant to explore mathematical ideas...

If you can't do sliders reliably, they should be moved to a beta branch. Streamlit overpromises and underdelivers. But it's a great project, I don't want to be too negative about it.

Re: Do Not Follow JavaScript Trends

#272

Earlier quoted context omitted.

Thanks for clarifying. Since HN isn't the right place for a detailed discussion, I would invite you to comment on that issue and try to help us work through it. As one of our engineers mentions in the linked issue, this bug is hard to trigger (as is the nature of many bugs), and she is working on a solution[1]. This issue has also been reported here[2], with the solution of adding time.sleep(1) inside the loop usuall…

Yeah. What I should have added here, but didn't want to sound brash and rude, is that Streamlit should focus on having a reliable working product before spreading out as an org with a Dev Relations department. I know this is a complicated problem domain ( because it's the web , Mathematica did this well with complex graphs in the mid-90s), but as it stands now my project has an input on which the graphic depends and…

I see you've both commented here and on GitHub, so I'll make my last comment here and then we can address the specifics on your ticket (I didn't realize I referred you to your own GitHub issue).

As I mentioned, there is a pull request already created for this issue; our head of engineering/founder says its being held up by a lack of tests before merging. This problem isn't a slider issue, but a race condition in our session state manager.

Regardless, one month is a pretty trivial amount of time as far as open-source projects go, as well as in the history of Streamlit (project became public Oct 2019). Like all projects, we try and address things in the order of severity, and as far as this issue goes, it's a pretty isolated one, not an indication that the library is unreliable or somehow reflects that our engineers can't design at an early-90s level of engineering.

Re: Do Not Follow JavaScript Trends

#273

Earlier quoted context omitted.

> I strongly dislike the create-react-app project because it abstracts everything away That's the point of it, really. CRA sets up your build (webpack) and test runner (jest). Has nothing to do with hooks. I'd strongly suggest using it, unless you're interested in learning how all that stuff works.

Any dev worth their salt should know how to set up these tools from scratch anyway. The day I first ejected a CRA app I had started was the day I decided to never use it again. I could not believe the sheer amount of code behind that project... I’ve been writing reasonably complex React/ Typescript projects for years, and have never had any problems with nothing more than a few simple config files to bootstrap everyt…

> Any dev worth their salt should know how to set up these tools from scratch anyway.

Yeah, I don't agree with that kind of gate keeping. I've known plenty of developers who are proficient with React, Redux, graphql, etc, but might not know where to begin when it comes to build tooling. Almost like they're totally different things.

And that's great that you trudge along with your own lesser version of create-react-app. I've personally built my own JS build toolchains and the second I used CRA I never wanted to look back.

Re: Do Not Follow JavaScript Trends

#274

Earlier quoted context omitted.

Any dev worth their salt should know how to set up these tools from scratch anyway. The day I first ejected a CRA app I had started was the day I decided to never use it again. I could not believe the sheer amount of code behind that project... I’ve been writing reasonably complex React/ Typescript projects for years, and have never had any problems with nothing more than a few simple config files to bootstrap everyt…

> Any dev worth their salt should know how to set up these tools from scratch anyway. Yeah, I don't agree with that kind of gate keeping. I've known plenty of developers who are proficient with React, Redux, graphql, etc, but might not know where to begin when it comes to build tooling. Almost like they're totally different things. And that's great that you trudge along with your own lesser version of create-react-ap…

Is it gate keeping to suggest that developers should understand their tooling? I guess if we can agree the bar we are reaching for is "proficient", then yeah, I suppose a React dev doesn't need to understand how their project is built. There is nothing wrong with "proficient"! I work with lots of "proficient" developers. Great people. Good workers.

I set the bar for myself quite a bit higher than that though. I mentor "proficient" developers because I know with a little push some of these developers can become "excellent". It's usually not for lack of ability that developers stagnate, rather, passion (relative to everything else), curiosity, and time. Sometimes I can bring that glint back into their eyes, sometimes not. Again, there is nothing wrong with that! Having a some reliable code monkeys around is, frankly, usually good for a business.

And FWIW the longer you do this the more apparent it becomes that "less is more"!

Re: Do Not Follow JavaScript Trends

#275

Have followed the trends and I now know Ember, Angular(both legacy and new), Vue(with and without typescript), and React(both classes and hooks). I've also used Svelte, and Stencil JS in my personal projects. In addition, I've also dived headfirst into GraphQL and Typescript pretty heavily lately. Do I regret investing time in learning any of those frameworks or technologies? Not at all. It was fun and interesting at…

The downside probably being that an employer paid you during that time of learning and didn't get much work product out of it. Learning for the sake of learning is an infinite endeavour. I try to practice strategic learning - learning skills/frameworks/topics that will have a high likelihood of being used in the course of my current project. There's just so so much out there... focus is everything.

I am actually paid by my employer to do 5 hours of training per week. It's required and I am allowed to study anything I want, whether it's a new framework or a self-improvement book.

I usually spend that time studying something that I think may be useful or related to my job but I have been encouraged to explore. My employer is a big believer that innovation comes from exploration.

As you pointed out, it is an infinite endeavor. I'm okay with that. If I just stuck with the current technologies that were used when I first came in, we'd probably still be using jQuery and .ERB templates. Instead I personally pushed for using new technologies and my team is personally responsible for introducing Vue, Typescript, and GraphQL to our stack among other technologies.

Post reply on HN