Not sure I agree. I didnt know about gitjournal until vHanda's post, but immediately saw how it could be a replacement for my use of Google Keep (which I use when I'm on the go vs at my laptop). And there was already an exporter for Google Keep. I'm guessing that exporter benefited from a spec being available.
Your point about "if you're the only one using it, just use it" does apply, but sometimes we do find ourselves being more successful than we originally expected and defining things via a spec is not a bad thing.
or frink [1], which started off as a tool like the others mentiond here, but is now a full fledged units-based programming language. See some examples of them here [2]
minor nit about your website: the top menu's css might need adjusting. On my laptop (dell xps) the last letter of each word shows up in the next line, like so:
Abou FAQ
t s
Triggered my (minor) OCD!
Edit: added minor due to comment below in an attempt to clarify. The wierd text placement does bother me, i'm not joking. but its not that bad that i cannot get past it and read the rest of the website. thought i'd let the OP know; dont mean to poke fun at people who have been diagnosed with OCD. i'm still learning these terms via a child who was diagnosed with ADHD.
Especially considering this is a post about mental health, can we please quit labeling being picky as OCD? OCD is a serious condition, not a "haha I'm picky" joke.
didnt mean it as a joke. I did not have another label for my pickiness as you call it. i'm still learning these terms via my child who has been diagnosed, but the thing that bothered me is that it was misaligned. i have similar issues with magazine stacks that are not aligned, for example. i thought that was what was called mild ocd, hence used the word. make what you will of that.
Fair enough, it's just a pet peeve of mine. Like people who had a few too many drinks and start cracking jokes about being an alcoholic.
Have you looked into OCPD? (Obsessive Compulsive Personality Disorder) From my relatively uninformed knowledge on the subject, that sounds closer to OCPD. (Of course, talk to a licensed health practictoner, not a procrasting software engineer)
OCD sufferers prefer to call that OCPD. Being bothered by stuff like that is nowhere near as serious as real OCD which can be traumatic and life ruining.
I love new languages, and I love that you have all the basic elements of webapps as first class citizens.
....and then I saw that the page is still written using React and db access uses Prisma. They are not dependencies, you have to now about them, and their syntax and how they work.
What is the incentive for me as a developer to learn both them and wasp? Especially since there are multiple places where the wasp layer is a thin layer over the underlying capability supported by those dependencies.
Dont get me wrong. I say go bigger and make it a full-fledged DSL that generates react and prisma code without making them __visible at all__. That way nobody has to learn anything but wasp. Sure, you will be limited by whatever your underlying implementation layer is, but you can now switch from them easier, and its likely to last longer (there __was__ a time before React, and like will be one after too).
Can you be the +1 layer that people dont have to look under? More specifically:
1. Can you have inline .js files? Even better: Can you bring the page content _into_ wasp's syntax? It currently says a webapp has pages and routes, how about expanding to say a webapp has components, elements and text?
2. Same question for storage schemas and migrations. Would that help with NoSQL integrations (vs expecting Prisma to support them)?
3. Can you eliminate the "Note:" sections in https://wasp-lang.dev/docs/language/basic-elements? Those are the leaks in the abstraction called wasp. And if the answer is no, then should there be a better abstraction?
I love the idea you are describing, it is very much our initial (and maybe final) vision that we had when we started working on Wasp! But, our vision of the best approach for the current moment is somewhat different, let me explain below.
Web apps are complex beasts, and we believe there is a reason for multiple DSLs being used today (HTML, CSS, React/Vue/... as embedded DSL, Prisma as schema DSL + db access embedded DSL, Terraform, ...): it is easier to solve the problem by splitting it into subproblems and then solving each one of them with specialized language/DSL, than figuring out one DSL that works for everything. Even if we found one DSL that works for everything, it would at the end likely be a combination of multiple DSLs unified in one language.
So, if we decided to solve it all at once with Wasp, we would be solving N problems at the same time, and would need to beat whatever is the current best solution in most of the areas to be compelling enough to be used. At the same time, we would be competing with the whole web dev ecosystem that has shown in the recent years to innovate and progress very quickly.
That is why we believe more in the current approach we are having: by utilizing existing solutions for sub-problems, solutions that work relatively well and are on the edge of what we know is the best way of solving those sub-problems, and building our DSL in the space in-between, where the most of the friction is happening, we are bringing value where it matters the most while also riding the web dev ecosystem wave, instead of fighting it directly.
This doesn't mean that we can't expand Wasp with additional sub-DSLs if we figure out at some moment that, e.g. we have a better abstraction than React that would fit really well in Wasp - we can still do all that, but we can do it step by step, while still progressing in the meantime.
Also, this might not be very clear in the docs, but the idea of Wasp is not be tied just to React - idea is to also support Vue, Svelte, and whatever is coming next, when defining components. Also, idea is to support not just NodeJS, but also Go, Python and similar on the backend (maybe you could even combine them).
Regarding learning -> is it better for a web dev to learn complicated Wasp language and how to write view logic in it and how to write db access logic in it, or to learn a simple, smaller Wasp language and how to write view/db logic in React/Prisma?
I think the second, since complexity is going to be similar in both cases due to Wasp becoming more complex in the first case, to be able to describe both view and db, while in the second case you are learning technologies that you can also use outside of Wasp later or you maybe even already know them.
Just to make it clear, what you are suggesting, to have 1 DSL for all -> I love it, it is our initial vision, and one I would very much like to be possible. We actually started that way with our prototype, but soon concluded that we need to divide and conquer (well, more like delegate in this case) if we are going to win this battle. We started with having elements in DSL like button, forms, but we left those to React for now -> however, we will probably try getting back to that in the future, if we manage to establish some footing first.
To answer the specific questions:
1. Yes! We are planning to relatively soon allow mixing of JS and Wasp logic, mostly for the purpose of making the code more readable and easier to organize. Describing lower-level details of the web app with Wasp, e.g. page content, elements, text -> that we would also like to do, but probably further in the future.
2. We initially started with our own syntax for describing schemas -> then we moved to Prisma since they have a DSL that works well. Right now we are working on our own Prisma DSL parser (almost done!), so that we can reason about those schemas independently of Prisma. Next step would be having our own syntax, which would make us independent of Prisma, as you said -> and yes, I believe we will be getting back to that relatively soon! Mostly with purpose of making it as simple and easy as possible. But now we will be armed with the knowledge of what worked well regarding Prisma DSL (PSL), what didn't, and what should work differently for Wasp.
3. That is a very good point, we should make that a rule: eliminate assumptions/caveats that we have to warn our users about - those are leaks in abstraction. I believe we can, but if not, I agree, we should look into modifying how we abstract those parts.
Advance apologies for coming across strong, but for an article advocating clarity, it is utterly devoid of an examples of how to actually achieve it. If your title starts with "How to..." you should SHOW, not TELL, and the article was a whole lot of telling. And the one example that was accidentally there - the image at the top - did not clarify if it was a good one or not (see discussion here, for example).
Others have found issue with the grammar and sentence structure of the article, I found it totally opaque.
Show me an example of a mental model (or the absence of one). Pull an excerpt from the Times or the economist and contrast it with another publication that is not clear. Wouldnt this help us "understand, know and" eventually "do"?
And given that the advice is to think about your audiences and communicate with purpose, please do ask yourself: What is the purpose of this article? If it's to tell us to strive for clarity, please show us how, don't just tell us to do so.
Your point about "if you're the only one using it, just use it" does apply, but sometimes we do find ourselves being more successful than we originally expected and defining things via a spec is not a bad thing.