danielskogly

I found this demo of him playing "Into the Breach" with only Face Gestures very impressive! https://twitter.com/GoingHandsfree/status/140022171083874713...

Congratulations on the launch! This looks super nice, and if I understand it correctly, it's _kinda_ like creating a Checkout Session and redirecting the user, but more direct.

About a year ago I was toying with the idea of creating a SaaS/product that worked completely without JS, and the only hurdle was that there currently is no way to simply answer redirect a client directly to the Checkout page after creating a Checkout Session in the backend. Currently, you have to create the Checkout Session, send this to the client, load StripeJS, and _then_ you can redirect to the Checkout page.

Seeing that the Payment Link is basically the same thing, only that instead of a backend, the seller can create the Payment Link ("Checkout Session") in a dashboard, it doesn't really seem like the StripeJS-step I mentioned above is strictly necessary.

I hope you'll add a way to get the URL when creating a Checkout Session in the backend, so that the dream of a fully-functioning noscript SaaS might one day come true :)

Previous discussion from 11 months ago: https://news.ycombinator.com/item?id=23671022

My preferred DB layer is Objection.js[0] which is simply an ORM-layer on top of knex[1], with official TypeScript support.

[0] https://vincit.github.io/objection.js/

[1] https://knexjs.org/

As far as I can see, it's the exact same as the one listed in this[0] article, and without having seen your CV design, I guess it's completely coincidental.

[0] https://zety.com/blog/software-engineer-resume

I realize you're not using React for t.ly, but the method I outline in this[0] blog post could perhaps be made to work for you if you at any point would like to accommodate users without JS enabled. Yours is the kind of site that this method is best suited for - a relatively simple UI with basic I/O.

The biggest hurdle I've encountered so far, is that Stripe doesn't offer a fully nojs alternative to enable users to make payments, although this would be incredibly easy for them to do, considering that they already offer a hosted checkout[1]. The only thing missing here is a way to get the checkout URL itself from the server side, when the Checkout-session is generated.

[0] https://blog.klungo.no/2020/05/28/using-react-and-redux-to-a...

[1] https://stripe.com/en-no/payments/checkout

Seconding this! Lichess is also free/libre and open-source[0], and has a really nice API[1] allowing you to do pretty much anything you could think of wanting to do when it comes to online chess.

[0]: https://github.com/ornicar/lila/

[1]: https://lichess.org/api

Is this related to Uno[0] by Fuse Open, which is also a C#-thing for native app development?

[0] https://github.com/fuse-open/uno

Thank you for this! I realize now how confusing that is. An updated version should be up any second :)

Facebook is only mentioned in the context of how I did things previously, before I implemented the email/password registration.

I fully agree, so when I released the update with email/password registration, I also stopped allowing new account creations via Facebook. Now it's only supported for login for legacy reasons, and those users can disconnect their Facebook account after connecting an email.

Using something like bcrypt would definitively be better, but considering that the email is the identifier, I would have no way of retrieving the correct hash to check it against, so the salt must be fixed to allow for lookups.

I'm currently using SHA512 with a fixed salt. If someone gains access to only the database and not the salt, the emails are well protected. If someone gains access to both, then it's true that they could build a rainbow table to check if a given email exists in the database. What they _can't_ do is easily use all the emails in the database for spam/phishing/etc.

Either way, I'd argue it's better than nothing :)

You're right that could be an issue, but hopefully anyone who registered via Facebook will take care to add an email/password to their account and disconnect Facebook before they delete their Facebook account.

This is really useful! You might want to consider hiding the “More”-button if the current page isn’t filled up, so as to not just have an empty page when clicking it.

For some reason I couldn’t find my own blog post[0], even when searching for the embarrassing typo I made in the title - acommodating.

[0] https://news.ycombinator.com/item?id=23426951

Both of those frameworks support SSR, and can then be made to work without JS on the client side for many use cases.

I completely agree, and acknowledge that there are plenty of web apps that just can't work without JS [0][1][2]. It's the middle ground of web apps that I think might have the most to gain - web apps that _can_ provide their main functionality without JS, like Asana, GitLab, Product Hunt, Pinterest, etc.

[0] https://audiomass.co/ [1] https://html5gamepad.com/ [2] https://agar.io/

