• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

Web Design and Development |OT| Pixel perfect is dead, long live responsive design

Copons

Member
Guys, do you have any resources regarding CSS 3D transforms and animations?

I'd like to (try to) do a perspective animation, but I don't know anything about 3D (and math T_T ) so I'm a bit overwhelmed by it.

What I'm trying to achieve is something like this:
sky and some hills far away, the view moves toward the hills (that scale up, and shouldn't be a problem), with passing inside two "walls" of 2D clouds (let's say for convenience: white divs), skewed in perspective.

In my mind, it would be something roughly like moving through a square tunnel, with just some clouds painted on the side walls.
Does it make any sense? :D
 

JesseZao

Member
Question for any asp.net mvc devs:

For error handling, do you elect to override the onexception method in the handleerrorattribute filter( there's also one in the controller class) or do you use try/catch to route to your custom error pages?

Right now I have try/catch blocks, but as the project grows it's becoming uglier and uglier. I found a solution for overriding onexception that involved building a dictionary for error page routing that looked promising and may implement something similar. As it stands I only really have a not found/404 error page and a general error page that can display the custom error message string from where it called from.

Anyway, what have any of you found to be the best pattern? (I'm not constrained by existing structure as I'm basically treading new ground for my company. I want to lay the best groundwork that I can.
 

Somnid

Member
Question for any asp.net mvc devs:

For error handling, do you elect to override the onexception method in the handleerrorattribute filter( there's also one in the controller class) or do you use try/catch to route to your custom error pages?

Right now I have try/catch blocks, but as the project grows it's becoming uglier and uglier. I found a solution for overriding onexception that involved building a dictionary for error page routing that looked promising and may implement something similar. As it stands I only really have a not found/404 error page and a general error page that can display the custom error message string from where it called from.

Anyway, what have any of you found to be the best pattern? (I'm not constrained by existing structure as I'm basically treading new ground for my company. I want to lay the best groundwork that I can.

I had success replacing the global error handler with dependency injection and then mapping the uncaught exception types to error pages.
 

Zoe

Member
I use Health Monitoring to copy all exceptions (and the occasional custom alert) to a database. Haven't bothered doing any kind of specific error pages.
 

Nelo Ice

Banned
So sitting here with a stupid look on my face. My resume somehow got through a filter cuz I just got an email asking me to take a hacker rank challenge as part of the interview process. Honestly dumbfounded. I did not think I would get this far with a cold application.
 

GHG

Member
Hey guys, doing a bit of web development for my new business at the moment so you might be seeing me in this thread a often over the next few months.

I have a question relating to HTML form inputs and labels and I'm wondering if any of you might be able to give me a definitive answer.

When you are labeling form inputs is it better to nest the input within the label field or is it better to use the for/id method? For example:

Code:
<form>
<p><label for:"username">Username:</label>
	<input id="username" type="text" placeholder="Enter Username"></p>
<p><label for:"password">Password:</label>
	<input id="password" type="password" placeholder="Enter Password"></p>
</form>

OR

Code:
<form>
<p><label>Username: <input type="text" placeholder="Enter Username"></label></p>
<p><label>Password: <input type="password" placeholder="Enter Password"></label></p> 
</form>

Which method will give me more options and flexibility when it comes to styling?
 
Hey guys, doing a bit of web development for my new business at the moment so you might be seeing me in this thread a often over the next few months.

I have a question relating to HTML form inputs and labels and I'm wondering if any of you might be able to give me a definitive answer.

When you are labeling form inputs is it better to nest the input within the label field or is it better to use the for/id method? For example:

Code:
<form>
<p><label for:"username">Username:</label>
	<input id="username" type="text" placeholder="Enter Username"></p>
<p><label for:"password">Password:</label>
	<input id="password" type="password" placeholder="Enter Password"></p>
</form>

OR

Code:
<form>
<p><label>Username: <input type="text" placeholder="Enter Username"></label></p>
<p><label>Password: <input type="password" placeholder="Enter Password"></label></p> 
</form>

Which method will give me more options and flexibility when it comes to styling?

I put inputs inside of labels whenever possible:

1) no need to use for or id's
2) every part of the label (including any space between) is clickable
3) Easier styling in general
 

GHG

Member
I put inputs inside of labels whenever possible:

1) no need to use for or id's
2) every part of the label (including any space between) is clickable
3) Easier styling in general

