Table and Query Classes good or unnecessary?
On Mon, Mar 12, 2018 at 9:24 PM, Bastiaan Olij <email@example.com>
> Hey Reg,
> There is a long list of things I wouldn’t mind seeing in the front end.
> Better layout controls, controls that are more customizable, proper
> fieldstyles that can be combined, better control over look n feel
> changes on things like mouse over, better drag and drop support, etc.
> We’re undecided on the middle tier and last time I took a serious look
> was over a year ago, other things had a higher priority. I will likely
> start looking into things again and see how they have changed.
> At the time hot contenders were Node, Ruby and Python, that may change
> once I revisit it.
> In a nutshell, Node seems to have a really good setup for doing restful
> type stuff. With both Ruby and Python the focus seems to have been (at
> the time at least) to create full fledged webservers.
> Ruby I really like as a language and I like its structure, it felt like
> an environment to build things in quickly. It was definitely the one
> that I picked up the quickest. But its bloated.
> Python is probably the most likely candidate at this time, loads and
> loads of libraries out there to use, there are a few things about the
> language I don’t like (I just can’t get over the indentation, contrary
> to what they say I find the code harder to read, not easier, but I’ve
> gotten used to it) but for the most part it’s an impressive environment.
Python isn’t really one language. You can think of it like the Omnis
Classic and Studio divide. Classic was so good and Studio so flawed when it
first shipped that it took a long time for Studio to get established. I’ve
been using Python since the 1.5x days and the changes from 1.5 to 2.7 have
been evolutionary and for the better. The transition was relatively smooth.
Python 3 had some breaking changes so it took a long time for the vast
number of Python 2x modules to be ported so the transition to Python 3 took
a long time. Django 2x is Python 3 only. Given how influential Django is in
the Python world, that’s a big deal.
> But again, I don’t know what has changed over the year, there are a few
> more options now that might be interesting.
Django 2 deserves a second and a third look. It’s a mature, full-featured
framework with which you can build RESTful applications very quickly.
Supply the db credentials to Django, point Django’s ORM at your PostgreSQL
db, run “inspectdb”, and it will generate the Python classes corresponding
to your database objects. Use Django Rest Framework (DRF) and you’ll have a
REST API up pretty quickly. It’s all well-documented and mature.
I used Django 1.11 and Django Channels to have a way of doing WebSockets
and HTML from the same software stack for the the virtual machine
configuration application on the project I’ve been working on. That’s
running on Python 2.7x. With Django 2, one application server can deal with
whatever protocol you throw at it, HTML, Websockets, or something else and
you can use the asynchronous programming constructs that have been in
Python since 3.5. Python 3.6 also provides for type hints so if you don’t
like dynamic typing, you can now provide type hints for variables.
I’ve been playing with Dart <www.dartlang.org/> and I’m especially
impressed with Flutter <flutter.io/>. Dart is a simple language to
language, tooling, and the community. Flutter enables one to build native
apps for both iOS and Android using the same base. The closest competitor
would be React Native. Ionic and such aren’t even close because they’re
still relying on Webview, not the native canvas. Dart makes asynchronous
Go is also pretty easy to learn and it’s great for building RESTful
middle-tier apps. Again, it’s highly performant for asynchronous
programming. (You might be seeing a trend here.)
In the Node.js world, I really like the Feathers <feathersjs.com/>
framework. It’s optimized for building real-time and reactive applications.
I like how it’s agnostic about what you use for the frontend – Feathers
client, jQuery, Angular, React, Vue, whatever. If you want to build your
frontend in Omnis, you can since there is no rule that says you have to use
Feathers to build a frontend. It’s perfectly happy being a RESTful or
GraphQL server. I also like how it’s agnostic about the database backend –
SQL, NoSQL, even plaintext files on the filesystem that store JSON (NeDB).
I have a love/hate relationship with Node.js. I love how performant it is
and how innovative the community is. I am not a fan of the complexity of
the build toolchain. For an interpreted language, we sure put an awful lot
of effort into the build process. I understand the reasons for that but
there are times when I marvel at the craziness of a build process that is
as complex as any compiled language. For instance, we write TypeScript for
our AngularJS frontend. Browsers know nothing about TypeScript. They know
about ECMAscript and at that, ECMAscript 5. We have to transpile that TS
into ES5. Not only do we want to do that but we want to bundle and minify
the resulting ES5 code and we want to do tree-shaking on all that code to
only include modules we absolutely need and nothing else.