21 ms·

On one hand I think this is really neat. On the other this is why I have never taken front end development seriously enough to spend any real time learning it [

On one hand I think this is really neat. On the other this is why I have never taken front end development seriously enough to spend any real time learning it [0]. From the get go it always seemed like the rules were arbitrary and involved lots of guessing to get things right. I know this isn't actually true but it felt true enough early on to poison my mind to it. [0] Not something I'm proud of and I know front end development is serious business so don't @ me.

moron4hire 8y ago
Try writing C meant to compile in different compilers, on different processor architectures. Or ANSI SQL meant to run in a variety of RDBMSes. Web GUI is not the only bastion of arbitrary behavior. I would wager, if your goal is to make as wide-spread, cross-platform GUI as possible, a Web GUI is the easiest way to do that, for both the developer and the users.
- tmd83 8y ago
  C has a much bigger baggage. I assume a big chunk of C is modern version of compilers is fairly gotcha free. But even the core basic part of Web is full of gotcha. Just the fact that you need to start with a normalize.css is reason enough. And as they fix compatibility in 1 things, they seem to add 10 more. Maybe I'm wrong and clueless. But web seems to be a bastion for adding overly complex solutions while failing at trivial things often enough not always. I agree it is probably still the cheapest way to get a cross platform GUI at least maintenance wise. But it is a pile of electricity sucking horrendous crap regardless or at least a big part of it. More frustratingly I'm not sure that it has to be the case.
  - markmark 8y ago
    As someone who came from "native" gui development and has only really been doing web stuff seriously for a few years, it's pretty easy now, particularly if you don't need to support IE, and even IE11 isn't _too_ much of a pain. I've never used a normalize.css for example.
- dopamean 8y ago
  This is a great point and I appreciate you pointing it out. Cross platform development is hard regardless of which part of the stack you're developing for. The reason development for the browser stands out for me is that when I build a web app I can control to a certain extent what environment the server is deployed in and then I don't have to worry too much about different platforms. However I have no control over which browser my user chooses to use and that can have a serious impact on their experience. An impact that I have to account for.
  - qudat 8y ago
    It's pretty easy to control, just detect which browser and throw up a screen saying that browser isn't supported or "use at your own risk." I don't see any distinction between cross platform support and cross browser support.
    - Moru 8y ago
      That is not support, that is denial of service and isnt an option for most webpages.
amelius 8y ago
> From the get go it always seemed like the rules were arbitrary and involved lots of guessing to get things right. I know this isn't actually true but it felt true enough early on to poison my mind to it. I guess you aren't into Deep Learning either ;)
- bryanrasmussen 8y ago
  Most programming/development environments/standards have arbitrary rules. Also most workplaces I've found. It's arbitrary almost all the way down.
duxup 8y ago
It is frustrating as here we are in 2019...er 2018 and structring a page is still kinda wonky.
- davnicwil 8y ago
  Is it? That's disappointing. Who wins the world cup by the way? :-)
  - duxup 8y ago
    England
- spankalee 8y ago
  Except for the fact that in 2018 it's actually not wonky at all.
robbrown451 8y ago
Honestly its getting rarer and rarer to find things like this, most things that reasonable people want to do "just work." You have to go to considerable effort to come up with a case like this.
- mvdwoord 8y ago
  What is the status quo on vertical alignment if I may ask..
  - evan_ 8y ago
    Flex box https://philipwalton.github.io/solved-by-flexbox/demos/vertical-centering/ https://philipwalton.github.io/solved-by-flexbox/demos/verti...
    - lisper 8y ago
      The code shown on that page actually doesn't work, though the code in the github repo does. And this exposes the problem with the current state of the art: yes, you can probably get flexbox to do what you want [@] if you know how. But if you don't know how, trying to figure it out is still very hard. You should be able to write: <center>stuff</center> or <vertical-center>stuff</vertical-center> There is really no reason that should not Just Work. (The <center> tag has worked for 20 years, notwithstanding that it has been deprecated for most of that time.) --- [@] What if I want to put something in the lower left or upper right hand corner?
      - rvense 8y ago
        You should not be centering things in HTML, that's the stylesheet's job.
        lisper 8y ago
        I have no objection to having a style sheet that defines what the <center> tag does. But it should at least be possible to have a center tag and a vertical-center tag. AFAICT it is not possible. At the very least you need both a center-capable container and centered elements.
