61–70 of 126 posts
Earlier quoted context omitted.
I like Jinja. What's a Python templating language you prefer to it?
Randomly chiming in here, but now that I've used Hiccup (in Clojure) for a few years, nothing else seems evenly remotely pleasant to use. Especially when it's hooked up to a good IDE for super-easy key bindings (emacs + paredit for me).
Earlier quoted context omitted.
JSX is kinda nice, once you get used to it. Primarily because it's just HTML and/or your custom components, with arbitrary code execution in { } blocks.
Apples and oranges. (Or fruits and oranges?) JSX can only do XML; Jinja is for arbitrary text.
The primary restriction is that your output can be modelled as a tree in some way, and what you find is that nearly everything falls into this category. I don't know if anyone's done it yet, but a plain-text renderer is certainly possible, I imagine it would be very similar to a terminal renderer.
So far isomorphic Node + React has been the best (but not perfect) way I've seen to do this. You abstract out the API layer, and now you can define components and their data sources that have the exact same code on the client and server, and it just works. Apollo/GraphQL is probably a giant leap forward in this as well.
Having an option to do hand-glued "isomorphic" data in a few places is probably nicer than Javascript spaghetti on the front end, but it doesn't get you all the way there. Rails has the same problem by the way, the "Rails way" is coffeescript glue to get any kind of modern front end application functionality. Even with React on Rails you have to have to reinvent data fetching, and lose the benefit of a well structured isomorphic codebase.
Until browsers support a different language natively other than Javascript (which will never happen), Node + React is currently the most straightforward path to get there.
Ugh. After living in frontend land (native mobile and react) I'm really not looking forward to going back to Django. It feels so irrelevant in the world of backend-as-a-service and GraphQL. ...Please forgive my cynicism. I am looking for a reason to like this. Maybe I should just move on.
That's fair. What got me thinking about these ideas were cases where having a distributed frontend felt overengineered. If you have problems where GraphQL makes sense, this would be a step in the wrong direction.
I usually ignore server side rendering or isomorphic rendering. I'm not saying all projects should ignore it but you're really talking about a high level of optimization if you need it. And if you're reaching that level of optimization you probably shouldn't use Python. Server side rendering only makes the first view faster. After that, everything is rendered on the client and faster that way. And if you use caching…
Earlier quoted context omitted.
From that description it sounds nightmarish.
That "arbitrary code execution" is functional viewmodel stuff. It makes complete sense once you've spent more than an hour with it. (This is also why "templating languages" in PHP were a special kind of foolish; PHP is a templating language.)
Any PHP project of any reasonable complexity will either use an existing "templating language" (by which you probably mean a framework) or be forced to create some sloppy, ad-hoc version of one, because while yes, PHP is a templating language/framework, it's also a terrible one.
I usually ignore server side rendering or isomorphic rendering. I'm not saying all projects should ignore it but you're really talking about a high level of optimization if you need it. And if you're reaching that level of optimization you probably shouldn't use Python. Server side rendering only makes the first view faster. After that, everything is rendered on the client and faster that way. And if you use caching…
If you're writing a SPA, server side rendering is probably the most important optimization you can make to speed up your application. No other optimization will come close to the benefits of server rendering. SPAs are both slow and perceived as slow. True SPAs are only appropriate for a subset of the web where you have very specific user constraints.
"Only the Sith deal in absolutes", Obi-Wan Kenobi
I was wondering if we should not code a Python renderer for one JS framework and be done with it. We already have one JS engine in Python ( https://github.com/kovidgoyal/dukpy ). We even have pluggable renderers ( https://pypi.python.org/pypi/PyExecJS ). Later we will have webassembly renderers in Python, so you will be able to take frontend frameworks, compile them and execute them in Python. Finally, we have some f…
Write a react clone in Python (complete with "pyx" files), and then use one of the python to js transpilers to compile to js on the frontend. On the backend, you'd use "react" just as another simple template language, whereas on the frontend, you'd also have the reconcilation algorithm.
Templates cause bugs. The solitary appropriate solution is an unparser – a component that walks an AST and serializes it. Making sure the result conforms to the grammar of the output language without any unparser would always involve a parser. > As soon as I'm looking at more than one programming or markup language in the same file, I'm looking at spaghetti code. Iain Dooley, December 2011 http://www.workingsoftware.…
> you simply include everything in the markup that might need to be there, and the programmer removes whatever is not necessary I realize you may not be cosigning on everything in the article you're quoting, but this is the author's first suggestion to an alternative to template languages. I work on an SPA that was built like this. The index.html is over 10k lines long. It contains almost every single piece of the UI…
I think SPAs are either fundamentally dishonest engineering, in the same way that a microwave wrapped in artificial wood veneer is (and a stainless steel microwave is not) or should result in such a template. If you really think that this is too much, IMO you should not make an SPA in the first place.
Ugh, Jinja is not an "excellent" templating language. It's a terrible broken mix of pythonisms and arbitrary-feeling restrictions and oddly missing pieces. It becomes hard to read very quickly and some of the looping idioms are just nuts. Sorry I don't have anything constructive to say here but I'm genuinely taken aback that there are apparently big fans of Jinja.
I like Jinja. What's a Python templating language you prefer to it?