kedo posted:

Flexbox is a nice step forward. Sure it has its issues, but at least it's better than trying to cobble together a stable, responsive layout using only positioning or, god forbid, floats.

Granted I chuckle to myself when I realize that 99% of what most developers use flexboxes for are the exact same things people used tables for back in the early 2000s. We've come full circle.

kedo posted:

Missed this on my first read. Why not just go back to <img src="spacer.gif" height="100" /> you goddamn caveman?!

Also:

SupSuper posted:

While we're at it, anyone who still has a pathological fear of <table> in 2015 deserves to be shot.

Pollyanna posted:

Anything that has to do with GUIs has problems of the same nature. Putting together a GUI in Qt is about as painful.

Mr. Wynand posted:

UI is hard. Nobody has gotten it right to date IMO. Effectively describing a UI in code is an as of yet unsolved problem IMO.

Mr. Wynand posted:

Because pre-css that was the only way to accurately size an element. Alas, CSS has solved that particular problem.

v1nce posted:

Shamefully I think Flash had the right idea - you don't design UI with code, you design UI with a UI. I really don't want to be exposed to the underlying definitions if I can avoid it.

quote:

DreamWeaver

HTML, CSS and JS

quote:

Everything designed for the desktop UI suffers from classic desktop UI problems too, because they were only ever designed for use on the desktop. You can't move that poo poo anywhere else. The introduction of touch screens to laptops was an alarming reminder of how desktop apps were designed for one specific method of user interface, and everything else is a hack.

Microsoft's idea for cross-platform universal apps is hopefully a step in the right direction, but their false-start with the UX disaster of metro in Windows 8 isn't helping them win anyone over with the concept.

kedo posted:

No, I meant what are you using <div class="spacer"> for these days? I know what spacer.gif was used for... I have far too many ancient projects kicking around on dusty backup drives that make ample use of it.

I say we bring back websites that are coded entirely by ImageReady and are one big image sliced into 500 smaller images that load in a slow, beautiful collage. Or rounded corner buttons that take 4–9 images to achieve. Old web was best web.

Mr. Wynand posted:

sorry, I'm not actually going out of my way to be contrarian

Mr. Wynand posted:

