React UI Builder(github.com)
github.com
React UI Builder
https://github.com/ipselon/react-ui-builder
23 comments
Even more exciting to me is that if your interface fits into a declarative model that can be serialized you are probably maintaining a good separation between code and presentation.
(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)
(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)
> Some programmers may not immediately see the benefits of having such a UI builder
... expecially those who haven't witnessed the Win16/32 era. VB, Delphi, Centura, ... Everything old is new again.
... expecially those who haven't witnessed the Win16/32 era. VB, Delphi, Centura, ... Everything old is new again.
Yes and without going that far in time XAML, WPF or silverlight
Thank you for this comment...I was looking for a good reason to explore this further, and this is it. In addition, if you are just learning React, this might be a good tool to assist in your learning.
Yeah... I wouldn't touch this.
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.
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.
And over here in the native world we've had drag and drop ui builders for 20+ years. I can't believe how slowly the wheel is being re-invented (over and over and over again) in the web world... when will the DOM and JS die and real innovation starts happening again.
And there was also WebForms, but the less said about that, the better
Your lament is certainly warranted. It has taken two decades for the desktop to arrive in the browser. However, the journey has been a long one because our browsers has taken a long time to mature, and there are different players with different agendas.
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.
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.
The formula is: new operating-system/vm/browser > new programming language > new libraries > new ui builder :). Choose any one and re-create everything that comes after. Rinse and repeat en-millennium.
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.
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.
Nah, we will just continue to make more and more meta-compilers for our meta-languages so that they can inevitably become JavaScript just the same.
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
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
When you say NPAPI (now deprecated) you refer to a very wide spectrum of API's for very different problems. One such API under the NPAPI umbrella is NaCl/PNaCl which attempts to solve the problem of performance by allowing developers to use existing native C/C++ code by compiling it to a portable bytecode format based on LLVM, this is compiled ahead of time, achieving the same performance as traditional native execution in C/C++ (something that has be packing a boner 24/7). This code can be compiled to run on any platform in the case of PNaCl (NaCl is on it's way out anyway) and suffers a nominal performance penalty that is only felt up-front, not during execution.
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.
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.
This is great. One big reason that I'm so excited to see more tools like this is that they have the potential to make unit testing less annoying. Build your component and take snapshots of it in different states with different props. Convert that to a Jasmine (or something) spec automatically. This would take care of 90% of the UI unit tests that I write.
I plan to add an agnostic generator for code-coverage that can be easily extended to allow generators for a given testing toolkit. I will adapt it as necessary to facilitate unforeseen/esoteric features as new testers get added, but the idea is to make a utility API that generalizes the process of defining contexts and templates for their associated testing code for the generator to use. I plan to support TDD and BDD based systems, and isomorphic module designs.
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).
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).
This is a great idea.
Huge work. Will be very interesting for business users. They often need to build forms quickly and a lot of them.
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.
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.
I intend to not only add WAI-ARAI conformance but even better, to merge the work of this project: http://khan.github.io/tota11y/ into the builder itself, so that the developer can benefit from moment to moment conformance feedback as the application is built - instead of the typical process a developer goes through when he builds a successful application and quickly finds out as an afterthought that these things are not only important, but often necessary. If I ever get around to it I want to go the extra miracle mile and allow for an /actually/ usable voice guided process of building software so that blind users can finally leverage their largely underrated skills in abstraction.
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.
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.
> They often need to build forms quickly and a lot of them
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
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
Have had a huge hankering to build something like this for a while. Excited to try this out!
Came here to make this same comment! I've always thought something that combined react with a sweet wysiwyg gui would be the most awesome and powerful tool.
Stay in touch guys. Next thing we are going to roll is a fast CSS editing - convenient way to edit CSS for component on the page.
Actually we have a big plans for improvement of the tool. And it will be sooner if you will give us any feedback. Thanks.
Actually we have a big plans for improvement of the tool. And it will be sooner if you will give us any feedback. Thanks.
Hey @ipselon - I'd love to get in touch and chat about this. I can't find your email in your HN profile; any chance you can contact me via vlad [at] webflow [dot] com? Thanks!
I added my email, please find it in profile.
Having Delphi background (5 years) in another life, and using React for the past year, I was waiting for something like this any day now. Looks really nice.
Not saying it will be easy, bit this should be ported to Electron/Atom.
Not saying it will be easy, bit this should be ported to Electron/Atom.
This would be as easy as a easy peaze of Cake. Even easier to bring it to the MUCH MORE SUPERIRIOR NW.JS. Then it would be to react what Intel XDK is to Cordova/Phonegap. And what that greek god guy is to EnyoJS and/or WebOS.
Something like this has existed for Polymer.js for a while now called Polymer Designer - https://polymer-designer.appspot.com/
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.
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.
Been wondering when someone would do this. How the community rallies around it rather than relying on the maintainer doing all the work, assuming it's of high quality. Looking forward to giving a try!
This thread would be remiss without mentioning the EnyoJS UI builder, Ares2, which has a similar feature set, but also allowed for Dropbox storage (work on your apps anywhere) and Cordova builds from the UI.
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...
https://github.com/enyojs/ares-project
http://enyojs.com/
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...
https://github.com/enyojs/ares-project
http://enyojs.com/
Absolutely positutly FALSE.
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.
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.
The new version of React-UI-Builder is now available! Quick CSS editing panel was added - convenient way to change component's style. Now it's a time to write some tutorials and documentation, any help will be really useful for our team! Thanks everyone for interest!
I would love to see a side-by-side of this and those awful "website builder" tools that domain/hosting providers churn out.
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).
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).
They aren't all bad, have you seen webflow.com? They've created a pretty good darn UI builder, responsive design as well. Doesn't use React though I think.
This this really rad man! I love it.
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?
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?
Who doesn't want to install react-ui-builder locally I made on-line demo version. However, demo doesn't allow use it full cycle development.
http://umyproto.com/react-ui-builder/
http://umyproto.com/react-ui-builder/
This is pretty interesting, I was waiting for something similar to this to happen that looked like Interface Builder in XCode.
That said I'm curious to see how good this can be without static types.
That said I'm curious to see how good this can be without static types.
Wow, this looks very interesting. With the upcoming releases of Relay and GraphQL, it would be a great addition to be able to specify what data the components need as well.
[deleted]
How to clone project?
Whenever value i input in the "Local directory path", it always say: {"errno":-2, "code: "ENOENT", path: ""}
I don't think it's stupid at handling common situations like that for someone to try the first time.
I don't think it's stupid at handling common situations like that for someone to try the first time.
Please read posts here https://groups.google.com/forum/#!forum/react-ui-builder
I'm pretty sure you will find answer there.
I'm pretty sure you will find answer there.
I think the issue is permissions. Since the browser is creating and writing to files. I was having this problem and changing the permissions on the target directory to 777 fixed the problem.
Yes, and more obviously, the project directory needs to exist.
You should file an issue on the GitHub repo. That way you're assured the author/contributors will see it :)
It even create reflux stores and actions. Like +1
[deleted]
So this requires bootstrap? :(
It has the concept of boilerplate projects that you can start from. Right now, its bootstrap or material or a blank canvas.. But there is nothing preventing you from creating a new boilerplate project for foundation or semantic-ui if you choose to ( and he is asking us to basically contribute such boilerplate projects ).
Ahhh that's really cool! Thanks for clearing that up.
Not sure why I got down voted.
Not sure why I got down voted.
This has huge potential. I just saw the tutorial video and super excited. I don't know why I didn't think of this before, this could be the 'missing' piece of the front-end application puzzle. What I mean by that is that there are so much fragmentation in this landscape and a tool like this could eventually consolidate all the heterogeneous attempts by forcing others to adopt the same UI builder, and compete on that front.
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!
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!
Yeah, same here - I was exploring this area last year in a few different ways [0]. I think it was still early then, but with GraphQL, DataScript, React Native, etc. I think we're really getting close to some very, very powerful tools for UI. A lot of the backend can be removed, and focus can go into the frontend (to some extent, obviously).
[0] https://dl.dropboxusercontent.com/u/412963/zenrise/zenrise_p...
[0] https://dl.dropboxusercontent.com/u/412963/zenrise/zenrise_p...
I'm so excited with the technology coming out of facebook right now, imo it's the best possible way they can attract new developers. I can't wait for react native to come out for android so I can start playing with it!
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!
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!
Something similar (in terms of interface) https://vimeo.com/128038818
https://vimeo.com/128038770
There are a lot of such tools which allow to create a layout of your pages. In case of builder you should consider page as a desk for combining components into some composition which you will reuse as a component itself.
So, there is very small similarity - only because you can copy/paste/delete some components.
Your tool looks awesome! Yes there are lots of such tools.I should have worded mine as 'something along the lines of ...' instead of saying that its similar.
Hi, thanks for this awesome feedback !!!
Generation of event handlers will be in the next release.
Thanks again. I appreciate your feedback very much.
Generation of event handlers will be in the next release.
Thanks again. I appreciate your feedback very much.
Not a problem, event handlers would be great, very much looking forward to it. If you can email me (click my profile) I'll be happy to send you more feedbacks once I start diving into it.
Absolutely agree. I think the future of web application development is going to be based on tools like this, something beyond text coding. It has to be done right and I think the under laying technology is finally there to make it possible without becoming another dreamweaver.
We have been trying to build something similar: http://crudzilla.com/assets/img/info-graphics/dnd-demo-clipp...
We have been trying to build something similar: http://crudzilla.com/assets/img/info-graphics/dnd-demo-clipp...
>These never caught on
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.
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.
On the native desktop side yes (btw qt is underrated) it's very mature, and I think people were just too busy with building stuff for the web (at least from a non .NET developer).
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.
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.
Have you come across react.net ?
Yeah, I'm surprised the developer hasn't been fending off Facebook yet.
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).