Question / Food for thought - getting rid of dependency on Node

[drkameleon]

Hi guys!

First of all let me say that I do find the project idea intriguing - that's why I've decided to make my first minimal contribution to the project (prog-lang designers united! lol).

I've also just tried it out. Just the basics: install (on macOS catalina) + the prerequisites (here, I must admit the documentation was very helpful) plus the Getting started example. It went fine. :)

I generally love the idea of a custom DSL for that type of thing (as a matter of fact it is one of the use case of Arturo I'm experimenting on), since basically most approaches are trying to "hack" their way into something like that, since they have not been designed for that specific purpose.

What I did not like so much is the dependency on Node.js and nvm.

I mean... I don't know... I may be one of the few programmers that regard it as a super-bloated and heavy thing, with one zillion dependencies (that for one reason or another seems to be half-broken whenever I install it, but ok). So, why depend on that and not be completely independent?

Would you consider going fully autonomous/self-reliant? (autonomous as in zero-dependencies on the server side)

[Martinsos]

I am glad you find it interesting and that it worked on the first try :)!

Dependency on Node.js and nvm -> hm, interesting question.

We could maybe make it implicit instead of explicit, in the sense that Wasp user would not have to install node/nvm themselves, but instead Wasp would obtain it and use it internally, behind the curtains (probably via Docker) - but we haven't given much thought to this yet as to understand the details.

But to completely remove it, that is harder to imagine. If I understood correctly what you mean by "autonomous", you mean implementing turing complete language of our own? While that would be very cool and fun :D, I am afraid it would pull the project in the wrong direction, it would take a lot of time to implement that, and then we are still missing the whole JS ecosystem. Instead, we would rather focus on solving the bigger problems like deployment, state management, ... . But let me know if you have different view of this or if I got smth wrong here!

I checked Arturo, really cool project (I left a comment on it with some impressions)! While Wasp has parser and compiler, it is all relatively simple - for now we don't yet get to play with fun stuff like evaluating expressions, control statements, or having module system and libraries - but I hope we get there soon! Btw. I have been having some fun with following "Crafting interpreters" book and implementing their Lox language in Haskell, that was a lot of fun! Do you have any resources to recommend, for learning to write programming languages, what worked well for you?

[drkameleon]

But to completely remove it, that is harder to imagine. If I understood correctly what you mean by "autonomous", you mean implementing turing complete language of our own? While that would be very cool and fun :D, I am afraid it would pull the project in the wrong direction, it would take a lot of time to implement that, and then we are still missing the whole JS ecosystem. Instead, we would rather focus on solving the bigger problems like deployment, state management, ... . But let me know if you have different view of this or if I got smth wrong here!

I'll have to study the code a bit more and I'll share my view :)

Of course, I can see the point in taking advantage of an existing ecosystem, especially a vast one like JS's - my only point is not to end up being limited by it. (In any case, I may be missing something here - so I'll get back to it once I've studied Wasp! )

P.S. You also have an answer at the other thread @ arturo ;-)

[matijaSos]

@drkameleon I just wanted to say thank you for reaching out, it is really a pleasure to speak to a fellow language designer! :) I can totally understand your frustration with complexity and bloatedness of the current web-dev ecosystem, that was exactly the reason that motivated us to make Wasp.

Re not depending on nvm/Node I agree it is an interesting topic - that would give us more control and allow us to tailor DX (developer experience) to our liking. Currently I see Wasp divided between two worlds: wasp code (e.g. main.wasp file) and "external" code as we call it now (js/jsx, node) which is basically a black box for Wasp compiler.

Currently wasp part of the code is pretty thin and simple, and still a lot is going on in the external (black box) code. What I am excited about is actually gradually moving more and more features from the "external" side to the "wasp" side - so developer will be able to express more and more features directly using Wasp. That is cool because then Wasp compiler will actually understand what developer wants to achieve and will be able to check it in compile time and also e.g. decide which type of target code it wants to generate (e.g. maybe dev can even choose if he wants Angular or React as a target code).

Ok that's some of musings from my side :D Would love to hear also more of your thoughts on this and how you imagined it to work. How do you feel about depending on React for the frontend, is that also something you would consider removing?

[drkameleon]

@matijaSos Hi!

I just wanted to say thank you for reaching out, it is really a pleasure to speak to a fellow language designer! :)

My pleasure as well! Exchanging ideas and helping each other is always beneficial - especially, on interesting projects :)

I can totally understand your frustration with complexity and bloatedness of the current web-dev ecosystem, that was exactly the reason that motivated us to make Wasp.

Re not depending on nvm/Node I agree it is an interesting topic - that would give us more control and allow us to tailor DX (developer experience) to our liking. Currently I see Wasp divided between two worlds: wasp code (e.g. main.wasp file) and "external" code as we call it now (js/jsx, node) which is basically a black box for Wasp compiler.

Currently wasp part of the code is pretty thin and simple, and still a lot is going on in the external (black box) code. What I am excited about is actually gradually moving more and more features from the "external" side to the "wasp" side - so developer will be able to express more and more features directly using Wasp. That is cool because then Wasp compiler will actually understand what developer wants to achieve and will be able to check it in compile time and also e.g. decide which type of target code it wants to generate (e.g. maybe dev can even choose if he wants Angular or React as a target code).

I absolutely get your point. I just want to be 100% sure what I'm talking about - and what Wasp actually does - before saying something. I'm sharing some thoughts for now. I did try it out but not extensively enough, not to mention that I haven't spent sufficient time reading the code yet (the code always speaks tons more! :-))

Ok that's some of musings from my side :D Would love to hear also more of your thoughts on this and how you imagined it to work. How do you feel about depending on React for the frontend, is that also something you would consider removing?

Well, I think you are reading my mind! haha.

Look... I've always seen myself as a programmer (not a "web developer", or a "web... something" - even if other people could easily consider me as such at several points of my coding life).

One thing I've always found unnecessary in the world of webdev is the need for one million different languages (be it markup, or styling, or scripting when, in 2020, things should have already moved to more all-encompassing design, with the different parts being ONE thing.

Now, for me, all React does (and Vue, and Angular, and all these) is add an another extra layer of complexity. (Yes, in theory, it's there to make our life easier, but not really - at least, not for me. I would prefer something more elegant, to mixing html-ish tags, with javascript-ish code, without a second thought).

I've been playing with Google's Dart and Flutter these days and it all looks to me like a mashup between some weird OOP-version of JavaScript and React again, which is gonna end up traspiled to JavaScript (or maybe not) and something that could resemble a WebView (but supposedly is not - or at least more performant). Ah, on top of it, only to get the thing running, I have to install 10 different packages, via yet-another package manager, then a couple more "frameworks" and then export PATH=... like crazy.

Just too much (visual and mental) clutter, for something that should be much more straightforward in the first place. I mean... it's practically a webpage in an app(!)

I may be being too much of an idealist here, but one benefit we obviously have when designing a language from scratch is to be able to dream of whatever we want after all ;-)