Perfect, thank you. Just the type of answer I was looking for. I'll nest them moving forwards.
 

Zoe

Member
Wait, that's valid? Mind blown.

Is that a "newer" change from the W3C? Because i remember reading that this isn't valid some years ago.

It never even occurred to me to do things like that because I always use the HTML Helpers in Razor, but the VS text editor doesn't seem to be complaining /shrug
 
Is that a "newer" change from the W3C? Because i remember reading that this isn't valid some years ago.

Nope, it has been like that at least from HTML4.0 :)

https://www.w3.org/TR/html401/interact/forms.html#h-17.9.1

HTML5 spec for reference: https://www.w3.org/TR/html-markup/label.html

I have used a few libraries that insisted on nesting due to their css. Just another factor to keep in mind.

Bootstrap, for example, does this.
 

Nelo Ice

Banned
So anyone take HackerRank tests or challenges as part of their interview or internship?. Kinda freaking out since I'm still terrible solving algorithms. And going through even the easy hacker rank challenges are giving me fits. Have to take a test for the internship I applied to so thinking I'll take the test by the end of the week at the latest. Didn't get a timeline to finish it besides the sooner the better.
 
Not sure whether to ask this here or in the general programming thread, but I need some advice on resources:

This is my last semester of college and I'm in a capstone group with some other students. We've decided upon working with a team of faculty and a few other students to create a new database and interface for a department at the university. In particular, my team will be creating taking an existing paper form and transforming it into an electronic form that can be built into an application that passes the information into the new database that will be built. I've heard you can create applications using HTML5 and JS, but I've also heard there are security risks going that route versus a native language. My question is, for those experienced: 1) what will it take to do something like this for an iPad, and 2) does anyone know of any good resources for building a simple form app to connect to a database?

This seems like a large jump from my normal web design routine.
 

Kalnos

Banned
Not sure whether to ask this here or in the general programming thread, but I need some advice on resources:

This is my last semester of college and I'm in a capstone group with some other students. We've decided upon working with a team of faculty and a few other students to create a new database and interface for a department at the university. In particular, my team will be creating taking an existing paper form and transforming it into an electronic form that can be built into an application that passes the information into the new database that will be built. I've heard you can create applications using HTML5 and JS, but I've also heard there are security risks going that route versus a native language. My question is, for those experienced: 1) what will it take to do something like this for an iPad, and 2) does anyone know of any good resources for building a simple form app to connect to a database?

This seems like a large jump from my normal web design routine.

Nothing insecure about this idea. The HTML/JS is your front end and when the user hits a submit button it sends the information via a POST request to the server which will be using some sort of back end technology. Popular choices for a small app would be something like Python/Flask or JS/Node/Express. Just Google around specific web 'stacks' like those and you will encounter an infinite amount of tutorials.

You will also probably need to research something like Bootstrap (Responsive design) if you want it to look good on iPad/Desktop/Mobile/etc.
 

scurker

Member
Which method will give me more options and flexibility when it comes to styling?

I'd say there's really no definitive answer.

Personally, I prefer nesting inputs inside my labels when possible, but sometimes that does make things more difficult to style, specifically when you want to style the label separately from the input.
 

Somnid

Member
Trying to migrate my Object.observe code to proxies is a shitshow. Chrome is removing Object.observe pretty soon but only just allowed proxies in v50 which seems to indicate there will be very little overlap where old code is unbroken and new code will work on stable releases leaving me with several projects to update in that time (that I can now only use on canary). The interface gets a lot worse, you now need to swap references to the proxy in consuming code which is inelegant, it's slightly better than building an observable object like many frameworks do because you get native methods but you have to build to the library, instead of just integrating it. Arrays are the absolute worst because I need a proxy to an array but that array itself has all of it's items proxied (which requires an new backing store for the real items). You also don't get notified of push and pop, just that a numeric property has changed, plus you get notified about length changing on the set handler which is silly because it's understood to be computed and not truly set. It's annoying and complicated to follow. But the worst is that V8 can't inspect proxies, you just get an error. Surely they intend to fix that before they ship?

Blah, it's pretty clear nobody really thought about this. They weren't that similar at all and I might as well just build fake observable arrays again. Disappointed it just caters to the monolithic frameworks and makes it harder to build lighter replacements.
 

Haly