jayd16 8y ago
This isn't really a spec thing. Its more a manifestation of undefined behavior. Even c++ compilers have undefined behavior.
- tgummerer 8y ago
  Especially C++ compilers have undefined behavior
  - chiefalchemist 8y ago
    Yes. But are you going to to use 3 to 5 or mote C++ compilers on a given project? The worst part of these frontend issues is, ultimately, the UX can become inconsistent, if not mess. Given that nearly everyone interfaces via the visual UI, you'd think we'd have this sorted out by now.
    - ben0x539 8y ago
      If your project is a library, I'd expect that people are gonna use it with, like, maybe not 5 but probably 2 or 3 different compilers, and they're gonna be less diligent about upgrading their compiler versions than mainstream browser users.
      - chiefalchemist 8y ago
        Thanks. I wasn't thinking about it that way. Good point. That said, the browser's impact on UX is essential. A lot more people use browsers than compilers. You'd think the UX would matter by now.
    - ravenstine 8y ago
      Does a single compiler work exactly the same on every architecture? :D
  - de_watcher 8y ago
    You're using the words wrong. The code may have undefined behaviour. For example, a race condition is an UB. Compiler won't invent locks that were not specified by the programmer in a code with some raw threads. As a result, CPUs will trash the memory.
krsdcbl 8y ago
So you're saying other dev domains don't have intrinsic glitches and oddities? ;)
billybolton 8y ago
Forcing the DOM, JS and CSS was a mistake. The problem was that you couldn't have alternatives. wasm is going to disrupt front end by allowing you to have a strong typed language that you can use to build your own framework like the good ol' days.
- crimsonalucard 8y ago
  Still gotta deal with the dom though. They need a root pixel level api to be made in conjunction to wasm, so people can restart from scratch.
  - billybolton 8y ago
    Only once for the containing canvas. A direct access to the canvas pixel data and webGL offscreen rendering is all you need. With a few hacks, we're already 90% there. I expect by next year to see an explosion of this. There already are projects in Github that translated SDL and OpenGL to build web widgets.
sonnyblarney 8y ago
" I know this isn't actually true " It's true. A confluence of vague definitions, poor implementations, bad documentation ... and this is the web we have. It's the tip of the iceberg, and the painful life of anyone doing html5 work, it's 'not fun' for anyone who's been exposed to regular programming because the problems you spend your day solving mostly should not be problems to begin with.
- shawn 8y ago
  This is what us older people would like to believe. Meanwhile the young webdevs are having a blast ignoring us and building the apps of the future.
  - King-Aaron 8y ago
    > having a blast ignoring us and building the apps of the future Building technical debt for the future I tend to think, which I guess is good for keeping future devs employed.
  - sonnyblarney 8y ago
    My experience is that young web-devs don't even know the dystopian matrix they live in, and when they discover 'regular programming', in many ways their perspective changes. Both web and regular dev have their faults but the the King of Byzantium is HTML5.
  - BigJono 8y ago
    Nah, it's mostly true (I'm one of those young webdevs), but I'd attribute the pain points in front-end development to slightly different problems than the state of browser inconsistencies and spec problems. IME 70% of the problems people run into are self-inflicted due to overengineered solutions. I spend a lot of time lurking front-end IRC channels and most of the problems that get posted is stuff that I have never had trouble with, with libraries I'd never even consider using, that I don't have the first clue how to fix without going back to square one and re-engineering the solution from the ground up. The advice given by people that do attempt to help with these problems is often awful and creates more confusion. For the most part, I don't think people realise that libraries add to the complexity of their software, rather than abstracting it away. Every front-end dev desperately needs to go and read the Law of Leaky Abstractions, because they're getting smoked by it on a daily basis and they don't realise. The other 30% of problems come down to what GP mentioned, ambiguous specs, browser inconsistencies etc. Stuff like the relationship between x-overflow and y-overflow, little flexbox niggles like different behaviour depending on if flex-direction is set to row or column etc etc. This stuff can often be worked around with simple but unintuitive fixes (usually some fuckery with negative marigns and such), the two difficulties lie in discovering the solution to begin with (there's boatloads of bad and outdated advice everywhere), and running into these solutions when they haven't been properly documented (usually the case if some junior programmer has just ripped the hack off SO without understanding the theory behind it). The secret to being good at front-end dev is to develop strategies to handle these problems, and to pick your resources very carefully (much as you would in any other ecosystem beset with noobs, like PHP back in the day). I believe (based on my experience) that it's possible to build very successful software with very horrible engineering. Good and successful aren't necessarily synonymous in the world of big VC money. A great example is this: I need two hands to count the critical failure bugs I've run into with Uber's products in the last year. By critical failures I mean things that have flat out stopped me from being able to use it. I strongly suspect (a subset of) their engineering sucks (sorry to anyone here that works for them!). But hey, I don't own a squillion dollar company so what do I know? ;)

moron4hire 8y ago

Try writing C meant to compile in different compilers, on different processor architectures. Or ANSI SQL meant to run in a variety of RDBMSes. Web GUI is not the only bastion of arbitrary behavior. I would wager, if your goal is to make as wide-spread, cross-platform GUI as possible, a Web GUI is the easiest way to do that, for both the developer and the users.

tmd83 8y ago
C has a much bigger baggage. I assume a big chunk of C is modern version of compilers is fairly gotcha free. But even the core basic part of Web is full of gotcha. Just the fact that you need to start with a normalize.css is reason enough. And as they fix compatibility in 1 things, they seem to add 10 more. Maybe I'm wrong and clueless. But web seems to be a bastion for adding overly complex solutions while failing at trivial things often enough not always. I agree it is probably still the cheapest way to get a cross platform GUI at least maintenance wise. But it is a pile of electricity sucking horrendous crap regardless or at least a big part of it. More frustratingly I'm not sure that it has to be the case.
- markmark 8y ago
  As someone who came from "native" gui development and has only really been doing web stuff seriously for a few years, it's pretty easy now, particularly if you don't need to support IE, and even IE11 isn't _too_ much of a pain. I've never used a normalize.css for example.
dopamean 8y ago
This is a great point and I appreciate you pointing it out. Cross platform development is hard regardless of which part of the stack you're developing for. The reason development for the browser stands out for me is that when I build a web app I can control to a certain extent what environment the server is deployed in and then I don't have to worry too much about different platforms. However I have no control over which browser my user chooses to use and that can have a serious impact on their experience. An impact that I have to account for.
- qudat 8y ago
  It's pretty easy to control, just detect which browser and throw up a screen saying that browser isn't supported or "use at your own risk." I don't see any distinction between cross platform support and cross browser support.
  - Moru 8y ago
    That is not support, that is denial of service and isnt an option for most webpages.

amelius 8y ago

> From the get go it always seemed like the rules were arbitrary and involved lots of guessing to get things right. I know this isn't actually true but it felt true enough early on to poison my mind to it. I guess you aren't into Deep Learning either ;)