The laying out of components is a photoshop-like manner is trivial - that was never the hard part. It's the way everything interacts and for that you need to deal with all manner of abstractions and straight up programming logic. UIs don't really help you with that (beyond maybe some basic type hinting and documentation where you need it - but that's more an IDE than a visual editor).

Mr. Wynand posted:

Different devices require a different experience to be explicitly designed for them. Of course if you just need to adapt something on the quick and cheap crossplatform doodads will do, but they are just shortcuts. You will never be able to do a great job with them. There can (and should) be tools and abstractions that might make some of that work easier but there is absolutely no such thing as "write/design once, run anywhere", and there never will be.

Mr. Wynand posted:

Oh I don't since, like I said, I've been wasting my life trying to keep things nice and semantic. I can certainly imagine a situation where you just need a div to take up space and nothing else and rather than calling it "abstract-noncontent-placeholder" or some poo poo we can just call it spacer and be done with it.

Heskie posted:

I'm guessing, but I think what kedo is getting at is why even do this when you could just apply some padding/margin/positioning to some of the markup used for actual content rather than dropping in empty divs.

Mr. Wynand posted:

I'm sure you can for many situations, but like I said, I can conceive of a scenario where having a spacer div is the cleaner solution. Again, the actual point being that it's OK to treat markup as the presentational structure it actually is.

Mr. Wynand posted:

I'm doing it - I'm making a modern responsive layout using tables. I'm living the dream, you can't stop me now!

Mr. Wynand posted:

UI is hard. Nobody has gotten it right to date IMO. Effectively describing a UI in code is an as of yet unsolved problem IMO.

kedo posted:

code:

SCSS:

.breathe {
  margin-top: 5rem;
  margin-bottom: 5rem;

  &--top {
    margin-bottom: 0;
  }
  
  &--bottom {
    margin-top: 0;
  }
}

code:

HTML:

<p class="breathe">I have extra space on the top and bottom.</p>
<p class="breathe--top">I only have extra space on the top.</p>
<p class="breathe--bottom">I only have extra space on the bottom.</p>

An example of my preferred method. While having uber semantic code is not super important to me, I'd still rather not add extra elements when I don't need to. But in general I agree with your point that it's okay for parts of your markup to be purely presentational.

v1nce posted:

I really didn't mean just slapping elements down. I mean actually interacting, transitioning, modifying, etc. I'd love a UI editor which worked play-for-play how it'll work on the target device, including the ability to walk through it, hook up functionality. From my limited knowledge I'm dreaming of something between Qt's designer, SquareSpace and Android's designer. With the ability to be responsive, or the ability to specify my own specific layout per breakpoint. I really don't want to be editing lines and lines of code to position and style and transition poo poo.

quote:

Flash was a bad example - it can only poo poo out content designed for itself in a fixed window. But as a UI editor goes it was a step in the right direction, especially for its time.

Just like a web page, I don't expect to just look at it on my 1920x1200 monitor and go "this will work everywhere!" and it magically looks perfect on my phone, but I want a UI tool which lets me switch to the breakpoints I need, and modify the layout and elements to fit. Maybe even let me specify how I want the transition of elements to look! What a magical day it would be. Yes, there will always be platform hokey-pokey poo poo that just requires a crowbar, but for the core interface elements I just want an authoring tool where I can say "This is a loving button, it triggers this thing over here to go boop. It fucks off in that direction. This new stage slides in." Then I look at it all in the other breakpoint, and I go "woah woah, make the transition faster! make the button flash! Make the title huger and put it over here!", or perhaps I specify an entirely different process for a specific device because I can.

quote:

I want a tool that can handle these differences and unique situations and let me implement them, with the least amount of key presses - if any. UIs are visual, and I should be able to visually author them.

Maluco Marinero posted:

You're over thinking it mate. If it needs to change in CSS, delete the inline styles and there's no problem. If your development has strict naming schemes, its really no problem, because inline styles are localised.

Yes they're bad for specificity, which is why you only use them for one offs where there's no need for media queries. The overhead you think is added is only there if inline styles are used for more than one off text aligns or spacers.

If you're making code thats meant to be overridden by others, of course you wouldn't use inline styles, but sometimes it's better to inline style on a true one off where the only thing you could meaningfully name it is block--slightlyPadded or u-leftAlign or something. Sometimes it's better not to come up for an arbitrary name for every little thing in your system.

piratepilates posted:

Wouldn't it be weird to do things like media queries with inline styles? You'd end up having to have javascript hook on to window resize and update all the inline styles.

Mr. Wynand posted:

I just wrote a Flux store that represents viewport dimensions - React components can render based on it as a special "layout" prop (which also includes some other details like grid sizing). I can do any amount of re-layout I want - beats the pants off bootstrap columns both in terms of the things I am able to do and markup weight. The additional rendering overhead is minimal. It's not like window resize has to be heavily optimized for. It does kind of gently caress up pre-rendered content since I have to pre-render it for one specific viewport size and all devices will get a flash of that layout before the real one loads. Might be a few ways to mitigate that though...

We can/should still use media attributes on our stylesheet links to conditionally load heavy device specific assets, like images.

gbaby posted:

Meteor 1.2 came out today. It comes with ECMA15/new JS stuff and support for React and Angular built in, along of course with it's own templating system Blaze . I haven't learned React yet so today's the day.

Noam Chomsky posted:

Is Meteor worth diving into?

Doc Hawkins posted:

I'm surprised this thread hadn't already discovered Elm. It's a statically typed, purely functional, compile-to-js-html-and-css language, an arrowized FRP platform, an architecture pattern, a time-travelling live-reloading development server, a package repository, and god knows what else. So far I think it's only used in production by this guy.

Somewhere out there is the one person who wished Meteor was more like Haskell, and who now can't believe their luck.

(I predict I will write real things in this.)

JawnV6 posted:

It really seems like the entirety of frontend web tooling needs to be burnt to the ground and rebuilt by adults. Thoughts?

JawnV6 posted:

v1nce posted:

I think the argument was more about each platform wanting to be a special unique snowflake, so pixel-poking in Qt's GUI designer is a lost cause because each platform will look retardedly different to someone.

FamDav posted:

He has some valid points but you can tell his personal definition of quality is heavily informed by the stuff that he works on. His negativity towards garbage collectors and his implication that c means high quality are questionable.

Analytic Engine posted:

Here's a video trashing Node and webdev by Casey Muratori, a guy who contributed to the game The Witness, wrote very popular graphics rendering code, and is making the C++ Handmade Hero project:

https://www.youtube.com/watch?v=6azav9sXK_4

I do webdev and data visualization for tech-focused-but-not-really-tech companies, and I'm worried that guys like this have the right idea and I'm wasting my career on garbage software.