One day I realized that sadness is just another word for not enough coffee.
From a user point of view, I like clicking labels to focus the input box. It's just ever so slightly more convenient for large amounts of data entry. You can do it with a script, sure, but i believe nesting the input will result in this behavior automatically in most browsers. Saves you some code and saves the user one or two clicks on occasion.
 
Trying to migrate my Object.observe code to proxies is a shitshow. Chrome is removing Object.observe pretty soon but only just allowed proxies in v50 which seems to indicate there will be very little overlap where old code is unbroken and new code will work on stable releases leaving me with several projects to update in that time (that I can now only use on canary). The interface gets a lot worse, you now need to swap references to the proxy in consuming code which is inelegant, it's slightly better than building an observable object like many frameworks do because you get native methods but you have to build to the library, instead of just integrating it. Arrays are the absolute worst because I need a proxy to an array but that array itself has all of it's items proxied (which requires an new backing store for the real items). You also don't get notified of push and pop, just that a numeric property has changed, plus you get notified about length changing on the set handler which is silly because it's understood to be computed and not truly set. It's annoying and complicated to follow. But the worst is that V8 can't inspect proxies, you just get an error. Surely they intend to fix that before they ship?

Blah, it's pretty clear nobody really thought about this. They weren't that similar at all and I might as well just build fake observable arrays again. Disappointed it just caters to the monolithic frameworks and makes it harder to build lighter replacements.

Why not just polyfill it if you need it so badly? Chances that you could have used the native implementation in any time soon (with any proper browser support) would have been very slim in the first place. Performance won't be as good obviously, but the polyfill can be later replaced with an libary that uses proxies instead. Here's a huge amount of options between vanilla JavaScript and "monolithic frameworks" and I am sure that you can find a lightweight, well supported library that fills your needs in no time.
 

Somnid

Member
Why not just polyfill it if you need it so badly? Chances that you could have used the native implementation in any time soon (with any proper browser support) would have been very slim in the first place. Performance won't be as good obviously, but the polyfill can be later replaced with an libary that uses proxies instead. Here's a huge amount of options between vanilla JavaScript and "monolithic frameworks" and I am sure that you can find a lightweight, well supported library that fills your needs in no time.

I'm pretty convinced you can't polyfill it because they don't work the same way, proxies are a wrapper and object.observe works on native objects so to use a proxy you need to replace a reference which requires a change in the consumer code. Maybe I could override the native object constructor or something weird and dangerous. Most polyfills are timer based which is exactly what I don't want. That's kinda why I'm disappointed, it's much less flexible and introduces dependency which was what I wanted to avoid. I built my library because I was dissatisfied with my options in the first place.
 

WanderingWind

Mecklemore Is My Favorite Wrapper
One of the first questions I ever asked was how to make a more interactive map. Today, I figured out how to use SVGs semi-well. If the popovers work the way I think they'll work, tomorrow I may be able to make something I've wanted to create for 2 years. Granted, I have had about 30+ projects get in the way in the meanwhile, but still.

Front end development is so fucking cool.
 

grmlin

Member
Ampersand uses a pretty simple getter/setter approach. You have to write some sort of spec for you models first, of course, but I think with the other options available this is a good and broadly support (IE9 afaik) solution.

Well, maybe I totally misunderstood the problem. Did you link your library somewhere Somnid? :)
 

Somnid

Member
Ampersand uses a pretty simple getter/setter approach. You have to write some sort of spec for you models first, of course, but I think with the other options available this is a good and broadly support (IE9 afaik) solution.

Well, maybe I totally misunderstood the problem. Did you link your library somewhere Somnid? :)

https://github.com/Somnid/tmpl

This is the old version that I have hooked up to a bunch of personal projects. I was working on creating a 2nd gen rewrite to have less special syntax and more method chaining but that's on hold until I can figure out a paradigm to move forward with. I have to fix the issues with this one first.

It does 2 way binding with the DOM. You pass it an element or a template, a binding hash which hooks up the values to different aspects of the element and the plain javascript object that represents the model. It gives you the document fragment (or nothing if you bind to existing DOM) Then anytime you make a change to that object the DOM updates appropriately and vise-versa. I wanted something more programmatic than knockout and angular that was easy to drop in.