bryanrasmussen 8y ago
Most programming/development environments/standards have arbitrary rules. Also most workplaces I've found. It's arbitrary almost all the way down.

duxup 8y ago

It is frustrating as here we are in 2019...er 2018 and structring a page is still kinda wonky.

davnicwil 8y ago
Is it? That's disappointing. Who wins the world cup by the way? :-)
- duxup 8y ago
  England
spankalee 8y ago
Except for the fact that in 2018 it's actually not wonky at all.

robbrown451 8y ago

Honestly its getting rarer and rarer to find things like this, most things that reasonable people want to do "just work." You have to go to considerable effort to come up with a case like this.

mvdwoord 8y ago
What is the status quo on vertical alignment if I may ask..
- evan_ 8y ago
  Flex box https://philipwalton.github.io/solved-by-flexbox/demos/vertical-centering/ https://philipwalton.github.io/solved-by-flexbox/demos/verti...
  - lisper 8y ago
    The code shown on that page actually doesn't work, though the code in the github repo does. And this exposes the problem with the current state of the art: yes, you can probably get flexbox to do what you want [@] if you know how. But if you don't know how, trying to figure it out is still very hard. You should be able to write: <center>stuff</center> or <vertical-center>stuff</vertical-center> There is really no reason that should not Just Work. (The <center> tag has worked for 20 years, notwithstanding that it has been deprecated for most of that time.) --- [@] What if I want to put something in the lower left or upper right hand corner?
    - rvense 8y ago
      You should not be centering things in HTML, that's the stylesheet's job.
      - lisper 8y ago
        I have no objection to having a style sheet that defines what the <center> tag does. But it should at least be possible to have a center tag and a vertical-center tag. AFAICT it is not possible. At the very least you need both a center-capable container and centered elements.

jayd16 8y ago

This isn't really a spec thing. Its more a manifestation of undefined behavior. Even c++ compilers have undefined behavior.

