matijash

Thanks for the feedback! I see your point; we could make it clearer from the start that it is JS-oriented. I'm coming from that world, so it seems like I took it for granted.

Also re OSS positioning - I'm actually not aware of modern (but maybe I missed it), polished SaaS starters such as the paid ones that got really popular lately (e.g. supastarter, shipfast), so that's what prompted us into that kind of messaging. We'd like to create a community-driven starting point for developers of equal polish and quality.

Thanks for your support! Yes, the stack is currently fixed (React, Node, Prisma), and I understand developers might have specific preferences.

We'd definitely like to make it more flexible (also in the sense of UI frameworks, etc), but that's something we'll have to figure out step by step.

This sounds cool! How would we go about integrating this with https://github.com/wasp-lang/wasp ?

yep, agree on that, don't see a better way to react

Why do you find the title misleading/clickbait?

I'm following Pynecone (now Reflex) from the start and liked the idea of building out an AST with Python and compiling that to a working web app (we're actually doing the same with https://wasp-lang.dev/, only it's a DSL and an explicit compiler with JS interop).

Although AI has been all the rage lately, I was actually always excited the most by building a compiler. After a few years of dabbling with it, I created one together with my brother: https://github.com/wasp-lang/wasp

It is a DSL (a simple config language for building web apps) so not that complicated as a Turing-complete language, but still a lot of concepts remain.

As a good starting resources for building your own compiler I'd also recommend Crafting Interpreters, super nicely explained and fun to go through: https://craftinginterpreters.com/

This is how we went with https://wasp-lang.dev/ (a DSL for building full-stack web apps). It is a very declarative language (config pretty much) and there is still plenty of work around tooling, but also enabled to cut down on a lot of boilerplate.

Another route to consider when implementing a DSL, is to make an embedded one (e.g. like Terraform or Pulumi have, even both at the same time). That doesn't resolve all the tooling problems since there is still a compile step, but might provide a more integrated experience, although at the cost of brevity.

that's one thing I've been thinking about a lot lately and I think it is confusing for many - that both Next/Nuxt/Remix and Rails have a title of a "full stack" framework while they are pretty different in reality.

Next/Nuxt are coming from the frontend origins and are strongest there, while Rails/Django are coming from the backend and focus on db ORM / data model story via ActiveRecord etc.

I understand the etymology of terminology, but I think we'll probably come up with better names in the future. E.g. Remix briefly called themselves "center-stack" which I found interesting and think makes sense.

I'll keep investigating and probably whip up a blog post about it.

that's what our goal with wasp[0] is - to abstract the common patterns that keep reappearing and condense them to a configuration choice, while still leaving hatches to write your own code. Still have a way to go (in Beta atm) but I think we managed to demonstrate the basic principle in some instances.

[0]https://wasp-lang.dev/

this is a really good summary, thanks!

glad you find it interesting! the plan is to support more frameworks/langs moving forward. The poly-frontend option might be even fairly easier to introduce since Wasp is doing more stuff closer to the server.

yeah in a way. react gets closer to being synonymous with next/remix rather than viewed as a separate, standalone library.

why the link in the text isn't clickable?

works now!

an important question - what did you build Thorium in? How happy are you with it?

This is an awesome idea, stealing it :)

I also wonder how this compares to https://www.framer.com/motion/, anybody tried both?

Very nice! If you want something similar but be able to extend it with your code in React & Node.js, give a try to https://wasp-lang.dev/ (disclaimer: I am the author).

We recently used it with ChatGPT and it was a super good combo for quickly scaffolding a web app: https://www.youtube.com/watch?v=HjUpqfEonow&ab_channel=Wasp

Also apologies for the shameless plug here! :) I really like what you did, happy to provide more feedback on anything.

yeah, that threw me away at first too

I like this a lot! Asking clarifying questions - super easy to come up with, and it will keep the other side busy (and happy :))

Yeah, well put. I guess it's much more about initiating the interaction and showing goodwill rather than the actual content.

nicely done! I like how I get warnings for password not being strong enough. What did you build it with?

nice, thanks for giving it a look! Btw, what is an educational day? You get to spend the day learning something new?

You might also want to check out https://wasp-lang.dev/ - it lets you use React & Node.js (although it seems you prefer php), but you don't have to write API endpoints + everything works out-of-the-box

(disclaimer: I'm one of the main contributors to the project)

Wasp DSL creator here, let me know if any questions :)

Congrats on the launch! This reminded me a lot of what we're going for with https://wasp-lang.dev/ (but for the JS/TS domain atm) and I can definitely relate to the problem.

I'm not a big python user but I can imagine how this might be a really friendly way for python devs to build their own apps. The gallery and examples are also nicely done!

Here is the explicit list of functionalities that Wasp DSL currently offers:

* full-stack auth - username/password or Google (more providers soon)

* routing + ability to protect your routes (only authenticated users)

* running async jobs (e.g. you need send an email, or generate a report), powered by pg-poss

* tight integration of data models throughout the stack - no need to implement CRUD API, automatic cache invalidation, native support for optimistic UI updates

I see your point on Next.js being considered a full-stack solution, given it can execute server code. When referring to full-stack frameworks, I had in mind solutions that also immediately pick and setup a db layer for you. But I agree that is not given and will look into clarifying that in our docs.

Besides db coming out-of-the-box, the biggest difference of Wasp over Next.js is that data models (aka entities in Wasp) are more deeply integrated throughout the whole stack. That means you don't have to implement your typical CRUD API to deal with data. E.g. Once you define your entities (User, Post, ...) and queries/actions that operate on them (getUser, updatePost, ...), you can immediately invoke them from the client (Wasp generates RPC under the hood) without any extra work.

Since Wasp has understanding of your data models (we actually parse the psl, prisma schema language, used for data model definition) it can also provide more help such as automatic cache invalidation [1] (e.g. if you run an action that updates Task entity, Wasp will immediately know it needs to refresh all queries that depend on Task entity, unless you specified differently) and a native support for optimistic UI updates [2].

[1] https://wasp-lang.dev/docs/tutorials/todo-app/03-listing-tas...

[2] https://wasp-lang.dev/blog/2022/11/30/optimistic-update-feat...