Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FastUI: Build Better UIs Faster

github.com

Post reply on HN
Print view View original

211–220 of 230 posts

Re: FastUI: Build Better UIs Faster

#211

Post by int_19h »

dustrider wrote: post #92
int_19h wrote: post #66

Earlier quoted context omitted.

The XML+XSLT equivalent here would be an XSLT stylesheet with a bunch of predefined rich parametrized templates that you can just . Hand-coding XSLT to produce HTML (or whatever) is still rather tedious.

Did this extensively in the mid-naughties. Huge site, lots of data and traffic. Performance exceeded what was available at the time, scaled super well, but not something I’d ever go back to. - xslt is not a programming language. As soon as you start using xslt:functions you’re doomed. - it is not a fit for interactive UIs. It’s good for static content, trying to mix in js goes wrong very quickly. My opinion is that t…

Once you get to XSLT 2.0+, it is a programming language, just a very verbose one. I did a lot of XSLT/XQuery back in mid-00s, albeit not in web frontend context (we used it for code generation).

Unfortunately no browser has ever supported anything past XSLT 1.0.

Re: FastUI: Build Better UIs Faster

#212

Post by int_19h »

LtWorf wrote: post #72
int_19h wrote: post #65

Earlier quoted context omitted.

The ultimate RAD was Windows Forms, in my opinion. It's been downhill ever since. Remember how you could just "add" a database connection to your project, plop a data source on a form, then a datagrid or a bunch of text/check/comboboxes and the standard control, wire it all up in a couple clicks, and things just magically worked? That was a lovely time to work on any kind of line-of-business app.

> The ultimate RAD was Windows Forms Layouts >> fixed size window

It has that.

Re: FastUI: Build Better UIs Faster

#213

Post by int_19h »

dgiovan wrote: post #100
int_19h wrote: post #65

Earlier quoted context omitted.

The ultimate RAD was Windows Forms, in my opinion. It's been downhill ever since. Remember how you could just "add" a database connection to your project, plop a data source on a form, then a datagrid or a bunch of text/check/comboboxes and the standard control, wire it all up in a couple clicks, and things just magically worked? That was a lovely time to work on any kind of line-of-business app.

THe ultimate RAD was Delphi.

C# 1.0 was, to a significant extent, Delphi with a Java-like syntax (which is no wonder given who designed it), and WinForms is so much like VCL, often the only difference is the presence or absence of the "T" prefix.

By now C# is a much more powerful language, though.

Re: FastUI: Build Better UIs Faster

#214

Post by int_19h »

nurettin wrote: post #81
int_19h wrote: post #65

Earlier quoted context omitted.

The ultimate RAD was Windows Forms, in my opinion. It's been downhill ever since. Remember how you could just "add" a database connection to your project, plop a data source on a form, then a datagrid or a bunch of text/check/comboboxes and the standard control, wire it all up in a couple clicks, and things just magically worked? That was a lovely time to work on any kind of line-of-business app.

Data source on the form idea originated from Borland Delphi. Later, Anders Hejlsberg quit Borland to work at Microsoft, where he implemented the idea of visual and non-visual components and property editors in .net You would be even more impressed with Delphi, because after connecting your data source, your form fills with data at design-time. Lazarus and Typhon does the same.

Yes, I'm well-aware of the genesis. In my opinion, .NET + WinForms stack was a better Delphi.

And if I remember correctly, it could also do the "fill the form with data" trick.

Re: FastUI: Build Better UIs Faster

#215

Post by marcosdumay »

Timwi wrote: post #210
boxed wrote: post #189

Earlier quoted context omitted.

The N+1 problem is solved in iommi (again, I am one of the authors) by simply: 1. keeping a log of queries per request with stack traces 2. at the end, checking if there are N+1 problems 3. print a big warning with example SQL and stack trace to the console During dev if I miss a prefetch_related/select_related the console will start to print gigantic stack traces telling me where the problem is. I don't have these p…

Can you explain what an N+1 problem is?

You have a query like:

select * from book where author_id = 5

If you represent your data as objects, you'll create a Book class with an attribute of type Author. If you now want to run the query above, you'd say (in c# likelihood, but not a real Entity query):

Database.Set().filter(author.id = 5).all()

But that instructs the ORM to fetch the author attribute from all books, and only then filter it by id. So, you will end up running the following query:

select * from book join author on book.author_id = author.id where author.id = 5

There is no reasonable way to represent the difference between this query and the one on top with an object representation. And even though both have exactly the same semantics, databases have been historically bad at optimizing them so the second one can be orders of magnitude slower.

Re: FastUI: Build Better UIs Faster

#216

Post by neonsunset »

mvdtnz wrote: post #184
marcosdumay wrote: post #159

Earlier quoted context omitted.

And yeah, you are just reinforcing the GP's point, because all of those are atrocious. I am at the ORMs are bad club, but if you try any of the systems that encode the logic paradigm into their interface, they are a completely different kind of beast. (MS has brought some of it into C# with linq so you can use with the Entity Framework. It's not a fully logic system, and has so many attrition points with the Entity F…

I'm very familiar with Linq and Linq to SQL. It's as close as any ORM got to being "good enough" and was abandoned by Microsoft very early in its lifecycle. Linq in Entity Framework is a minefield of N+1's and excessive eager loading.

Thankfully, not an issue as of today. EF Core has client-side evaluation disabled by default. It was an enormous footgun in EF so to bring that behavior back you have to explicitly opt into it.

Re: FastUI: Build Better UIs Faster

#217

Post by neonsunset »

marcosdumay wrote: post #215
Timwi wrote: post #210

Earlier quoted context omitted.

Can you explain what an N+1 problem is?

You have a query like: select * from book where author_id = 5 If you represent your data as objects, you'll create a Book class with an attribute of type Author. If you now want to run the query above, you'd say (in c# likelihood, but not a real Entity query): Database.Set ().filter(author.id = 5).all() But that instructs the ORM to fetch the author attribute from all books, and only then filter it by id. So, you wil…

EF Core compiles a query for the entirety of the expression provided. I wonder if it actually outputs select * from book join author on book.author_id = author.id where author.id = 5 as you described - this seems like a pit of failure a framework would work hard to prevent from happening.

Re: FastUI: Build Better UIs Faster

#219

Post by asyx »

LtWorf wrote: post #192
animal_spirits wrote: post #180

Earlier quoted context omitted.

Django's ORM is beautiful, I can glide through queries using it. It makes SQL a breeze

But is it fast?

Fast enough. You get enough tools to optimize the queries. Keep in mind that Django is still a web framework. You can go nuts with Django and it starts to feel like maybe raw SQL would have been easier but I've rarely encountered this.

Re: FastUI: Build Better UIs Faster

#220

Post by boxed »

LtWorf wrote: post #197
boxed wrote: post #194

Earlier quoted context omitted.

Fast to develop with? Yes. Fast to run? Well.. no.. it's Python . I personally care much more about development speed and time to market/customer than execution speed. It's good enough for 99% of cases.

You're doing queries to a db, the fact that it's python is not your bottleneck

In that case it doesn't matter if the ORM is "slow".

Anyway, I disagree. Sometimes the conversion of raw data from the db to Python objects can be the bottleneck for a view. Of course, almost always when this happens it's not really a problem per se as the view is plenty fast enough.

Post reply on HN