tgummerer 8y ago
Especially C++ compilers have undefined behavior
- chiefalchemist 8y ago
  Yes. But are you going to to use 3 to 5 or mote C++ compilers on a given project? The worst part of these frontend issues is, ultimately, the UX can become inconsistent, if not mess. Given that nearly everyone interfaces via the visual UI, you'd think we'd have this sorted out by now.
  - ben0x539 8y ago
    If your project is a library, I'd expect that people are gonna use it with, like, maybe not 5 but probably 2 or 3 different compilers, and they're gonna be less diligent about upgrading their compiler versions than mainstream browser users.
    - chiefalchemist 8y ago
      Thanks. I wasn't thinking about it that way. Good point. That said, the browser's impact on UX is essential. A lot more people use browsers than compilers. You'd think the UX would matter by now.
  - ravenstine 8y ago
    Does a single compiler work exactly the same on every architecture? :D
- de_watcher 8y ago
  You're using the words wrong. The code may have undefined behaviour. For example, a race condition is an UB. Compiler won't invent locks that were not specified by the programmer in a code with some raw threads. As a result, CPUs will trash the memory.

krsdcbl 8y ago

So you're saying other dev domains don't have intrinsic glitches and oddities? ;)

billybolton 8y ago

Forcing the DOM, JS and CSS was a mistake. The problem was that you couldn't have alternatives. wasm is going to disrupt front end by allowing you to have a strong typed language that you can use to build your own framework like the good ol' days.

crimsonalucard 8y ago
Still gotta deal with the dom though. They need a root pixel level api to be made in conjunction to wasm, so people can restart from scratch.
- billybolton 8y ago
  Only once for the containing canvas. A direct access to the canvas pixel data and webGL offscreen rendering is all you need. With a few hacks, we're already 90% there. I expect by next year to see an explosion of this. There already are projects in Github that translated SDL and OpenGL to build web widgets.

sonnyblarney 8y ago

" I know this isn't actually true " It's true. A confluence of vague definitions, poor implementations, bad documentation ... and this is the web we have. It's the tip of the iceberg, and the painful life of anyone doing html5 work, it's 'not fun' for anyone who's been exposed to regular programming because the problems you spend your day solving mostly should not be problems to begin with.

shawn 8y ago
This is what us older people would like to believe. Meanwhile the young webdevs are having a blast ignoring us and building the apps of the future.
- King-Aaron 8y ago
  > having a blast ignoring us and building the apps of the future Building technical debt for the future I tend to think, which I guess is good for keeping future devs employed.
- sonnyblarney 8y ago
  My experience is that young web-devs don't even know the dystopian matrix they live in, and when they discover 'regular programming', in many ways their perspective changes. Both web and regular dev have their faults but the the King of Byzantium is HTML5.
- BigJono 8y ago
  Nah, it's mostly true (I'm one of those young webdevs), but I'd attribute the pain points in front-end development to slightly different problems than the state of browser inconsistencies and spec problems. IME 70% of the problems people run into are self-inflicted due to overengineered solutions. I spend a lot of time lurking front-end IRC channels and most of the problems that get posted is stuff that I have never had trouble with, with libraries I'd never even consider using, that I don't have the first clue how to fix without going back to square one and re-engineering the solution from the ground up. The advice given by people that do attempt to help with these problems is often awful and creates more confusion. For the most part, I don't think people realise that libraries add to the complexity of their software, rather than abstracting it away. Every front-end dev desperately needs to go and read the Law of Leaky Abstractions, because they're getting smoked by it on a daily basis and they don't realise. The other 30% of problems come down to what GP mentioned, ambiguous specs, browser inconsistencies etc. Stuff like the relationship between x-overflow and y-overflow, little flexbox niggles like different behaviour depending on if flex-direction is set to row or column etc etc. This stuff can often be worked around with simple but unintuitive fixes (usually some fuckery with negative marigns and such), the two difficulties lie in discovering the solution to begin with (there's boatloads of bad and outdated advice everywhere), and running into these solutions when they haven't been properly documented (usually the case if some junior programmer has just ripped the hack off SO without understanding the theory behind it). The secret to being good at front-end dev is to develop strategies to handle these problems, and to pick your resources very carefully (much as you would in any other ecosystem beset with noobs, like PHP back in the day). I believe (based on my experience) that it's possible to build very successful software with very horrible engineering. Good and successful aren't necessarily synonymous in the world of big VC money. A great example is this: I need two hands to count the critical failure bugs I've run into with Uber's products in the last year. By critical failures I mean things that have flat out stopped me from being able to use it. I strongly suspect (a subset of) their engineering sucks (sorry to anyone here that works for them!). But hey, I don't own a squillion dollar company so what do I know? ;)