On Mon, Oct 7, 2013 at 4:37 PM, Łukasz Mach <lukasz.m...@pagema.net> wrote:
> 1d. Make 100% Python support mandatory and not just a goal. There were >> too many times that I was bitten by the conversion process where >> features either weren't supported or didn't behave as expected. I think >> if this project is going to become popular then 100% compatibility is >> absolutely critical, specifically MRO needs to work properly, if you add >> an attribute on a parent class, it should be visible in instances - >> right now basic things like that are broken. >> > > Won't it make runtime slower? For 100% compatibility I think a little slowness is worth it. We can also find ways to optimize it over time. As long as the code is modular and easy to do that with. My original complaint about slowness was that it's slow right now *despite* not being 100% compatible. If it was compatible and slow at least there is an obvious/tangible compromise, you're giving something up to gain something. If it's not compatible but still slow, that just sucks in my opinion :-) > 2. Rip out the widget library. It should be a 3rd party project >> altogether outside of the pyjs repo. It's nice but not necessary to be >> productive. Pyjs is a web technology first and foremost. >> > > From other side - widget library is thing which can bring more users. Of > course, if it's fancy, glowy sparkling and working in examples :). Meteor has no widget library and it is a lot more popular than Pyjs. jQuery became popular way before the jQuery UI project. Even still, lots of people use jQuery today without the UI module. The truth is that Pyjs is a web technology first and foremost. If you know HTML/CSS sufficiently you can be as or even more productive than the folks trying to pigeon hole desktop style widget based technologies onto HTML. Widgets are nice for prototyping but at the end of the day you should really learn HTML5/CSS. For demo apps, we can just use Bootstrap. It's popular and has the bare bones essentials. > 3. Provide very close integration with popular server side technologies. >> I vote for Django and Twisted. >> > > Yep. It's very important IMHO - I just wrote small project django+pyjs and > it was big pain to make it working together (BTW - I want to make > pyjs+django bootstrap project in free time, problem is that there is no > free time last days ... :) ). I'm willing to put my time towards Pyjs+Django+Bootstrap as well. I think the first steps is to break the project up and then have people volunteer to pick up the pieces that are important to them. I think it's easier to get the momentum going if you know others are working on different pieces and there is a common goal. Anthony, can we create a plan of action, specifically agree/vote on a common use case and specific/practical mission statement so that we are all on the same page. I think having a mission statement and core goals will help to make the project feel less overwhelming and if someone agrees with the philosophy of the project it will be easier for them to get behind it. I'd be willing to put some effort into the Pyjs+Django integration if someone else seriously picked up the compiler/runtime. Any takers to dive head first into compiler refactoring? I have a prototype of a runtime I did a while back that supported much better python MRO. The basic concept was to chain prototypes together to match the linear shape of the MRO. This meant that you could set an attribute on a super class and it was instantly available in an instance of a subclass (a simple use case that is not possible with current pyjs runtime). For most users this is not necessary but if you are building a framework it's critical to be able to do this kind of plumbing modification. In fact, my advice would be to just do the compiler/runtime from scratch. If you base it on the built-in python parser lib you'd already eliminate probably half of the code in Pyjs. The bulk of the effort will then be the JS code generator and the runtime. - lex -- --- You received this message because you are subscribed to the Google Groups "Pyjs.org Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to pyjs-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