I get what you're saying, and for many use-cases fully static websites is all you need. What might have been a better title for my post is "(Coincidentally) accommodating [..]", as the main target audience still remains users _with_ JS. By following some guidelines, using a couple of helpers, and avoiding certain interactions for _required_ interactions - ie. you can have sparkles on mousemove all you want, but don't gate important app functionality behind it - you will _also_ support users without JS. If the implementation cost is low, the potential gain of you and other users who might enjoy a JS-less experience might well be worth it.

For my part, I'm developing a service targeting privacy-minded people, and the ~1.75m NoScript users/installs are then among my main target audience.

I wrote about a generalized way to use React, Redux and SSR to make sites that work without JS a short while ago[0] and I’m currently employing that strategy for a side project I’m working on.

So far the biggest drawback is not being able to do a payment flow with Stripe Checkout without requiring JS on _my_ service, because Stripe.js is required to redirect a user to the checkout session.

[0] https://news.ycombinator.com/item?id=23426951

It's only render-blocking if put before the content! You can actually see this if you load up the demo[0] and reload the page. For some reason, I've made the mistake of putting the script-tag for the JS bundle _after_ the main content but _before_ the footer. The footer is also rendered on the server, but you'll see - especially if you throttle your connection - that the main app will appear instantly, but the footer ("Try without javascript :)", etc.) won't appear until the JS has finished loading.

This is why today it's common to put script-tags for external JS at the end of the body-tag.

[0]https://todo-react-redux-noscript.herokuapp.com/

For me the response time is ~100ms on average, me being in Norway and the server in the U.S., but YMMV.

I'm sure there are more efficient ways of implementing something like this, but it demonstrates the approach. The main goal here isn't to make something that is super snappy for users with JS disabled, but rather that they get something _at all_, without burdening the developer too much.

Exactly! As long as your framework supports SSR, and you got an event-based state container, you're good to go.

I agree! What I hoped to showcase in this post, is a way to support users without JS, while not changing how the web app is built. You would still _develop_ the site using JS :)

That can definitively work for some applications!

My goal with this post and demo was to outline a general strategy that could be employed in both small and large applications. For some cases, you could implement the server-side dispatching of actions as listening on GET-requests, but you would potentially be polluting the browser history more than necessary, and be capped to ~2k characters (varies in browsers) for actions (which for many cases should suffice).

I imagine that keeping all _state_ in the URL, while it can work for some small applications, might not scale sufficiently to be a general approach to the problem, nor have the kind of persistence usually found in eg. applications with login, where a user might expect to be able to authenticate and continue where they left off.

If I understand you correctly, then the answer is no. As strogonoff mentions in his comment[0], most of the frameworks that provide helpers to enable SSR also provides a way to "rehydrate" in the client side. React has to ways of rendering the app to a string, where one of them outputs html that can be used as the basis for rehydration[1], while the other one[2] drops any extra DOM attributes that the former adds.

[0] https://news.ycombinator.com/item?id=23446779

[1] https://reactjs.org/docs/react-dom-server.html#rendertostrin...

[2] https://reactjs.org/docs/react-dom-server.html#rendertostati...

I was surprised that my post on a strategy to make modern web apps work without JavaScript didn't get any attention, but I might just need some work on my writing and titles.

The topic is one I expected to hit the nail on the head with the HN crowd, though.

https://blog.klungo.no/2020/05/28/using-react-and-redux-to-a...

This is a demonstration of a way to make things work for users without JS enabled, making use of React, Redux and SSR.

You can find a complete write-up of here: https://blog.klungo.no/2020/05/28/using-react-and-redux-to-a...

How to accommodate users without JavaScript without changing the development flow in modern web app development is something I've been thinking about for a while, and I'm happy to finally share this writeup and proof of concept.

If you just want to check out the demo, you can do that here: https://todo-react-redux-noscript.herokuapp.com/

I've been with ProtonMail a couple of years now, and recently made the step to buy my own domain to use for personal email. What I'm hoping is that whenever I want to switch provider in the future, it won't be any more trouble than to switch some DNS settings :)

That's great to hear! I'm not too familiar with Fullstory, so I recommend reading up on their GDPR docs[1] and judge for yourself :)

[1] https://www.fullstory.com/resources/gdpr-and-fullstory/#how-...

Consider changing the grid texture and re-recording your videos. Depending on the level of zoom, it creates an unpleasing effect: https://send.firefox.com/download/f3465be7ff20fc88/#Ebv76l6w...