padseeker

this ^^^

I've used turbo/stimulus/hotwire. It's best suited for STATELESS interactions withe the browser/web page. The problem is not all desired user experiences and use cases are stateless. And the ecosystem for hotwire is a minuscule fraction of all the other popular js frameworks.

If you're searching for inventory available its perfect. However if you want to update one thing based on the most recently touched input it becomes more complicated and in all honesty more trouble that it's worth.

Honestly if you're a solo Rails dev, use whatever you want. However the React ecosystem, and really all of the other popular JS ecosystems (vue, ), are very strong and you have so many available options. Stimulus is 2 steps back from jQuery, it inverted the Event delegation pattern. No one else outside of the rails community is using it.

Just added you to Launch Point Zero

https://launchpointzero.com/launchsites/innovativ_es

we are expensive to employ

here's another one where someone is complaining

https://x.com/tibo_maker/status/1840656616032489754

I appreciate your comment, and the honesty.

This post is certainly being critical, but I'm also not here to bring the hammer down. I am saying that it has grown very popular, and that makes it harder to get noticed. I know more than a few people have publicly complained on twitter about how their startup listing has been removed or bumped.

I also know there are a lot of scammers out there that PH has to battle against, trying to game the system. I know the people at G2.com when they started and were giving away free ipads for the top people with the most software reviews in a month, and someone tried to jump ahead by downvoting all the reviews of the people ahead of them in a month.

Clearly though expectations have changed. I'm certainly bummed for the 60% of the staff who were laid off. You can't just share your startup without some serious work beforehand or else you risk blowing your shot at 15 minutes of startup internet fame.

My point is not that PH is dying or not, but the game has changed and it has hurt makers who do this for the hope of making a full time living, and we're being crowded out by VC funded startups and previous PH launchers who have had past success (i.e. Tallyforms) that are "relaunching" and sucking up the little amount of attention available on PH. It's frustrating.

I'm sorry the post I wrote in a pinch and shared within 30 minutes and is free does not meet your standards for journalism.

here's a couple of twitter feeds that center on the drama related to product hunt;

https://x.com/WhoWorksThere/status/1840822087868375085

https://x.com/csallen/status/1840792433447391560

https://x.com/HeyImYossi/status/1840634391040577847

theres a lot more in my feed and the people I follow this could be an all day thing but I hope this supports the headline of my post.

Salesforce bought it and there were too many freeloaders.

Options of "local hosting for development purposes"? Do you mean running "rails s" locally on your machine?

Are you saying that the one letter typo on the one of my many points surrounding the drama at Product Hunt discredit the whole thing? No I do not.

Maybe I should have shared in the article all the twitter posts where indie hackers are upset how they are getting screwed and how hard it is to get ranked on PH. There is a lot more drama surrounding PH than just the CTO not knowing one well known community member.

I made a mistake, it will be corrected asap. Thanks for the heads up.

Heroku is the OG of affordable rails hosting. If the tutorial is older than 3-4 years ago then it was published when Heroku was free, which it no longer is.

There are lots of other affordable, but probably not free, options now;

https://railway.app/ https://fly.io/ https://www.hetzner.com/ https://www.digitalocean.com/ https://render.com/

you can't manage permissions very well or precisely. You can give a user "read only" or "edit" but you cannot manage individual sheets or cells. Spreadsheets are great for lots of things, but sharing them with lots of people is not one of them.

hey I think this is very cool and I plan to try it out

higher altitude means less oxygen, means you need to inhale/exhale more to get the proper amount of oxygen, and also faster heart rate. Is it possible the metabolism of people at higher altitudes burn more calories just trying to get the same amount of oxygen?

I'll refine it. I scraped a lot of sites and some of them were terrible. I just figured it was better to have the data there and let users decide as opposed to not having anything. I can see scraping some numbers related to traffic and using that for ranking.

Spoiler alert - The free speech crowd never actually cared about free speech.

Where are all those fanboys who whenever Elon would make a bone headed move, they would correct you about how no Elon is a genius and here's why. I desperately want to hear what they have to say this time.

thanks for the heads up, just fixed it

Explain to me what exactly that means? Do you mean who manages the domains like GoDaddy?

Your first problem is you're using Angular.

There are ways to keep things simple with the front end, only add js for the things where you want instant visual feedback. It requires a little pushback on the part of the dev team, against UX and Product management.

Notice I said profitable niche. You won't magically become the profitable behemoth that Slack will. But you can build a company just on this one angle.

The best engine for generating a startup idea? Find a successful company that charges per user, then build a competing product, and don't charge per user. That's it.

It would be nearly impossible to this for Salesforce. But for a lot of other applications like Slack and Dropbox, you could carve out a profitable niche.

