3 ms·
In this case based on them targeting node/express on the backend and react on the front, the advantage is that you can create a language that is easily-ish tran
by blacktriangle 5y ago
In this case based on them targeting node/express on the backend and react on the front, the advantage is that you can create a language that is easily-ish translateable into Javascript.
The problem with using a Ruby or other language DSL is that since you're giving the developer full access to the programming language, you now have to also support translating the full scope of the programming language into Javascript.
One might then say just make it a JS framework except that JS syntax doesn't lend itself to these kinds of DSLs the way Ruby and several other languages do.
- cyanydeez 5y agothe detaios presented on the main page look like they are basically creating a dsl based around typescript, then exploding that into existing frameworks. its a code generator, which will feel nifty, but as soon as any idea you have needs real coding and the dsl isnt prepared for it, so long dsl or hello magical routines. somewherd in q0 years therely be a dev cursing these guys build script with limited documentation andmumbling to himself "it reads fine...it reads fine..."
- blacktriangle 5y agoThe value prop of this does seem really wierd. So you accept a limited DSL in return for eventually being able to target multiple web stacks...but the point of this is to abstract away all those web stacks? I really don't get it.
- remram 5y ago> translateable into Javascript I didn't realize this was for web app frontend. This is not mentioned in the repo, in fact the README seem to indicate otherwise: > Concepts such as app, page, user, login, *frontend*, production, etc. are baked into the language