I'm still desperately trying to find something I can throw on top of an RoR application which is a crud app that is used by less than 20 users that handles the view easily. Or even if I could scrap that and hand over my decently large postgres database. (Not sure how it would be able to carry over the schema.rb or the model to retain relationships).
But, ideally I would say here is this database. Let users be able to easily add and update it and search/sort quickly.
I feel react is built to do things like this quite fast. Seen some great examples of autofill and sorted/filtered massive tables within a brilliant UI. Having the ability to work on independently on components also seems like a huge benefit but all solutions seem rather frankenstein-ish.
Maybe I suck. I wish I could find someone to pay that could take the database (or a grouping of csvs) and set up what I'm looking for. Sadly I've tried and the best solution has been hacking together on my own something that "works" but it's not great.
This is why I keep being attracted to these scaffolds hoping one will "click."
If you're willing to give up on client-side apps (and deal with a Microsoft stack), MVC5+EF+server-side-kendo can be magical (you'll need to customize EF's TT file so that it scaffolds a grid for each type, and produces MVC validation attributes for the create/edit pages), then just scaffold DB-first, tie it into an auth DB for logins, build your layout, menu and theme. It won't be pretty. It won't be React. It will work.
It's close but I have custom "notes" that have fields as well. I've looked at this and have disabled the comments per config but I almost have to gut it to add another component below the information of an entry.
Could I just setup my db and then hook it up to Django's admin? Right now I'm trying to basically do a restructure of a database by having a set of csvs (4 sets of files or 4 "tables" bigger than excel can open but I use bash to pull the columns and sample data) and wrote some scripts to import them into postgres.
I haven't, this looks kinda neat though. The biggest "feature" needed is ability to work with a lot of data on the grid and filter every which way possible easily + exporting/importing csvs.
CxJS grid supports buffered rendering for displaying large collections when records are available on the client side. Infinite scrolling can be used to browse data coming from APIs that support pagination.
Filtering and csv import/export are not built in, but that should be in the application code anyway.
I don't really get who stuff like this is aimed at. Either you know no code so this works for the first 40% of the stuff you need and then you just need to program the really unique and incredibly hard stuff. Or you already know code and you end up wrestling whatever comes out of this into a form that you can actually support going forward.
Tools like (i.e. WYSIWYG editing suites) this have a yield point of usefulness and I am not sure open source can get there. There are very few exceptions (Gimp and Audacity spring to mind).
You forget the interactive nature of WYSIWYG editors- if you have tooling enough to throw together a UI in front of a group of people as part of requirements gathering and just 'do you like how this looks' it can be very powerful- especially when you can show up a few hours later and have the broad strokes mostly working. It is also a natural design constraint- if it is not easy to do with a the generator it's probably going to require to do extra work so you can give a near equivalent that is less expensive but easier to do.
Without WYSIWYG and current web dev you can bring it to a whiteboard and hash out a design and then find out that for some reason that it is really annoying to make work well on everything you need to support. It's really the consensus driver that makes WYSIWYG always a very helpful tool.
It's as if web developers think the web is cutting edge in everything, and there can't possibly exist better tooling for some things on other platforms, particularly older ones.
Having a universal platform with several competing implementations ported to multiple hardware and operating systems, easy deployment, and a standardized user interface model with very high configurability, resolution independent, allowing end-user tweaks to presentation, and responsive resizing of the user interface?
No, I haven't, and I was developing before the web existed. I don't doubt there may be much better tools for some things outside the web, but none for a platform with all those features.
All those tools are very useful, but they rely on needing a standardized UI. The problem with most web-based projects is that everyone wants to customize them, and once you start doing that those kinds of tools just aren't as useful.
I think that is a good point. However wouldn't Bootstrap be an example of a standardized web UI? There are also Bootstrap implementations which use React, and Bootstrap 4 is significantly easier to customize by writing a small amount of SASS. I can easily imagine a UI builder that is as good as the desktop tools which uses Bootstrap 4 and React as its base.
Sure, there have been several implementations of this idea on the front-end. Sproutcore was working towards a UI builder at one point for example, and extjs has one as well since both of those use a standardized layout engine.
Wix, Wordpress and Drupal all have layout builders. But they're mostly geared toward designers or admins, and thus separated from the code.
And then once upon a time, there was Dreamweaver, which nobody mentions. There is also Adobe Edge. I've watched a designer put together a nice looking website very quickly in Edge. I've also seen what they could do with the WP theme builders.
But then you still need someone to tweak the css, and add JS for custom stuff separate from the builder.
You couldn't wire up application logic with Dreamweaver though could you? I never used it that deeply so I only remember it being good for creating web pages, not applications.
Qt Designer for instance is extremely useful to quickly put together an interface and even connect it to code via signals and slots. It generally pays off to go as far as possible purely using Qt Designer and add GUI code only when needed. If a similar tool could be created for React that would be great, but yes it might be hard for a one man project to get to this point of usefulness.
I have been waiting something like this for the last 20 years. We had a WYSIWYG editor in Visual Basic and Delphi, but procedural languages are not adequate to build the logic of the presentation layer.
The hope is that using Reactive programming, you won't need to wrestle what comes out of the tool, since the underlying language and programming model is finally capable of truly supporting components without lots of glue code, boilerplate and exceptions.
I agree that a reactive paradigm is key to unlocking a powerful WYSIWYG view-layer. In fact, I'd argue this has been proven with the visual design tools available for Verilog/VHDL. Hardware is as 'reactive' as it gets.
You may be interested in what my team is building: https://haiku.ai
Haiku is a UI-builder modeled after Flash, FPGA design tools, VB, Qt, even a dash of HyperCard and Unity. We've sought to 'invent' as little as possible, while adapting proven solutions to the many quirks and challenges of the Web.
If you're curious at all, I encourage you to join our beta list and shoot me an email for access: zack@haiku.ai
There is also Smalltalk Pharo, but I don't know how good it is as a UI builder. Still, you have the idea of a programming language environment inside a GUI where everything is a customizable, live object that talks to other objects.
Flash wasn't a bad technology per se (security issues in the plugin aside). It was just annoying, in the same way HTML5/JS is now annoying. When people want to do user-hostile things they will do user-hostile things, no matter what technology stack is popular.
Right, Flex GUI Builder which first release was midways through 2000's... People really like to snark at technology but just don't give enough credit at how much water has run under the bridge...
That doesn't look like what I was talking about. He basically has an entire new component for every possible state - and his state is just a single variable.
That seems very wasteful if what you want to do is just to show a bunch of extra controls if a small part of the state changes.
Later when he works with bindings, that's closer, but the expression still had to be written in as code, so no win there. Plus it's classic data-binding, where it can only affect pre-defined properties (usually of primitive types), but not the entire structure of the component.
> That doesn't look like what I was talking about. He basically has an entire new component for every possible state - and the state here is just a single variable.
With reactive programming being primarily functional, it should be relatively easy to refactor the output of a tool like this. You could split the states into its common components, maybe even using visual tools in the designer itself without having to touch the generated code.
I don't know if this tool will be able to do that, but I've seen that approach used in mockup tools for rapid prototyping. The only part missing in those tools to allow the interface designer to build the interaction logic by themselves was a sane code generator. With a language like React, I believe the generated code will resemble something usable, which was impossible when UI designers generated imperative or object-oriented code.
Delphi, VB and C++ Builder surely are, and we could do a full application just by dragging components and setting properties, without a single line of code.
well, the ide is more recent, but Qt was released in 1993 or something like this and the core concept did not change that much since then, it has just manifested itself in a simpler language than C++ with qml / qtquick.
The declarative QML makes all the difference when building a user interface programmatically. You could create interfaces in Qt in the nineties, but you couldn't create mockups of the different states and integrate them without writing the supporting code for those states by hand.
But you have to specify how the UI looks in code, as opposed to having RAD tools to work with your code. If you don't like 90s comparisons, how about Unity?
True, you would need a drag-and-drop tool for essentially editing functions (with `if`, `forEach` objects) in order to achieve this with React (well, if you had that, you would have achieved a lot more than the old-school UI tools did).
I wonder if drag-and-drop tools really provide that much value compared to just editing a component with instant live-preview on the side.
Obviously, you don't need to know how to code, but many designers know at least HTML/CSS. You could have some nice basic DSL, plus a good set of layout components that hide the CSS ugliness in this area.
The "code" you would need to write would be little more than JSX with some basic `if`s and `forEach`es, because you are only writing the render function.
The props and state could then be manipulated inside the tool to see all the possible variations (you could even add new props/state fields if you need them, and then export this structure as TypeScript interfaces). You would have a list of components on the side, like the tool in the OP does, to help with discovery.
> I wonder if drag-and-drop tools really provide that much value compared to just editing a component with instant live-preview on the side.
The idea is to have both. Finally this is possible thanks to reactive programming.
UI designers make mockup tools that basically support that kind of rule-making with drag and drop, but that logic cannot be exported to the development environment, only the visual components.
With a tool like the one in the article, this will be possible, and UI designers will be able to create the basic user interactions by themselves in the prototyping tool, rather than having to write them down in English in a specification document for developers to re-write them in a proper language.
>With a tool like the one in the article, this will be possible, and UI designers will be able to create the basic user interactions by themselves
I'm not sure if it's a good idea to allow actual interactions (`setState`, etc.) to be handled by a tool like this. The whole idea of such a tool is that you can develop components relatively in isolation, without having to mess with the application code.
When doing just the look of a component as a pure function (just the render function and nothing else), that can be achieved, but as soon as you allow the design to have side-effects, that isolation is gone.
> I'm not sure if it's a good idea to allow actual interactions (`setState`, etc.) to be handled by a tool like this. The whole idea of such a tool is that you can develop components relatively in isolation, without having to mess with the application code.
A UI designer should be able to develop the interactions over a single component isolated. For example they could define a "Send form" event and tie it to the button and the "Enter" keypress all from the visual designer, just like you would do it in code.
In reactive programming, the effects of each interaction don't need to be represented as side-effects, but as output of events over a functional and composable "stream". UI designers can learn to think in that programming model, which is way saner than callback hell.
The problem is that in order to play with the mockups and test them, you could create interactions that work with the expected happy path, but are not what the final application logic is supposed to be.
For example, you have an action that will ask some remote server whether the user has a permission to do something, and if it receives a positive response, it performs that action and only then updates the UI (and shows the error UI if the user doesn't have the permission).
With a tool like this, you could easily create an interaction that updates the UI immediately. It would look correct, but it would be wrong.
>For example they could define a "Send form" event and tie it to the button and the "Enter" keypress all from the visual designer, just like you would do it in code.
That's fine, but I don't count that as an interaction. In React, you would just define that as a prop and pass it to the buttons and the keypress event, so that would be ok. `setState` would not be ok (unless it only stays in the mockup and is not exported).
> With a tool like this, you could easily create an interaction that updates the UI immediately. It would look correct, but it would be wrong.
Why couldn't you just go into the code and specify the error UI? You still have JS/React available to you at any point. The GUI tool is just to aid with rapidly building stuff, not as a replacement. We're not talking about a visual programming language here.
And if handling error cases is expected, then the tool could provide an option for specifying error UIs.
> Why couldn't you just go into the code and specify the error UI?
Because usability professionals typically don't know how to code.
> The GUI tool is just to aid with rapidly building stuff, not as a replacement.
My point in this thread is that, with a tool like this, it could be.
I said elsewhere that mockup tools used by UI designers already have a development environment very close to this one, and only a good code generator is missing.
A mockup environment which can communicate logic to the devs, and not just visuals, is everything these professionals need to create specifications fully in software without resorting to natural language that the developer needs to interpret.
> The problem is that in order to play with the mockups and test them, you could create interactions that work with the expected happy path, but are not what the final application logic is supposed to be.
> With a tool like this, you could easily create an interaction that updates the UI immediately. It would look correct, but it would be wrong.
This also happens if you build the component in code, no? I fail to see how this is specific to a visual tool. A professional should take care of all cases, regarding of the medium of the tool.
> That's fine, but I don't count that as an interaction.
That was just the simplest example I came up with in ten seconds. For more complex examples of what interactions you can build purely with a visual tool that then spits code, see Apparatus [1] or Stop drawing dead fish. [2]
I can imagine building components easily in an environment like that. We already could do that in the Flash/ActionScript environment in a limited fashion, but the results were very limited (state could only be represented as a video timeline), and the platform itself was terrible.
>This also happens if you build the component in code, no? I fail to see how this is specific to a visual tool. A professional should take care of all cases, regarding of the medium of the tool.
If you want to do it correctly in the tool and tie the UI update to the "permission granted" response, that event (or part of a store, or however it's implemented) already has to be defined in code (even if it's just a stub) by the time you're making the UI.
So again, this breaks the isolation because the component in the tool now has to know about this.
In contrast, if you're writing the component in code, and find something missing, you can just go "oh, guess I'll just add that to the appropriate place".
I can imagine the tool exporting some kind of interface with a list of things it needs (project-wide, across different components), that the developers would then implement, but with that we're getting pretty far from existing real-world React patterns. It's also starting to approach the difficulty of just learning to code in the first place.
> That event (or part of a store, or however it's implemented) already has to be defined in code (even if it's just a stub) by the time you're making the UI.
That's a good point. A visual tool for building components will need a testing feature that can keep all those stubs. But isn't that just like Test-Driven Development?
> It's also starting to approach the difficulty of just learning to code in the first place.
Not at all.
In any design, you'll have to think about all the cases thoroughly and systematically; and any rational people can do that. But coding in a general purpose language has the additional requirement of having a mental model of the execution platform and conveying precise instructions; it's not enough to think in terms of the problem being solved. That makes all the difference to people without coding experience.
The syntax of programming languages is particularly tricky and difficult to learn. The people working with Chris Granger, the designer of Light Table, found that users of visual development tools find it incredibly difficult to understand scope. And coding in any modern general PL is all about scope.
You may think of this kind of visual environment as a particular Domain Specific Language. The users are coding in it, but the programming language is not general purpose, which makes it not "coding" as developers understand it.
> I can imagine the tool exporting some kind of interface with a list of things it needs (project-wide, across different components), that the developers would then implement
BTW, the mockup tools I'm talking about already offer that kind of interfaces to define the list of coding requirements generated by the user interface prototype. They cough up that list of requirements as a Word document or web page, though. Wouldn't it be best to generate those as placeholders in code?
The `render()` function describes the look of the UI.
With "traditional" libraries, you either have to imperatively mutate the initial UI (e.g. `button.setText`, `layout.addWidget(new Button)`, `removeWidget(button2)`) or use data-bindings which are pretty limited and you often have to adapt your data for them.
With React, you write the `render()` function that answers the question "given this state, how does the UI look?".
With Turbo Pascal's widget system you could describe the UI with a data structure from functions (not just the initial state), and it would bind those UI structures to a database (depending on the application). I'll admit, it's not the default way people generally built applications, built, but it could be done.
For example: In Qt you can bind signals and slots in the form editor declaratively. This way when a widget signals text change, another widget's set text is automatically called.
But, ideally I would say here is this database. Let users be able to easily add and update it and search/sort quickly.
I feel react is built to do things like this quite fast. Seen some great examples of autofill and sorted/filtered massive tables within a brilliant UI. Having the ability to work on independently on components also seems like a huge benefit but all solutions seem rather frankenstein-ish.
Maybe I suck. I wish I could find someone to pay that could take the database (or a grouping of csvs) and set up what I'm looking for. Sadly I've tried and the best solution has been hacking together on my own something that "works" but it's not great.
This is why I keep being attracted to these scaffolds hoping one will "click."