Currently the main change is that I have to return both the docfrag and the proxied model since changes to model aren't trapped, only changes on the proxy. This requires more strictness on how it's consumed, since you need to use that proxied model reference from then on. So now not a lot is gained by trying to keep plain objects because you have to know how to use it rather than it just working automagically on the objects you had. I don't care too much about browser support right now. Stable Chrome is my main target, and I'd hope others fill in support for things I need over time.

Nothing is a deal-breaker here but it's a lot of work to rewrite and it'll never be as clean as it once was. It's still probably a step above most existing (non-proxy) solutions though as you don't need special access methods so I want to continue with it.
 
Not sure whether to ask this here or in the general programming thread, but I need some advice on resources:

This is my last semester of college and I'm in a capstone group with some other students. We've decided upon working with a team of faculty and a few other students to create a new database and interface for a department at the university. In particular, my team will be creating taking an existing paper form and transforming it into an electronic form that can be built into an application that passes the information into the new database that will be built. I've heard you can create applications using HTML5 and JS, but I've also heard there are security risks going that route versus a native language. My question is, for those experienced: 1) what will it take to do something like this for an iPad, and 2) does anyone know of any good resources for building a simple form app to connect to a database?

This seems like a large jump from my normal web design routine.

Nah, no major security risks for a JS driven site versus any other languages.

There are tons of resources online for creating simple web applications using the "MEAN" Stack. MEAN is MongoDB (A database system), Express (a server middleware), Angular (a front-end layer), and Node (a javascript driven platform). There are hundreds of simple app tutorials that can get you started, for instance this one on building a to-do app with node, angular, and mongoDB and you can expand that so that instead of having a single form question, have multiple.

Most of these tutorials also use Bootstrap which is a front-end style library that will enable you to quickly develop a website that will look good and work on any device... From your desktop down to a cell phone.

If you want to use another web stack, you could also use PHP, MySQL, and Apache, which millions of websites use around the web (typically nicknamed the LAMP [Linux] or WAMP [Windows] stack). Despite that PHP and MySQL are definitely less sexy than other stacks and libraries, a huge percentage of websites are powered by this stack and it's still incredibly popular if not out of favor with the web development zeitgeist.

But, if you're starting from scratch and learning something new, the MEAN stack is as good a place to start as any... It'll keep you coding entirely in JavaScript, rather than other stacks which often have you transitioning from PHP, to JavaScript, to SQL Queries, and so on.
 
If you want to use another web stack, you could also use PHP, MySQL, and Apache, which millions of websites use around the web (typically nicknamed the LAMP [Linux] or WAMP [Windows] stack). Despite that PHP and MySQL are definitely less sexy than other stacks and libraries, a huge percentage of websites are powered by this stack and it's still incredibly popular if not out of favor with the web development zeitgeist.

But, if you're starting from scratch and learning something new, the MEAN stack is as good a place to start as any... It'll keep you coding entirely in JavaScript, rather than other stacks which often have you transitioning from PHP, to JavaScript, to SQL Queries, and so on.

MEAN will probably be what we end up using since other faculty and students are going to be building the database upon MySQL and PHP.
 

Maiar_m

Member
SEO might play a part in those choices? Having a SPA front can make it difficult and explains why many consumer websites still use LAMP and others multiple pages, server-served logics.

Edit: talking out of my ass, for the required project, MEAN sounds way way better.
 

Kalnos

Banned
I dunno I sort of agree that an SPA is overkill. Just because you use Express it doesn't mean you have to use the 'MEAN' stack though, that's just the popular buzzword stack. You could just as easily roll Express with the default Jade templates for server-side rendering and use something like Postgres/MySQL for the database if you're opposed to Mongo.
 
If you use the MEAN Stack, it also doesn't have to be an SPA. And yeah you don't have to use Angular either, but it'd probably make it easier. Jade is fine but I think if you're building web pages for the first time or using something like Bootstrap you're going to have a harder time with Jade than Angular.

But I just don't like Jade in general because I don't have a problem working with XML-based markup and I think it abstracts out too much.
 

Kalnos

Banned
Even if it isn't an SPA I still think Angular is probably overkill. If it's just an electronic survey form then it would probably be easier to just use jQuery or vanilla JS. Unless you really want the added frustration of learning Angular.

EDIT: I don't really like Jade either though, not gonna lie. There's probably a good alternative though. Though maybe the default MEAN stack would be best since that's where the most tutorials are...since this is all pretty overwhelming haha.
 

Tathanen