If you are using that many refs you built it wrong - from the React documentation (https://reactjs.org/docs/refs-and-the-dom.htmlhttps://reactj...

"There are a few good use cases for refs:

  Managing focus, text selection, or media playback.
  Triggering imperative animations.
  Integrating with third-party DOM libraries.
  Avoid using refs for anything that can be done declaratively.

Don’t Overuse Refs:

  Your first inclination may be to use refs to “make things happen” in your app. If this is the case, take a moment and think more critically about where state should be owned in the component hierarchy. Often, it becomes clear that the proper place to “own” that state is at a higher level in the hierarchy. See the Lifting State Up guide for examples of this."

React gives you some nice tools to handle most common use cases but you can still make less than optimal decisions.

As someone who built a product that is a form builder that uses React, https://keenforms.com, the best thing I can say is this;

Most of these libraries are fine for simple to medium complexity forms. However once you cross a certain level of complexity these libraries become impediments rather than tools. I probably could have used a redux implementation but build my own state management API with a mixture of object oriented as well as functional programming. The values of the inputs persist so you want objects, but hiding/validating/calculating need to be reset for each change so I used a functional approach for these other features.

React is not perfect and its easy to paint yourself into a corner. However as someone who used to write js for IE6 and has forgotten more js libraries that you can imagine (Dojo, ExtJS, Backbone, Ember, etc) I can tell you right off the bat its the best tool for the job. Not perfect, just like Javascript. Just know and accept its limitations and you should be able to get React to do what you want.

If they enter 'quux' or any invalid number then it should mark it as invalid, but if its blank then treat it as zero. You are correct the validity.valid or checkValidity() could be used in the right way to make the distinction between a blank non required value versus something that is invalid. I literally learned about that less than 24 hours ago.

I'm glad I learned something. And I'm really appreciative the way that you asked, it's been kind of nasty in the comments section.

However this not resolve the visual inconsistency issue for displaying error messages. Many complex forms have their own method of displaying error messages. It requires custom HTML and modifying the DOM. It rarely happens but once in a while the designer wants the invalid value mentioned in the error message. These are all issues that cannot be circumvented with the number input.

I don't love avoiding the number input - but I prefer to keep my job and my client happy. I don't have final say on these kinds of things. Accessibility matters to me, but keeping my job matters more. I've lost a lot of time fighting with the number input.

Not returning the invalid value is in fact the fault of the platform. On more than one occasion I've been asked to put the invalid value in the error message.

If you are using a framework like React or Angular, which I do a lot, then you are using a different approach to validation. Typically you aren't using the DOM API, each framework has it's own approach. You can use the DOM but that is additional work and deviates from the tools provided by each of these frameworks. I probably should have stressed that much of my work is spent using these frameworks. The angular form API is hot garbage but again it's not my choice, I have to use what's been selected. I'm a big fan of React, I have not explored all the options available with React and accessing the value. Typically you aren't using checkValidity when you use React.

The edge case I cited and your solution works. This method will help make the distinction between a non required number input containing an invalid value versus blank. I learned something today. Thank you for this.

I'm going to read more about the constraint validation API.

I stand by my criticism of the fact that the DOM API does not give you the value that appears in the number input. It's actually infuriating.

Also your solution does not solve the problem of a stake holder or product manager or designer who is unhappy about the visual inconsistencies across different browsers and the different validations. Yes the built in validation is useful. However for many of the clients I work for they have high expectations and different demands. The solution you're providing might meet the technical requirement of treating blank like a zero but it would not be accepted by the clients I deal with.

The built in browser validation takes precedence over the javascript validation that is custom built. This has become a massive problem. Even with the ability to customize the error message that doesn't mean the people who are designing or paying for whatever I'm building will find it acceptable. I haven't tested it but I'd be curious what would happen with a large form and multiple native errors, and how do you direct the user to go to each of the inputs that have errors.

I'm not going to list every possible use case, but I've seen a lot. Once you cross a threshold of complexity with javascript form validation the native validation becomes a hinderance that is hard to overcome.

I know there are people on this forum with opinions without having the level of expertise that merits making comments. Not reading someone else's comment while being insulting doesn't help either.

And as far as I'm concerned avoiding using the number input is the least worst option for many of the projects I'm involved with. I could expound upon the input.valueAsNumber method in an update of the article, that's useful in a certain but not all cases. I stand by the content of the article and based on the clients I serve I plan to continue to avoid using the number input. The invalid value as blank string is a deal breaker.

Just because you didn't run into these problems doesn't mean they don't exist. The clients I do work for have very complicated requirements and expect a lot of dynamic interactions from the forms they pay for. It could be a non profit trying to determine if a new client's family qualifies for federal benefits based on family size and income level. It could be a gas pipeline company trying to calculate how much natural gas they can deliver on a 60 day contract during summer months versus winter months. It could be calculating the medication dosage per body weight for a pharmaceutical company. There was the life insurance example which I mentioned in the article.

Ruby will parse "3.9e3" properly. However Ruby on Rails param parser tries to prevent bad data from entering the system. So the e gets sliced off. There are things that you can do to prevent data from being entered that way.

However like I mentioned in the article and commented on multiple times its not always my choice. And overwhelmingly the product managers and stake holders I interact with would prefer to not see numbers submitted in scientific notation form. There's no reason why you would want to submit your age like that. It's highly unlikely anyone would need a product quantity value in that format.

And maybe most importantly the people who pay tell me all the time they don't want it. Does that make sense?

thank you so much for this

I'll admit I name dropped my own product a lot. As a programmer I'm a little embarrassed, bordering on shameless. But as a single founder it means I have to do marketing, which means I have to be a little shameless.

I can't make this any clearer to you - if you have an invalid value like "ABC" you don't want to treat it like a zero, you want to treat it like an invalid value and not perform the calculation until the user corrects the number.

On the other hand if the input is blank you want to treat the value as a zero and perform the calculation.

The problem of getting a blank string for an invalid value means you cannot make the distinction between the 2. I cannot make it any clearer than this.

Not everyone wants to treat a blank number input as a zero, and the ideal situation would have been to default the number input to zero. However like I said in the article multiple times it's not always my call or decision. That why the native validation and visual inconsistency across browsers as well as non compliance with mockups is a problem I've encountered multiple times. When you you cannot see an invalid value or make the distinction between blank and invalid number you lose control over work flow.

Also you rubbed me the wrong way with the snide "indeed" comment. Talking down to people is not a good way to generate a thoughtful debate. I try to approach these things with a certain level of humility. I don't know everything, I even learned a couple of things from other people when I published this article. Have you considered that maybe you don't know every possible requirement or request that I have?