Perhaps. The end result of simplifying a task is always the same: "oh but I want to check the value of this field on the page", "can I check the local time to do this", "how do I respond to mouse movements", etc. Real programming can't be abstracted into DSLs in abused HTML elements.
The target audience of uilang should never, in my opinion, try to build websites.
even if agreed with your point i think we can agree it's more the execution is what's stupid- not the idea. not to say i think either is stupid.
the idea is that JS, and probably HTML/CSS by extension, are not the ideal tools for rapid prototyping, and this is a small step in the right direction.
>> The target audience of uilang should never, in my opinion, try to build websites.
why not?? everyone should, in my opinion, be able to build websites.
So who is the target audience? How many web designers are capable of writing the HTML and CSS necessary to create animated tabs, accordions and overlays, but can't figure out the few lines of JavaScript/jQuery necessary to toggle classes on elements? I've never met a single person who would fit that description.
All of the examples are basically differently-styled variations of "clicking on X adds/removes class Y on element Z". Is this all it can do? Would have liked to see some slightly more varied use cases.
I was thinking the same. From the few examples given, it seems to be only useful to toggling classes from click events. Would like to see some more use cases.
"Does uilang support other events? No, uilang lets you only react to clicks. Hover effects can usually be achieved in CSS and other events are simply out of the scope of this language."
I guess if you only need support for adding/removing/toggling classes, and you have no plans of using jQuery, this could be useful. It's 1kb of Javascript, compared to jQuery, which is over 80kb minified. Now, everyone and their dog likely has jQuery cached from a CDN, but it's a good way to reduce unnecessary bloat. If they added one or two common features from jQuery, and used a normal syntax instead of this written non-sense, I could see some people using it as a light version of jQuery.
I like this a lot. Your points about getting your hands just dirty enough resonates with me. Yes, I happen to know how to do things with jQuery till everything is a (really) complicated mess (aka a single page app). If I don't have to write jQ and JS code myself at the beginning, I probably won't succumb to featuritis and can concentrate on the bigger picture, like testing how content and interactions could work.
Now somebody just needs to support for CSS. I wan't to say:
* a boxy thing roughly the size of 25% of browser window
* a list of things with random paragraphs
* a draggable
* a receptacle for draggable things
* when this receptacle receives this draggable this happens
* this is a top bar, this is a sidebar and they should stay put
* this is content area, all to other things go there
Yes, I know I can just use Bootstrap or whatnot, but then I'm down the rabbit hole tweaking this and that, because I have a direct control of everything, yet a measure of nothing.
I think this is a solution to a problem that doesn't exist.
That's not to say it's not a great bit of effort, but I can't think of anybody that has a job to build widgets like on the demo page, yet cannot build them via pure CSS2/3 or JQuery.
I'm no designer, but i'd find it easier using CSS examples I find off the web combined with the information-glue that is StackOverflow, if something goes wrong with UILang, I'm on my own.
Maybe if "you're no designer" you're not the target audience? There are definitely a wide variety of other ways to do this, but extending a designer's knowledge of CSS to include minimal interactions is a nice way of leveraging existing know-how. jQuery is a bit of a mess conceptually, outside the core.
But designers use google too and they look an pages where developers or other designer are.
And on this pages you find tons of solutions and howtos, it is not so complicated to understand simple animations and events.
This is a neat extension of CSS to allow designers to create simple interactions. I like it as a mechanism targeted slowly at that use case, and I like it even more for determinedly limiting itself to solving that use case well.
The same design taste is evident in the project webpage itself.
I really like this. I think its an interesting approach to a problem designers have.
I personally teach all of our designers enough jQuery so they can animate their designs. The issue is its a steep learning curve and to be honest the Javascript is normally throw away as once we come to build the interface we normally use a framework like Ember or Backbone.
When i add a complex jQuery sequence, i comment the code -> my comments look like uilang.
It would be nice to reduce the work and do it in one language.
A simple language could be a benefit for all, not only for beginners.
Extend uilang with more commands (like "after that", "then") and conditions and it would be really powerfull language, that can be used for complex things too.
At the moment every developer with little complex instructions have to comment the code, uilang can reduce this work.
A separate npm module and source files with uilang could be parsed and compiled (like browserify) - (reactjs is a good example for that, include directly in frontend or compile jsx in backend).
I really think you should rethink the project and focus not only on beginners. -> i am not sure they will use it, because you find tons of ressources for things like bootstrap, purecss, ....
Mine is a little nicer (IMO of course) and supports a little more than just class toggling (the workhorse of interaction design) such as multiple chained actions per target, and more.
I've always thought of this as an intermediate step - designers for whom this type of thing would be useful would know CSS selectors at least, and could work with a bootstrap-alike. The more useful state would be to expose something like this directly in a web preview environment.
I think you both can create a really good project with that and split the work while extending the language and create a good documentation (with nice ui).
Gabriella . I can see what your saying... Adam `s postlng is impressive... on tuesday I got a gorgeous Maserati from having made $4435 this-past/five weeks and would you believe, 10k this past month . without a question it is the most comfortable work I've ever done . I began this four months/ago and pretty much straight away startad bringin in minimum $71 per hour .
Read Full Report >>>>>>>> www.jobsfish.com
Reminds me of Hypercard. I can't think of many better compliments than that.
There's nothing you can do with Hypercard that you can't do in C, and there's lots of things that you can do in C that you can't do in Hypercard. But there's a lot of people who could manage Hypercard to do basic things who probably would never master C. That, I think, is the problem uilang is trying to solve.
There's also no reason why you can't use uilang to do simple things and roll your own code for more complex ones on the same page.
As an aside, back in GNOME 2 it took me perhaps half an hour's reading to get into UI themes and adapt existing ones to suit my preferences, even start designing my own. It was limited but fun to play with. Then comes GNOME 3 with all its fancy CSS and I just can't be bothered to hunt down how I can make a thicker border on the button with tab focus without the buttons jumping around a few pixels whenever I tab to the next one. Sometimes, less is more. (Long live MATE!)
This seems to be implemented as an external DSL, with a brand new syntax and semantics. So my question is, why do that instead of implement it as an embedded DSL?
(Disclaimer: this is an honest question out of curiosity. I don't mean to imply that an embedded DSL is the right way, or that it's better -- but I do believe there's a tradeoff here and am interested in how that tradeoff factored in to the decision to implement this as a separate language.)
I don't know what you would like clarified, so please let me know if this doesn't cover it:
IMHO, the OP is presenting a DSL (DSL = domain specific language), and there are at least two common ways to implement DSLs, embedded and external (i.e. not embedded):
embedded (or internal) domain-specific languages, implemented as libraries
which exploit the syntax of their host general purpose language or a subset
thereof, while adding domain-specific language elements (data types, routines,
methods, macros etc.)
An example would be with parsers. Parser combinators are usually an embedded DSL. Tools like Lex and YACC are not embedded DSLs (as far as I know).
-----
Disclaimer: both have pros and cons, etc. etc. Interested in the author's motivations, not in debating which way is better, etc. etc.
However, I'd think that support for more than just click events will be needed to make this worthwhile. 'hover', 'tap' and 'drag'/'drop' seem pretty logical.
Chiming in with a few others here - I think uilang looks like a lovely idea, and very clever really given how few line of code are required, but I'm not sure it's genuinely all that useful.
I used to work with a brilliant designer (seriously great - he could realise the most terrible and tangled client ideas in the most stunningly creative and beautiful ways), but code was just gibberish to him. He'd managed to muddle his way through doing simple interactions in ActionScript 2 with the help of several developer friends, but the move to ActionScript 3 had completely defeated him.
I gave him a set of little snippets ("This is how you make something clickable: <code>") and once he had that, he was off. He never properly understood things like for loops, but it didn't really matter to him too much since he was perfectly happy copying and pasting since the end result looked no different.
I don't think having to learn a precisely structured invocation in English (with particular CSS selectors in it) would really be any better for him than just copying in `$("#foo").on("click", function() { $("#bar").addClass("hide"); });` as long as someone had told him "#foo" was what you were clicking on and "#bar" was what you were hiding.
I actually think the other problem with this idea is that the CSS is probably harder to understand than the JavaScript, and the number of people who can write `transform: translateY(80%) scale(.8); transition-timing-function: cubic-bezier(.3, 0, 0, 1.3);` but can't write just a couple of lines of jQuery must be vanishingly small.
The designers I know, at least, either know no CSS and JavaScript at all, or minimal amounts of CSS and JavaScript, or a lot of CSS and the basics of JavaScript - I don't really know any in 2014 who are experts at CSS but have no JavaScript (but I'm happy to be proven wrong on that).
I'd consider myself an expert at CSS, at a level where I can and have built very large frameworks with deep mixins, extends and variable use in Sass that need to be used across multiple projects.
I know the basics of Javascript, mostly around JQuery and setting up things like Grunt and Bower. The types of actions this framework solve are too low level even for me. As you mentioned earlier, I can copy paste or lookup any onclick or toggle events, which are about 90% of all display side JavaScript. Add this class, remove this class... etc.
If updating CSS classes of some elements when clicking on other elements is all your website needs, then uilang might be the right choice for you. For everybody else, there's web development.
It's kind of fascinating / scary that this is running on only 100 lines of javascript..
Kind of a cool way to let designers dive into interactive layouts, if only for just prototyping. I could see it being fleshed out into something that could make a big splash, but it seems really limited at the moment to simple CSS toggles..
I like this. Hate his non xhtml-strict compliant markup (old school).
This is a very creative way to tackle a problem and I love the fact that his JS doesn't add any elements to the existing markup. I feel that once your JS starts drawing dom elements, you've messed up somewhere (unless your front-end is completely JS, different topic). There are of course cases where it is necessary -- supporting older browsers or shimming functionality -- but I've grown to love the separation of markup and interaction.
One could probably build on this idea (wrap your favorite lib) and do things like:
'clicking on ".selector" sends post ".selector[:href]" ..."
But that may make things a bit more complicated in the long run.
Either way, should be fun seeing the 2048-ification of this in the upcoming weeks
47 comments
[ 3.2 ms ] story [ 111 ms ] threadThe target audience of uilang should never, in my opinion, try to build websites.
Sorry I'm bitter today.
the idea is that JS, and probably HTML/CSS by extension, are not the ideal tools for rapid prototyping, and this is a small step in the right direction.
>> The target audience of uilang should never, in my opinion, try to build websites.
why not?? everyone should, in my opinion, be able to build websites.
I guess if you only need support for adding/removing/toggling classes, and you have no plans of using jQuery, this could be useful. It's 1kb of Javascript, compared to jQuery, which is over 80kb minified. Now, everyone and their dog likely has jQuery cached from a CDN, but it's a good way to reduce unnecessary bloat. If they added one or two common features from jQuery, and used a normal syntax instead of this written non-sense, I could see some people using it as a light version of jQuery.
Now somebody just needs to support for CSS. I wan't to say:
* a boxy thing roughly the size of 25% of browser window * a list of things with random paragraphs * a draggable * a receptacle for draggable things * when this receptacle receives this draggable this happens * this is a top bar, this is a sidebar and they should stay put * this is content area, all to other things go there
Yes, I know I can just use Bootstrap or whatnot, but then I'm down the rabbit hole tweaking this and that, because I have a direct control of everything, yet a measure of nothing.
That's not to say it's not a great bit of effort, but I can't think of anybody that has a job to build widgets like on the demo page, yet cannot build them via pure CSS2/3 or JQuery.
I'm no designer, but i'd find it easier using CSS examples I find off the web combined with the information-glue that is StackOverflow, if something goes wrong with UILang, I'm on my own.
The same design taste is evident in the project webpage itself.
I personally teach all of our designers enough jQuery so they can animate their designs. The issue is its a steep learning curve and to be honest the Javascript is normally throw away as once we come to build the interface we normally use a framework like Ember or Backbone.
Nice work Benjamin!
When i add a complex jQuery sequence, i comment the code -> my comments look like uilang. It would be nice to reduce the work and do it in one language.
Extend uilang with more commands (like "after that", "then") and conditions and it would be really powerfull language, that can be used for complex things too.
At the moment every developer with little complex instructions have to comment the code, uilang can reduce this work.
A separate npm module and source files with uilang could be parsed and compiled (like browserify) - (reactjs is a good example for that, include directly in frontend or compile jsx in backend).
I really think you should rethink the project and focus not only on beginners. -> i am not sure they will use it, because you find tons of ressources for things like bootstrap, purecss, ....
Mine is a little nicer (IMO of course) and supports a little more than just class toggling (the workhorse of interaction design) such as multiple chained actions per target, and more.
I've always thought of this as an intermediate step - designers for whom this type of thing would be useful would know CSS selectors at least, and could work with a bootstrap-alike. The more useful state would be to expose something like this directly in a web preview environment.
I think you both can create a really good project with that and split the work while extending the language and create a good documentation (with nice ui).
There's nothing you can do with Hypercard that you can't do in C, and there's lots of things that you can do in C that you can't do in Hypercard. But there's a lot of people who could manage Hypercard to do basic things who probably would never master C. That, I think, is the problem uilang is trying to solve.
There's also no reason why you can't use uilang to do simple things and roll your own code for more complex ones on the same page.
As an aside, back in GNOME 2 it took me perhaps half an hour's reading to get into UI themes and adapt existing ones to suit my preferences, even start designing my own. It was limited but fun to play with. Then comes GNOME 3 with all its fancy CSS and I just can't be bothered to hunt down how I can make a thicker border on the button with tab focus without the buttons jumping around a few pixels whenever I tab to the next one. Sometimes, less is more. (Long live MATE!)
(Disclaimer: this is an honest question out of curiosity. I don't mean to imply that an embedded DSL is the right way, or that it's better -- but I do believe there's a tradeoff here and am interested in how that tradeoff factored in to the decision to implement this as a separate language.)
IMHO, the OP is presenting a DSL (DSL = domain specific language), and there are at least two common ways to implement DSLs, embedded and external (i.e. not embedded):
from http://en.wikipedia.org/wiki/Domain-specific_language:
An example would be with parsers. Parser combinators are usually an embedded DSL. Tools like Lex and YACC are not embedded DSLs (as far as I know).-----
Disclaimer: both have pros and cons, etc. etc. Interested in the author's motivations, not in debating which way is better, etc. etc.
However, I'd think that support for more than just click events will be needed to make this worthwhile. 'hover', 'tap' and 'drag'/'drop' seem pretty logical.
I used to work with a brilliant designer (seriously great - he could realise the most terrible and tangled client ideas in the most stunningly creative and beautiful ways), but code was just gibberish to him. He'd managed to muddle his way through doing simple interactions in ActionScript 2 with the help of several developer friends, but the move to ActionScript 3 had completely defeated him.
I gave him a set of little snippets ("This is how you make something clickable: <code>") and once he had that, he was off. He never properly understood things like for loops, but it didn't really matter to him too much since he was perfectly happy copying and pasting since the end result looked no different.
I don't think having to learn a precisely structured invocation in English (with particular CSS selectors in it) would really be any better for him than just copying in `$("#foo").on("click", function() { $("#bar").addClass("hide"); });` as long as someone had told him "#foo" was what you were clicking on and "#bar" was what you were hiding.
I actually think the other problem with this idea is that the CSS is probably harder to understand than the JavaScript, and the number of people who can write `transform: translateY(80%) scale(.8); transition-timing-function: cubic-bezier(.3, 0, 0, 1.3);` but can't write just a couple of lines of jQuery must be vanishingly small.
The designers I know, at least, either know no CSS and JavaScript at all, or minimal amounts of CSS and JavaScript, or a lot of CSS and the basics of JavaScript - I don't really know any in 2014 who are experts at CSS but have no JavaScript (but I'm happy to be proven wrong on that).
I'd consider myself an expert at CSS, at a level where I can and have built very large frameworks with deep mixins, extends and variable use in Sass that need to be used across multiple projects.
I know the basics of Javascript, mostly around JQuery and setting up things like Grunt and Bower. The types of actions this framework solve are too low level even for me. As you mentioned earlier, I can copy paste or lookup any onclick or toggle events, which are about 90% of all display side JavaScript. Add this class, remove this class... etc.
http://splatcollision.github.io/shorthand.js/
Kind of a cool way to let designers dive into interactive layouts, if only for just prototyping. I could see it being fleshed out into something that could make a big splash, but it seems really limited at the moment to simple CSS toggles..
Where is the Github project?
This is a very creative way to tackle a problem and I love the fact that his JS doesn't add any elements to the existing markup. I feel that once your JS starts drawing dom elements, you've messed up somewhere (unless your front-end is completely JS, different topic). There are of course cases where it is necessary -- supporting older browsers or shimming functionality -- but I've grown to love the separation of markup and interaction.
One could probably build on this idea (wrap your favorite lib) and do things like:
'clicking on ".selector" sends post ".selector[:href]" ..."
But that may make things a bit more complicated in the long run.
Either way, should be fun seeing the 2048-ification of this in the upcoming weeks