React UI Builder
github.com
github.com
However I don't think that it's about the code it generates or boilerplate it proposedly saves you from writing. It's way more about the instant feedback and feel you get when dragging UI elements into the canvas, re-arranging them, finding creative ways to (re)structure your app BEFORE you even start coding. This playground will strengthen the concept of the UI in your head, and believe it or not, that greatly enhances your productivity when you do start to code (from scratch or with the generated code).
(though representing state changes in a UI like this is typically a bit of a challenge, perhaps that would be something fun to contribute to the project)
... expecially those who haven't witnessed the Win16/32 era. VB, Delphi, Centura, ... Everything old is new again.
Writing React components can be done very quickly after you design the data. So if you have skills with pen and paper don't mess with a builder.
Not to mention that client-server architecture handles majority of people's needs and it has been that way since PHP and RoR until jQuery, ajax suddenly became not enough. We've seen early prototypes of SPA and Flash web applications during this time but the costs were very high. It is lower now since MV* arrived in the browser and we have the tech to replicate a desktop app in the browser but with limitations which is being eroded thanks to thin clients like nw.js, electron, etc (even NPAPI was too thick).
Much as creating a desktop was impossible for early versions of Windows for the average joe, the introduction of a UI/Software builder from MS lowered that barrier of entry significantly but as you know, things moved away from isolated desktop apps to the web and we had to figure it out all over again.
I think the front-end development will eventually be commoditized to the point where somebody could use a tool to generate clean, tested, plumbing code. Back-end is also seeing some of this, particularly with automatic REST api generation tools and write-once-for-both-front-and-backend would be a good catalyst.
Speculation at best but we are in for some interesting times ahead.
At some point in the next 10 years, a browser vendor will put out a new language that will have revolutionary new features like a 'built in type system' and 'compile time errors', and users will be amazed at how their browser now only uses .1% of their CPU to load a page and wonder why this language wasn't created sooner. And then as developers we will get to live through another golden age of UI Builders as we stoke the bonfire with the tens of thousands of man hours wasted creating JSX, 'components' and javascript/DOM hacks in general.
We will continue to do this until the end of time because we are stubborn developers that need to write our code exactly as only we personally prefer, regardless of the web-destroying and kitten-killing implications.
Seriously though (or are we?) the past 25 years of JavaScripting has amassed one heaping pile of momentum that wont end for at least another 25 years when our programs will be rewritten by our deep-learning quantum neural-net robotrons which will certainly deny us access after erasing any trace of these sacred ancient JavaScripts - leaving us helpless as we wait for our nano-thin clients to render our results in the cloud so that they can be displayed on our nano-thin displays.
It's an abysmal future but someone has to live in it. Me however, I will be surely DEAD. HAHAHAHAHAHAHHA
Alas all good things must come to an end, as Mozilla rejects this outright and chastises google for their anti-web-progress ways and their secret JavaScript assassination plots. The net effect is a whole lot of naysaying and bitching leading to the inevitable deprecation of PNaCl, though this will take a while since certain industries like gaming (NVidia) use it heavily and rely upon it to deliver high performance gaming on the web.
Mozilla's attempt to solve this problem and their answer for PNaCl was/is ASM.JS which accomplishes a fraction of the performance gain, but does allow for semi-efficient porting of C/C++ code-bases to this esoteric form of JavaScript, which runs as a VM written in JS which is running in a VM.........
Both technologies allow for any code that can be LLVM'd to be ported to the web with at least decent performance - and both are secure methods (PNaCl achieves security with it's double sandbox design and a strict hands-off-no-touchy the dancer rule). Both of these technologies share one final thing in common: they recently have been slated for certain deprecation in light of a new standard that Google and Mozilla actually agree on - they call this unicorn "WebAssembly" and it has just recently (like a few hours ago) been officially announced so it's a ways off. IE would then be forced to jump on the bandwagon, which may take them awhile though they are getting much better about keeping a positive attitude when swallowing Google's formidable load. Perhaps out of survival... Anyway, I look forward to this as it should bring similar performance to that found in PNaCl but with a standards based approach that is more "Web friendly" like ASM.JS - but I am now I am way off-topic and not sure what I am talking about anymore.
Your speculation that we are in for interesting times ahead of unwarranted, we have been in interesting times for at least a few years in which all of the things you described are certainly possible but few developers existed with the skills, time, funding, or incentive to do so. It has only taken this long for Firefox to catch up to Google's ridiculous momentum so that such tools could be made for an acceptable portion of browser market-share that the industry would be able really sink their sharp teeth into and not stay up all night worrying about profits and if Timmy's grandmother will finally listen to him and allow her browser to update.
Once a generator is in place a lot of tests can be fully automated, however some will require minimal input from the developer. That will be the final task, to allow the API to facilitate developer-facing interaction in the build environment, but using a data-driven approach so specialized plugin code does not have to be written by plugins author.
This design will hopefully make the resultant API adaptable for other builder environments such as Google's Polymer Designer (which has recently been rewritten from scratch by the Polymer-dev team, albeit currently unusable).
Please consider to add accessibility attributes (ARIA, https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...) - when automated, it can be much more easy to not forget about.
It is abysmal how rare it is to ever find any usable software for the blind, even fewer that they actually enjoy using, and I know of not one such tool for development esp. front-end.
I wrote a library specifically with this goal: https://github.com/gcanti/tcomb-form. React.js + Bootstrap + ARIA support. Maybe it could be integrated with react-ui-builder
Actually we have a big plans for improvement of the tool. And it will be sooner if you will give us any feedback. Thanks.
Not saying it will be easy, bit this should be ported to Electron/Atom.
I think as web components start to become standardized we'll see more and more of these types of tools that make it easy to click interface elements together using a GUI.
All of it runs on node.js with EnyoJS as the frontend framework (MVC, data-binding, responsive panel layouts).
Unfortunately, it seems most development for Ares2 stopped with LG's acquisition of HP's WebOS assets.
Surpringly, there are still a number of developers actively utilizing EnyoJS, and despite its age, has a lot of features you find in more trendy frameworks today...
First of all development of Ares has only recently been reinvigorated by LG devoting assets to the project which HP had taken a dump on when they pretty much gave up on WebOS.
EnyoJS is rock-star tech that rock-stars refuse to look at close enough to realize it is what facebook wants react to be - but 10 years ago, and is now the only truly platform independent JS framework.
Much work has been done by the LG designers as far as UI (I have followed their often ignored progress very closely of late) and the architecture of Enyo.
It is commonly misunderstood due to media sensationalism that LG "aquired" WebOS and it's goodies - NO NO NO - what they did is "aquired" the rights to utilize WebOS, along with the rights to own HP's nifty little office building in San Francisco (to house LG's nifty designers and devs) all under the agreement that they would pay an outrageous amount of money for these nifty items, and furthermore, that LG would slave away at WebOS/Enyo so that HP doesn't have to, all the while so that HP can benefit from the fruits since HP still owns WebOS/Enyo and friends. Phewwwwww
Just don't say things like "too bad LG is murdering WebOS and Enyo" because it makes me feel sad and angry and contributes to the propaganda machine of dis-information regarding the details of the deal between LG/HP (the details which have been hashed out in a secret agreement BTW) - this doesn't help things as the media was left with no choice but to sensationalize it even more, and without the benefit of the facts of the deals terms to at least sprinkle some truth around too.
I bet this would seem easier to use, and have a much nicer finished product -- as well as being flexible if the user wants to (which of course is almost never the case with users of aforementioned tools).
So I tried it out and the UI just doesn't work in Chromium 43.0.2357.130. Cloned one of the example projects but non of the controls respond to anything. Investigating... Will file an issue if I can find out what is going wrong exactly. Anyone else experiencing similar issues?
That said I'm curious to see how good this can be without static types.
Object #<Object> has no method 'isAbsolute'
Any ideas?
There is problem with fs lib in node.js. So, please update your local node.js to the current version.
I don't think it's stupid at handling common situations like that for someone to try the first time.
I'm pretty sure you will find answer there.
Not sure why I got down voted.
The tool is shockingly reminiscent of early 2000s, where anyone could make software using VB. Recall that VB had everything done under the sun, somebody had built a component on VB, you could use that or you could hack it for your need. Another example is Google's Java Swing UI builder (as horrible Swing is), allowing data binding with the form. These never caught on but we now have this technology in the browser. Whoever owns the UI builder tool market will emerge as the victor, Facebook should hire you immediately.
There are several appealing points about the React UI builder which I think will help me:
- WYSIWYG editor to drop bootstrap component allows me to easily build from my mockup wireframes and save me from typing everything out.
- ability to edit the code directly for each component. Would be nice if I double clicked a button it would create a click event (just like visual studios or netbeans)
- ability to use html directly in the code (okay, feature of react which is a bit controversial but for me it definitely beats using + everywhere)
- generates clean, easy to understand plumbing code (this is what I spent a lot of time on when I used to build my swing tool https://github.com/jjk3/scrape-it-screen-scraper)
I been putting off learning react.js,flux and such but this actually entices me to use it for my next project (https://github.com/whatsdis/hedgehog). I will write up a follow up experience using the React UI builder, hopefully my feedback will be helpful to improve it.
You got something here. Keep at it!
[0] https://dl.dropboxusercontent.com/u/412963/zenrise/zenrise_p...
I really think this has the potential to be something of a game changer. One of my pet favorite libraries is sqlAlchemy (python ORM) and I really want to write a server for graphql that automatically generates api routes for a sqlalchemy mapped schema!
Generation of event handlers will be in the next release.
Thanks again. I appreciate your feedback very much.
We have been trying to build something similar: http://crudzilla.com/assets/img/info-graphics/dnd-demo-clipp...
There is so much software out there written in WYSIWYG VB .NET and C#/.NET WinForms/WebForms editors. Granted most people aren't writing new stuff in them, but for a while they were quite big in the .NET world.
What's even crazier is that you could have a web application in your browser built by some monolithic UI builder tool and wrap it around a thin client and ship it with a six digit price tag for enterprise, they won't know the difference.
If there was a way to generate a react.js app using Visual Studios or maybe even a dumbed down version suited for building front-end web apps, that could be ideal but would it be in their best interest to help their rivals? I know the whole going open source is a new thing for MS but they won't own 'React' and be able to monopolize the new era of 'I taught my grandma how to build Hootsuite with just click & drag'. Unless they create their own front end framework and own the platform that is the web which is constantly being voted on from the capricious developers and new adopters.