Get Inside Her!
Even if it isn't an SPA I still think Angular is probably overkill. If it's just an electronic survey form then it would probably be easier to just use jQuery or vanilla JS. Unless you really want the added frustration of learning Angular.

Now that I've gotten over the "learning angular" hump it's actually harder for me to justify ever building a site without it. jQuery just feels like such a relic.
 

Kalnos

Banned
Now that I've gotten over the "learning angular" hump it's actually harder for me to justify ever building a site without it. jQuery just feels like such a relic.

Agreed jQuery is definitely a relic which is why just plain ol Javascript works really well if it's just a one-off page.

I'd say people will say the same thing about Angular 1.X and point to something like React though. :p
 
https://github.com/Somnid/tmpl

This is the old version that I have hooked up to a bunch of personal projects. I was working on creating a 2nd gen rewrite to have less special syntax and more method chaining but that's on hold until I can figure out a paradigm to move forward with. I have to fix the issues with this one first.

It does 2 way binding with the DOM. You pass it an element or a template, a binding hash which hooks up the values to different aspects of the element and the plain javascript object that represents the model. It gives you the document fragment (or nothing if you bind to existing DOM) Then anytime you make a change to that object the DOM updates appropriately and vise-versa. I wanted something more programmatic than knockout and angular that was easy to drop in.

Currently the main change is that I have to return both the docfrag and the proxied model since changes to model aren't trapped, only changes on the proxy. This requires more strictness on how it's consumed, since you need to use that proxied model reference from then on. So now not a lot is gained by trying to keep plain objects because you have to know how to use it rather than it just working automagically on the objects you had. I don't care too much about browser support right now. Stable Chrome is my main target, and I'd hope others fill in support for things I need over time.

Nothing is a deal-breaker here but it's a lot of work to rewrite and it'll never be as clean as it once was. It's still probably a step above most existing (non-proxy) solutions though as you don't need special access methods so I want to continue with it.

I was looking at your implementation and while it is simple, it also seems to be pretty brutal as far as performance goes. While the observing values changed with o_O is fast, screwing around with DOM never is: doing the changes one by one is fast way to layout trashing lane. When dealing with DOM, always batch your changes and deal with them when the appropriate time comes.

Further on, despite using o_O, dirty-checking might still be needed for checking if the values have actually changed. Consider changing fooModel the values of barModel

Code:
let fooModel = {foo: "bar"};
let barModel = {foo: "bar"};

o_O notices the change (correct?) but the actual values haven't actually aren't actually different and unneeded DOM changes are triggered.
 

grmlin

Member
To be honest, I'm very careful using two way data binding as it gets a resource hog so fast.

