Hello list, After admiring Parenscript from afar for many years I'm finally taking the plunge into web front-end development. I'm using Preact <https://preactjs.com/> with Parenscript - so far so good. After reading the article How to make your React app fully functional, fully reactive, and able to handle all those crazy side effects <https://medium.freecodecamp.org/how-to-make-your-react-app-fully-functional-fully-reactive-and-able-to-handle-all-those-crazy-e5da8e7dac10> I would like to incorporate Redux, Cycle.js and Immutable.js, by porting redux-cycles <https://github.com/cyclejs-community/redux-cycles> to Preact (and Parenscript). Looking at the sample code, these modern JavaScript libraries (particularly the more functional ones) make heavy use of ES2015 features such as: - Arrow functions - const - let - Spread properties <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax#Spread_in_object_literals> - Rest parameters <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/rest_parameters> - Destructured function parameters - etc. I realise that pretty much all of these are just syntactic sugar, but I wanted to ask whether anyone other than me thinks it would be nice if Parenscript knew about these modern niceties and could be directed to generate them, and what the general roadmap (if any) is for Parenscript, before I start looking at what's involved. Thanks very much, John :^P -- John Pallister john@johnp.net john@synchromesh.com
I have found it easier to do Flux like patterns using rxjs. Basically the "store" subscribes to changes from "actions" and is subscribed to by the views interested in that store's state. I found it cleaner than the many versions out there. On Fri, Nov 9, 2018 at 10:55 AM John Pallister <john@synchromesh.com> wrote:
Hello list,
After admiring Parenscript from afar for many years I'm finally taking the plunge into web front-end development. I'm using Preact <https://preactjs.com/> with Parenscript - so far so good. After reading the article How to make your React app fully functional, fully reactive, and able to handle all those crazy side effects <https://medium.freecodecamp.org/how-to-make-your-react-app-fully-functional-fully-reactive-and-able-to-handle-all-those-crazy-e5da8e7dac10> I would like to incorporate Redux, Cycle.js and Immutable.js, by porting redux-cycles <https://github.com/cyclejs-community/redux-cycles> to Preact (and Parenscript). Looking at the sample code, these modern JavaScript libraries (particularly the more functional ones) make heavy use of ES2015 features such as:
- Arrow functions - const - let - Spread properties <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax#Spread_in_object_literals> - Rest parameters <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/rest_parameters> - Destructured function parameters - etc.
I realise that pretty much all of these are just syntactic sugar, but I wanted to ask whether anyone other than me thinks it would be nice if Parenscript knew about these modern niceties and could be directed to generate them, and what the general roadmap (if any) is for Parenscript, before I start looking at what's involved.
Thanks very much,
John :^P -- John Pallister john@johnp.net john@synchromesh.com
I love ES6 for classes, arrow functions. I avoid its Set and Map as I don't think they are well written. Spread properties are useful for passing state to child components but outside that I seldom find myself using them in my own React frontend work. Rest parameters I haven't found much use for although the cdr like possibilities are obvious. Destructuring is another that I have seldom had a need for. So I wouldn't go overboard getting every single feature. But given the right boilerplate to except ES6 features can't parenscript just put out ES6 javascript? On Fri, Nov 9, 2018 at 3:24 PM Samantha Atkins <sjatkins@gmail.com> wrote:
I have found it easier to do Flux like patterns using rxjs. Basically the "store" subscribes to changes from "actions" and is subscribed to by the views interested in that store's state. I found it cleaner than the many versions out there.
On Fri, Nov 9, 2018 at 10:55 AM John Pallister <john@synchromesh.com> wrote:
Hello list,
After admiring Parenscript from afar for many years I'm finally taking the plunge into web front-end development. I'm using Preact <https://preactjs.com/> with Parenscript - so far so good. After reading the article How to make your React app fully functional, fully reactive, and able to handle all those crazy side effects <https://medium.freecodecamp.org/how-to-make-your-react-app-fully-functional-fully-reactive-and-able-to-handle-all-those-crazy-e5da8e7dac10> I would like to incorporate Redux, Cycle.js and Immutable.js, by porting redux-cycles <https://github.com/cyclejs-community/redux-cycles> to Preact (and Parenscript). Looking at the sample code, these modern JavaScript libraries (particularly the more functional ones) make heavy use of ES2015 features such as:
- Arrow functions - const - let - Spread properties <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax#Spread_in_object_literals> - Rest parameters <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/rest_parameters> - Destructured function parameters - etc.
I realise that pretty much all of these are just syntactic sugar, but I wanted to ask whether anyone other than me thinks it would be nice if Parenscript knew about these modern niceties and could be directed to generate them, and what the general roadmap (if any) is for Parenscript, before I start looking at what's involved.
Thanks very much,
John :^P -- John Pallister john@johnp.net john@synchromesh.com
Not by default, I don't think. But there's always https://github.com/vsedach/Parenscript/pull/39 I haven't dug into it to see what the conflicts are though. On Fri, Nov 9, 2018 at 3:31 PM Samantha Atkins <sjatkins@gmail.com> wrote:
I love ES6 for classes, arrow functions. I avoid its Set and Map as I don't think they are well written. Spread properties are useful for passing state to child components but outside that I seldom find myself using them in my own React frontend work. Rest parameters I haven't found much use for although the cdr like possibilities are obvious. Destructuring is another that I have seldom had a need for. So I wouldn't go overboard getting every single feature.
But given the right boilerplate to except ES6 features can't parenscript just put out ES6 javascript?
On Fri, Nov 9, 2018 at 3:24 PM Samantha Atkins <sjatkins@gmail.com> wrote:
I have found it easier to do Flux like patterns using rxjs. Basically the "store" subscribes to changes from "actions" and is subscribed to by the views interested in that store's state. I found it cleaner than the many versions out there.
On Fri, Nov 9, 2018 at 10:55 AM John Pallister <john@synchromesh.com> wrote:
Hello list,
After admiring Parenscript from afar for many years I'm finally taking the plunge into web front-end development. I'm using Preact <https://preactjs.com/> with Parenscript - so far so good. After reading the article How to make your React app fully functional, fully reactive, and able to handle all those crazy side effects <https://medium.freecodecamp.org/how-to-make-your-react-app-fully-functional-fully-reactive-and-able-to-handle-all-those-crazy-e5da8e7dac10> I would like to incorporate Redux, Cycle.js and Immutable.js, by porting redux-cycles <https://github.com/cyclejs-community/redux-cycles> to Preact (and Parenscript). Looking at the sample code, these modern JavaScript libraries (particularly the more functional ones) make heavy use of ES2015 features such as:
- Arrow functions - const - let - Spread properties <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax#Spread_in_object_literals> - Rest parameters <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/rest_parameters> - Destructured function parameters - etc.
I realise that pretty much all of these are just syntactic sugar, but I wanted to ask whether anyone other than me thinks it would be nice if Parenscript knew about these modern niceties and could be directed to generate them, and what the general roadmap (if any) is for Parenscript, before I start looking at what's involved.
Thanks very much,
John :^P -- John Pallister john@johnp.net john@synchromesh.com
Hi John,
I realise that pretty much all of these are just syntactic sugar, but I wanted to ask whether anyone other than me thinks it would be nice if Parenscript knew about these modern niceties and could be directed to generate them, and what the general roadmap (if any) is for Parenscript, before I start looking at what's involved.
Adding support for newer ECMAScript features in Parenscript output is part of the plan. There is a variable *JS-TARGET-VERSION* that controls the ECMAScript version the output will target. Peter Stirling has already started work towards ECMAScript 2015: https://github.com/vsedach/Parenscript/pull/39 The general road-map I have in mind is, first, to release Parenscript 2.7. I plan to make 2.7 the last 2.x Parenscript release. After the release, the Parenscript code will become part of Parenscript 3, which will have some incompatible changes: removal of deprecated macros and special operators, and different system and package names (to prevent conflicts between Parenscript 2.x and 3, and to no longer define short two and four letter package names, which conflict with people's package nicknames in their systems and the REPL). I also have a pile of ideas for improving the internals of the Parenscript compiler, and improvements in the efficiency and correctness (with respect to Common Lisp semantics) of the generated Parenscript code, that are non-breaking changes. The most significant change for Parenscript 3 will be the license: Parenscript 3 will incorporate the 3 clause BSD licensed Parenscript 2 code into a copyleft (GPL version 3 or later) project. There are a lot of reasons for this that I can go into in more detail, if anyone is interested. The short explanation is that my experiences in the past six years have very strongly convinced me that working on non-copyleft Free Software is against my own (and the general public's) interests. I have decided to re-license Free Software projects that I created or maintain under the GPL. Vladimir
participants (4)
-
Clint Moore -
John Pallister -
Samantha Atkins -
Vladimir Sedach