Quinn – A web framework designed for things to come • Hacker News Board

Re: Quinn – A web framework designed for things to come

#21

Post by justin_vanw » Fri, May 08, 2015, 8:13 PM UTC

reverius42 wrote: post #19

justin_vanw wrote: post #12

It's a rite of passage to create a crappy, half baked web framework. It's a great thing that every web developer should do so that they understand, end to end, the tensions facing the creators of web frameworks, the tradeoffs between the various attempts to balance purity with convenience, and how much 'magic' you want a framework to perform vs how much should be completely explicit. However, nobody should ever use t…

You can call it amateurish and shitty all you want, but I'll take Express (on Node) over Flask or Tornado (on Python) any day.

Well, to be fair, Flask is kind of crappy and does anyone even use Tornado anymore?

I always just set up a project myself using Werkzeug, in the era of WSGI, almost all of the heavy lifting for web apps is done automatically and outside of your application anyway.

Re: Quinn – A web framework designed for things to come

#22

Post by NhanH » Fri, May 08, 2015, 9:12 PM UTC

justin_vanw wrote: post #21

reverius42 wrote: post #19

Earlier quoted context omitted.

You can call it amateurish and shitty all you want, but I'll take Express (on Node) over Flask or Tornado (on Python) any day.

Well, to be fair, Flask is kind of crappy and does anyone even use Tornado anymore? I always just set up a project myself using Werkzeug, in the era of WSGI, almost all of the heavy lifting for web apps is done automatically and outside of your application anyway.

This is the first time I've seen Flask being called crappy. Do you mind elaborate why?

Re: Quinn – A web framework designed for things to come

#23

Post by nealrs » Fri, May 08, 2015, 10:29 PM UTC

justin_vanw wrote: post #21

reverius42 wrote: post #19

Earlier quoted context omitted.

You can call it amateurish and shitty all you want, but I'll take Express (on Node) over Flask or Tornado (on Python) any day.

Well, to be fair, Flask is kind of crappy and does anyone even use Tornado anymore? I always just set up a project myself using Werkzeug, in the era of WSGI, almost all of the heavy lifting for web apps is done automatically and outside of your application anyway.

Flask isn't crappy. It's an excellent way for learners & aspiring polyglots (like me) to build a functional app and learn about routing. And it's got a bazillion useful extensions.

Is it great for a production environment? No clue. Same with Tornado. But it's definitely a solid pick.

Re: Quinn – A web framework designed for things to come

#24

Post by Twirrim » Fri, May 08, 2015, 11:04 PM UTC

NhanH wrote: post #22

justin_vanw wrote: post #21

Earlier quoted context omitted.

Well, to be fair, Flask is kind of crappy and does anyone even use Tornado anymore? I always just set up a project myself using Werkzeug, in the era of WSGI, almost all of the heavy lifting for web apps is done automatically and outside of your application anyway.

This is the first time I've seen Flask being called crappy. Do you mind elaborate why?

Because it's not written in javascript, obviously

Re: Quinn – A web framework designed for things to come

#25

Post by mrmondo » Sat, May 09, 2015, 1:46 AM UTC

I'm not convinced we need more JavaScript frame works also FYI the site loads very slowly on my iPhone 6+, Australia.

Re: Quinn – A web framework designed for things to come

#26

Post by poulsbohemian » Sat, May 09, 2015, 4:09 AM UTC

justin_vanw wrote: post #21

reverius42 wrote: post #19

Earlier quoted context omitted.

You can call it amateurish and shitty all you want, but I'll take Express (on Node) over Flask or Tornado (on Python) any day.

Well, to be fair, Flask is kind of crappy and does anyone even use Tornado anymore? I always just set up a project myself using Werkzeug, in the era of WSGI, almost all of the heavy lifting for web apps is done automatically and outside of your application anyway.

>does anyone even use Tornado anymore?

We do for as many apps as possible. The async / callback structure is far easier for our developers to understand over Javascript/Node. Tornado is significantly different from other Python frameworks like Django and Flask, but IMHO it is under appreciated.

Re: Quinn – A web framework designed for things to come

#27

Post by jgalt212 » Sat, May 09, 2015, 8:12 PM UTC

mrmondo wrote: post #25

I'm not convinced we need more JavaScript frame works also FYI the site loads very slowly on my iPhone 6+, Australia.

While in general it's important that sites load well on mobile, I'm not sure that's a valid critique for a developer tools site where most users will have at least a well-powered laptop with a large screen. I'm sure you're familiar with that old saw about the correlation between screen size and productivity.

Re: Quinn – A web framework designed for things to come

#28

Post by vortico » Mon, May 11, 2015, 6:31 AM UTC

benologist wrote: post #15

vortico wrote: post #2

On an unrelated note, do arrow functions inherit the parent context's `this` and `arguments` correctly in Node or io.js now?

They explicitly do that in ES6: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Right, but implementation hadn't caught up to spec since I last checked.

Re: Quinn – A web framework designed for things to come

#29

Post by benologist » Mon, May 11, 2015, 1:48 PM UTC

vortico wrote: post #28

benologist wrote: post #15

Earlier quoted context omitted.

They explicitly do that in ES6: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Right, but implementation hadn't caught up to spec since I last checked.

It's natively supported in typescript and iojs, and babel (prev. 6to5) + other libs enable it in browsers.

Re: Quinn – A web framework designed for things to come

#30

Post by ianbicking » Mon, May 11, 2015, 3:41 PM UTC

Reminds me of WSGI in Python – which is to say, the simplicity of functions that take requests and return responses, and then all your composition techniques are regular programming techniques. (With Promises added into the mix of course, but then you have .then() chaining with similar effect.)

It doesn't seem like a huge deal, but it's so much more convenient, makes it easier to think about the code, modify and rewrite values, all the normal programmy stuff people like to do in programs with values, instead of objects and actions. And yeah, if you use websockets or HTTP/2 or some other low-level stuff then it's going to break down, but there's only a couple of those and they should each just get their own separate layer.