In React I use the "Model -> View" bindings (of course, that's what React was made for) but never include the two way binding helper. I prefer to do the things myself when they happen. I have to write a little more code of course, but I feel safer this way.


Anyway, writing some sort of library is a great exercise and everybody should try it. So much work but also a lot of fun and much to learn.
 
A little late to the discussion, but on the jobs thing - we're currently hiring a designer/front-end dev role. It's my first time being on this side of a hiring process, actively being involved in going through applications.

Things that have stood out to me personally, don't know if it's useful advice or being picky...

1. HAVE A PORTFOLIO. It's incredible how many just don't. I'm sure you could have more reason not to for a pure dev role, you can't share all that, but for a role which involves designing, show stuff! Even just pictures! Code is best, but so many just have sent nothing. It's something I think we need to bolster in our ads the importance of, but yeah, if design's involved, just do it anyway... Doesn't have to be big, but one example is better than none.

2. For people going for web designer roles, um, I can view source and tell you've just used a Wordpress theme and plonked a logo in. Nothing against doing low-level freelance work that's mostly bought theme based, but again, I can't go "sure they come up with great designs" when not a single element of placement of content is your own. SAD FACE. Hey why not also design your own portfolio site rather than buy one? Again, if you're showing enough of your own work you could get away with it, but it's a chance to do something without client decisions getting in the way!

3. Standard job stuff of 'covering letters are great', do that in the email and tailor to the job okay thanks.

4. Oh this isn't an annoyance but just amusing, why are people rating technical skills in percentage? I get that it's showing which one you're more proficient in, but "80% CSS3" makes it sound you've learnt 80% of CSS, what does that even mean?
 

Copons

Member
Guys, what's the word about masonry-like layouts these days?

I'm trying to replicate the Material cards layout, like with CSS columns, but the suggested sorting goes from left to right, while columns are sorted top to bottom.
Is there a viable CSS-only solution or will I sadly need to resort to some scripts?
 

Deltoid

Banned
4. Oh this isn't an annoyance but just amusing, why are people rating technical skills in percentage? I get that it's showing which one you're more proficient in, but "80% CSS3" makes it sound you've learnt 80% of CSS, what does that even mean?

this is probably just so they have an excuse to use those circle chart things haha, they can be sexy but they're god damn everywhere

iphone5b-wood_1x.png
 

Maiar_m

Member
Guys, what's the word about masonry-like layouts these days?

I'm trying to replicate the Material cards layout, like with CSS columns, but the suggested sorting goes from left to right, while columns are sorted top to bottom.
Is there a viable CSS-only solution or will I sadly need to resort to some scripts?

It's funny how this question pops up every month, like there's a "this day" every month :D It's a fair question though, I'm not taking the piss., it's just amusing to see the "fad" or masonry grids being a continuous mystery.

Although it's a neat UI trick, masonry layout has several UX shortcomings mostly stemming from the fact that if you need hierarchy and chronology to be implied in your layout, then masonry won't do it. Technically, I'm not aware of any CSS-only solution, as sorting does indeed always comes left to right (or rtl if needed), and plugins aren't necessarily bullet-proof either. None of those I have used offered a consistent top to bottom stacking option.
 

Somnid

Member
I was looking at your implementation and while it is simple, it also seems to be pretty brutal as far as performance goes. While the observing values changed with o_O is fast, screwing around with DOM never is: doing the changes one by one is fast way to layout trashing lane. When dealing with DOM, always batch your changes and deal with them when the appropriate time comes.

Further on, despite using o_O, dirty-checking might still be needed for checking if the values have actually changed. Consider changing fooModel the values of barModel

Code:
let fooModel = {foo: "bar"};
let barModel = {foo: "bar"};

o_O notices the change (correct?) but the actual values haven't actually aren't actually different and unneeded DOM changes are triggered.

Yeah, o_O had ways where you could batch changes but that part of the spec was a bit complicated, it was much lower priority than actually getting it working and dog fooding the API. Though in your example it's really a new object so you'd have to rebind it. That would have been a future area of work (batch until the next animationFrame to avoid thrash). In my use cases it was uncommon for multiple values to change at the same time and the performance was pretty good due already due to native checking as long as long as you weren't changing values constantly. A simply dirty check is probably an easy win though. I appreciate you looking at it.

To be honest, I'm very careful using two way data binding as it gets a resource hog so fast.

In React I use the "Model -> View" bindings (of course, that's what React was made for) but never include the two way binding helper. I prefer to do the things myself when they happen. I have to write a little more code of course, but I feel safer this way.


Anyway, writing some sort of library is a great exercise and everybody should try it. So much work but also a lot of fun and much to learn.

It shouldn't really be different performance-wise than manual event processing, it's just a matter of "how often do I really want data?" Instant feedback is what good UIs do and it's a lot of boilerplate if you don't use a data binding strategy. The user is nearly always the bottleneck, they can't modify UI elements faster than you can process them so 2 way shouldn't be too bad, model -> view binding is where you are more likely to get into trouble especially if something is quickly modifying the model. Also, building frameworks is fun, and useful for understanding. I got a ton of experience with new things by doing this.
 
Yeah, o_O had ways where you could batch changes but that part of the spec was a bit complicated, it was much lower priority than actually getting it working and dog fooding the API. Though in your example it's really a new object so you'd have to rebind it. That would have been a future area of work (batch until the next animationFrame to avoid thrash). In my use cases it was uncommon for multiple values to change at the same time and the performance was pretty good due already due to native checking as long as long as you weren't changing values constantly. A simply dirty check is probably an easy win though. I appreciate you looking at it.

It shouldn't really be different performance-wise than manual event processing, it's just a matter of "how often do I really want data?" Instant feedback is what good UIs do and it's a lot of boilerplate if you don't use a data binding strategy. The user is nearly always the bottleneck, they can't modify UI elements faster than you can process them so 2 way shouldn't be too bad, model -> view binding is where you are more likely to get into trouble especially if something is quickly modifying the model. Also, building frameworks is fun, and useful for understanding. I got a ton of experience with new things by doing this.

The biggest issue with 2-way-binding (in my perspective) is that it is too damn easy which makes it too damn easy to abuse :). For example in your library, the API looks pretty easy so some developer might get the brilliant idea of binding everyything to the same model. Suddenly anything that the end-user changes makes everything re-render and then you get complaints about the page being slow. People expect that something like React is the magic bullet to these kinds of problems and sometimes they are, because the libraries are kinda smart, but most often using them wrongly makes your app perform even worse. And React is just passing down the props, with pure 2 way binding it can easily be disasterous.

This is a neat video about optimizing React performance: https://www.youtube.com/watch?v=KYzlpRvWZ6c

For your project, https://github.com/wilsonpage/fastdom might be something to take inspiration from, maybe in a less strict format though. Making the library virtual DOM powered might save tons of trouble though https://github.com/Matt-Esch/virtual-dom, but you might lose the simplicity you are looking for with it. Writing frameworks and libraries are fun (and useful!), but re-inventing a wheel might not be the right choice in the long run :)
 

Somnid

Member
The biggest issue with 2-way-binding (in my perspective) is that it is too damn easy which makes it too damn easy to abuse :). For example in your library, the API looks pretty easy so some developer might get the brilliant idea of binding everyything to the same model. Suddenly anything that the end-user changes makes everything re-render and then you get complaints about the page being slow. People expect that something like React is the magic bullet to these kinds of problems and sometimes they are, because the libraries are kinda smart, but most often using them wrongly makes your app perform even worse. And React is just passing down the props, with pure 2 way binding it can easily be disasterous.

