mindrun

Awesome! Let us know if you have any feedback!

At the moment the guides available at https://ronin.co/docs could be used for getting started! We're working on landing a starter boilerplate in the coming weeks (early 2024).

Definitely!

It's a breeze to set up with any frontend framework, but will work especially well with Next.js (built by Vercel).

Only the "Serverless Function Region" feature, meaning being able to select which specific region a Serverless Function runs in, is only available for Pro Teams.

It seems as if this wasn't clear from the UI. Would you agree? It sounds like you've assumed that it's the entire Serverless Function feature that would not be available.

Great suggestion! We'll add a link right after the conference.

Whenever the Next.js + Vercel combo gains a new feature, Vercel ensures that it's available in standalone Next.js too – even when deployed to other providers.

That's true for all the features mentioned in the Next.js 10 blog post: Image optimization, Internationalization, but also Analytics.

Since you mentioned the latter: Did you notice that we wrote a detailed documentation page about how to report those metrics to any service of your choice?

https://nextjs.org/docs/advanced-features/measuring-performa...

Sure, there's obviously a whole UI piece to this as well – but since you interact with Next.js programmatically and there's a quite sophisticated data storage that needs to back all of this as well, Vercel optionally provides you with a pre-built solution.

But again, to be clear: If you want to use Analytics + Next.js elsewhere, Next.js supports reporting them natively – even if not hosted on Vercel.

I'm glad to hear! Over time, more and more guides and proper documentation will be created for Now 2.0, so I'm sure you won't have any troubles with migrating any kind of application to Now 2.0. Aside from that, your bill is most likely going to decrease heavily, as Now 2.0 is much cheaper than Now 1.0.

This release of `now dev` is indeed a preview release. We're working very hard to improve the quality of the CLI, so should you notice any bugs, please let us know and we'll get right to it: https://zeit.co/feedback/dev

Hey, Leo from ZEIT here!

I agree strongly. There's been a lot of chance over the last couple of months, as Now 2.0 appeared and the entire platform started adapting to it.

However, I'd also like to let you know that the entire concept of "platform versions" is just a temporary way of slowly allowing everyone to migrate to Now 2.0 at their own pace. Once this process is complete, the whole concept of platform versions will disappear and I hardly doubt there will be any major changes from that point on.

Thanks for the compliments! That's exactly what our product is trying to achieve: Abstracting away all of that low level stuff, so you can just run `now` and that's it.

The command used for this can be invoked on any OS that Now CLI supports (Linux, Alpine, macOS and Windows). In terms of the languages that are supported, there's no end, really:

https://github.com/zeit/now-builders/tree/master/packages

(These are just the default ones, you can add your own language using https://zeit.co/docs/v2/deployments/builders/developer-guide...)

Thanks for your feedback. We've actually received quite a lot of other feedback regarding the new pricing model and will – as a result – soon be working on a way to set custom alerts and limits, so that it behaves just like 1.0 pricing, if you want it to.

With regards to 1.0 "just working": Aside from making 2.0 more intuitive, we're heavily investing into tools that allow you to automatically transition existing applications to 2.0, so that would definitely help a lot.

I'm glad to hear. Should you encounter any bugs, please let us know at https://zeit.co/feedback/dev and we'll get right to it.

I love what they're going for! However, I really don't think that text messages are the future. Looking at things like WhatsApp, iMessage, FB Messenger and others, a company like Apple will probably drop support for them very soon. A possible fix for this would be to support 2FA apps like Google Authenticator for communicating those codes. If not, I'm more than sure that Apple will release some kind of API for services that allows us to send messages...

Maybe this helps you: https://zeit.co/now#pricing

Awesome idea! Thank you for sharing it :) Haven't worked with Python so far, but it looks pretty straightforward.

If you want to see how it looks, either clone it: https://github.com/small-cake/server/blob/master/CONTRIBUTIN...

Or take a look at the Dribbble page: https://dribbble.com/notleo/projects/349841-Muffin

I still need to make a few changes before I'll be able to deploy the first development version. :)

Well, if someone really manages to get a copy of that token from the localStorage of a user's browser: Yes. However, there's now way to get access to the localStorage from a different domain (as far as I know). The attacker would have to place a script on the site itself and if he's able to do that, he's probably also able to access its contents.

When talking about cookies, there's also a way to limit those to certain URLs.

Great idea! Will keep that in mind for later.

It's not ready yet. The source code will be release on GitHub as soon as it's stable :)

How about code.org? http://studio.code.org

Let me clear up some confusion here. First, thank your for following up to this thread, it helped me to understand your position better. What your comments also taught me, is that I need to be way more precise when writing a post like this.

Firstly, I was mostly talking about languages like JavaScript that are running directly within the browser. When it comes to Back-end-techniques I don't see the necessity for this type of improvement, especially since most languages there are compiling before a request even comes in (or include some neat ways to cache the output).

To be clear: I haven't thought about using this "Snippet"-technique for software running on your mac/pc, it's thought for the web. I don't care about disc space or anything like that, in this post, I was just thinking of a new way to limit the size of the data packages that are downloaded from the server, each first time someone visits a site. And this "first hit" is really important to me and to many other developers out there. It's the first time a website or -app is actually downloading to a visitors client. Therefore I'm pretty focused on making it a good experience for the user.

I'm also thankful for that "compare 1 line of code to call library function versus e.g. 15 lines of code snippet" argument, I completely agree with you there. But when I say "snippets", I'm actually talking mainly about JS-functions (for example) that can be called on a specific DOM-Element, Object, String or whatever.

You can also take a look at the comments on my site, I posted a comment about "dynamic frameworks", maybe that will be a proper solution for the future. But as I already said, as long as this is not real yet, the "Snippet"-technique is probably the best way to achieve fast web-applications, in my opinion.

Sorry for not stating everything clear enough, again. I will make sure to do better in the future. :)

Yep, you're probably right. I mean, dragging the slider from left to right clearly increases the TB-number to 1000 (where it stops) and 1000 TB = 1 PB

Cool, thanks! Much appreciated! :)

I think think they will do anything to prevent that. I mean, it's made for the web, so it's technically made for every device from every provider.

Don't you think 'dirty snippets' are just a matter of who made them and in which way they're presented? When sharing them as Gist on GitHub (https://gist.github.com) for example, they're very well formatted.

I also think that choosing small libraries wouldn't help us here, because there will always be some stuff that's not being used. And that's exactly what I'm trying to avoid as best as possible here.

Also, what's wrong with copy-and-pasting code? This changes neither the formatting of the code nor makes it less readable, if you ask me (and I'm of course not talking about indenting with spaces, of course - that's terrible).

ooookay, That might sound a biiiiit too self-convinced, sorry for that :D

I think I found a short way to web-developer's garden eden...

Why don't you just stop writing him? I mean, it looks like he's just not interested in chatting. Or did he do this to your client?

Hehe, that's a another good point! Didn't think of the "sandbox" attribute before, will do so next time I write about iframes. Thanks for the info!