This is a neat video about optimizing React performance: https://www.youtube.com/watch?v=KYzlpRvWZ6c

For your project, https://github.com/wilsonpage/fastdom might be something to take inspiration from, maybe in a less strict format though. Making the library virtual DOM powered might save tons of trouble though https://github.com/Matt-Esch/virtual-dom, but you might lose the simplicity you are looking for with it. Writing frameworks and libraries are fun (and useful!), but re-inventing a wheel might not be the right choice in the long run :)

I don't think anything I make will get the notice of a large project with lots of techno-evangelism. Re-inventing the wheel is necessary I think, especially at the rate of change the web is going at and all the new tools we've gained even in the past year. I'm a big proponent of it because it's something you tell novices to keep their eye on the prize (If you want to design games don't start with building your own engine), but the more experience you gain the more you realize that even common code has a lot of problems and people avoid touching it, sometimes politically, but also when you have a heavily used project that has lots of legacy constraints you can't even upgrade it if you want (look at angular 2). I think that's exactly why the web has so many flavor of the month frameworks. Someone comes along using newer techniques and buries the older feature bloated library existing sites depend on. But ultimately I'm selfish and I would like to own my own code and make it such a way it appeals to my own biases and style.

Until it was stable in all major browsers I wouldn't put any of this in client code.
 

WanderingWind

Mecklemore Is My Favorite Wrapper
So, I got something to work that is part me understanding SVGs and how to inline them, part of my experimentation with Bootstrap popovers and one part JS that I sort of understand, but not really. The initialization script came from me Googling a problem and tweaking an answer I found on Stackoverflow. But I would really like to know what exactly the JS is doing and how it's doing it.

If it's not too much to ask, could somebody walk me through what I'm looking at?

https://jsfiddle.net/WanderingWind/8nwfu44f/2/
 

Copons

Member
It's funny how this question pops up every month, like there's a "this day" every month :D It's a fair question though, I'm not taking the piss., it's just amusing to see the "fad" or masonry grids being a continuous mystery.

Although it's a neat UI trick, masonry layout has several UX shortcomings mostly stemming from the fact that if you need hierarchy and chronology to be implied in your layout, then masonry won't do it. Technically, I'm not aware of any CSS-only solution, as sorting does indeed always comes left to right (or rtl if needed), and plugins aren't necessarily bullet-proof either. None of those I have used offered a consistent top to bottom stacking option.

Damn I wrote a big ass reply, but the corporate internet fucked up and I lost everything -> I AM CRY

Briefly: I'm not the biggest masonry fan every, I'm just trying to replicate some (most) of the Material guidelines, and Google says to sort cards in a masonry-like layout, left-to-right, while CSS columns work top-to-bottom.
I don't like the idea of using a bloated script for this feature, so I was hoping someone found a never-heard-before CSS4-only rule solving this very thing.
Turns out, I guess, I'll have to write my own stripped down masonry.


The biggest issue with 2-way-binding (in my perspective) is that it is too damn easy which makes it too damn easy to abuse :).

Oh but it's quite fun debugging other people's code and finding so much abuse, it should be punishable by law, and refusing to fix it because I honestly couldn't find the root (pun sort of unintended) of the issues, even if they paid me big money for it
and they don't
.
 

Somnid

Member
So, I got something to work that is part me understanding SVGs and how to inline them, part of my experimentation with Bootstrap popovers and one part JS that I sort of understand, but not really. The initialization script came from me Googling a problem and tweaking an answer I found on Stackoverflow. But I would really like to know what exactly the JS is doing and how it's doing it.

If it's not too much to ask, could somebody walk me through what I'm looking at?

https://jsfiddle.net/WanderingWind/8nwfu44f/2/

It's a bit hard to follow due to the way it's laid out but basically when you click on a section it hides all existing popovers and then presents the new one for that section, if you click off of a target it hides the popovers. Which part gives you trouble?
 

WanderingWind

Mecklemore Is My Favorite Wrapper
It's a bit hard to follow due to the way it's laid out but basically when you click on a section it hides all existing popovers and then presents the new one for that section, if you click off of a target it hides the popovers. Which part gives you trouble?

Uh. Well, considering I'm still firmly at the navigation bar level in my JS self-lessons, uh...all of it. This implementation works very, very well but I don't know why. Many other "solutions" either didn't work on mobile, had very poor responsiveness with clicks on the body (or in this case 'html? how does that work?).
 

Somnid

Member
Uh. Well, considering I'm still firmly at the navigation bar level in my JS self-lessons, uh...all of it. This implementation works very, very well but I don't know why. Many other "solutions" either didn't work on mobile, had very poor responsiveness with clicks on the body (or in this case 'html? how does that work?).

Part of the reason this works on mobile is because of the "touchend" event on html. This is when your finger leaves the touchable area of the web page, and in this case it closes the popovers. Click and touch events are similar but behave slightly differently, and this code assigns the close event to both. "Html" is equivalent to the document or the root element of the page. Events bubble up, so if you have html > body > div > a the <a> will trigger a touch event, then the <div> that contains it, then the <body> and then the <html>. So html will capture all events but what this code is doing when it finally triggers the event on html is asking "was the top-most element that was clicked the popover?" If yes then you clicked the popover and we don't want to close it, otherwise close it.
 

Kinitari

Black Canada Mafia
Been on a client project for a year that's wrapping up this week, and I'm super excited to be moving on to a new project soon. Almost all of our new projects are using es6 and react/angular 2, which is fun and new compared to my angular 1.3 ionic app I've been working on this last year. We did use rx.js on that project though so I've become proficient - however I haven't had the experience of working 40 hours a week on one of these next gen framework/libraries - only a few weekends here or there.

I've gotten my feet wet in an immutable/ng2/ts/rxjs app - and I'm stoked.

Over the course of the year I've become extremely functionality reactive in my dev style, and I've noticed a real improvement in my code. It's tough though when I have to consolidate this with a project that lasted a year, and try and keep code style consistent. However, going forward, there's no way I'm going back.

If you guys aren't familiar with functional reactive programming on the web, give it a look see and try it out on some projects - redux or rxjs is fine, I think. It's honestly so damn easy to debug or refactor, I feel like I'm cheating most of the time.

I had to add a feature to someone else's code last week that involved an async call, and it was so dann messy. None of the functions took params, they all just had global variables in the service that represented the state, and would filter on these values. Throwing an async function into this was a nightmare - and would have been ridiculously easy if the service properly utilized rxjs.
 

grmlin

Member
I used redux in a small project to give it a try on a smaller test subject ;)

It took some time to wrap my head around redux first, coming from the more traditional flux architecture, but in the end I really loved it.


I have a bigger project in the pipeline and I will definitely use it again. I like it much more than the other flux frameworks I tried before.
 
So, due to a high motivation thanks to the new year, a few weekends of regular sleep and all posts in here about the hot stuff in web dev, i'm thinking of building a little portfolio/cv site. Nothing big, just the usual details about me, and the projects i did in my various jobs.

Now i fear, i might lose the motivation when i start digging through all frameworks, etc. ... therefor ... any suggestions on what to check out and keep an eye on?
 
Top Bottom