3

If you were in charge of developing an entire information system based on a web app, and you were the only one working on it... (lol)
Would you start with back end or front end?

Comments
  • 3
    i usualy go front-end first. html/css for layouts, then backend and back to frontend with js to tie both together.
  • 3
    I usually do backend first so I can build all the features and expand as I think of features.

    Also, then you don't need to write mock data for frontend
  • 1
    Thank you guys.
    That's what I was thinking :D
    Also found kinda funny and entertaining doing so using Angular 2 components.
    So later all I need is to add functionality to components already created
  • 0
    I'm not sure what's the best practice here, but I find this suits me best.
  • 1
    I like todo the frontend first. So being able to just connect the backen, as you work on that 😊
  • 2
    Backend first is best. Thus you don't have to tune the backend to fit the frontend, but rather tune the front end to fit the backend...

    Doing frontend first can result in less functionality. Doing backend first can result in a ugly frontend. And who cares abput a ugly website? Functionality is more important than beutity.
  • 0
    I do care about ugly sites.
    I'm a developer, but if I'm in charge of UI and UX, I refuse to create something I'm not proud about.
    I'm working with Django as backend, and already have all the classes.
    What's left to do is to deal with the API, which I will create using Django REST Framework.
    It's just I have no experience at all as a web developer, thus I know nothing about REST.
  • 0
    I did the backend first, so I could implement all of that functionality and give my front end something to talk to as I put it together.

    It wasn't perfect and I've had to change/add stuff as I've gone, but i much preferred not switching constantly and staying in one environment as much as possible.
  • 1
    @jstaiyo But if you think... would you rather create a beutiful, but buggy site, or a ugly, but well functioning site?

    Im more proud if I make a system with a solid backend and nice/useful functions, rather than useless eyecandy that just adds nothing to functionality, bloats the footprint of the site, and makes it incompatible with certain web browsers, especially older.

    Eg, if I have a deadline to keep, I rather spend that time on debugging and well testing of the backend so the backend becomes top notch, and rather make the frontend more quick'n'dirty and use older standards like HTML4.
  • 2
    I would start by defining the requirements and designing the architecture. Then design of high level api interfaces, then business logic, then expose it to frontend according to predefined contracts. :)
  • 0
    @sebastian I don't think anyone said anything about useless. A visual design can be used to communicate potential functionality to encourage exploration of capabilities, current status, not to mention feedback during an action. Additionally, choice of whitespace, visual hierarchies all make a notable difference in comprehending relationships in a UI. Animation can be used to draw attention to a changes element or something that needs attention. Or even to distract the user briefly while the system does something a bit more time consuming and prevent user frustration.

    I don't see any of that being useless.
  • 1
  • 0
    @mhall The problem is that sites overuse them, causing Edge to crash and such... Thus it become useless.

    Personally I think, if you code a front end, code it with a older standard so it render correctly in for example Edge, IE7 etc (without crashing or similiar).

    This means site becomes uglier.

    When my sites do something time consuming, I usually put a refresh button user has to press with some regular intervals to check how long the process has gone, and usually some estimate (so if the estimate is like 5 minutes, user knows he can press button after roughly 5 minutes, and either get the result, or a new estimate, like "15 seconds left")
  • 1
    Core first, shine last.
    Backend --> Frontend --> CSS and shit
  • 0
    Depends on the web app, if it's logic heavy I'll model on the backend first so I can get my head around it but if it's interaction heavy and I can get away with a mock api I'll do frontend first.
  • 1
    First I grab a whiteboard, design the front-end (the actual interface to the data), then the backend (in a way that is easy to attach to the front).
    After I filled up the whiteboard, I take a picture and start coding (from there it's mostly irrelevant what you do first)
  • 0
    @sebastian yes and it is easier to fix ugly than it is to fix missing functionality.
  • 0
    @sebastian I get your point, but it is kinda hard to define requirements and design a back end first in this case because the stake holder judges the system according to its view, so I gotta have something to show. And I definitely prefer working on the view alone first rather than developing the full system just to make a serious of changes. Makes me feel like I'm only wasting my time haha.
    I was worried about it being so wrong to start from there first
  • 1
    @sebastian Interesting. I've yet to visit a site that crashes my browser. I've seen site so choked with advertising junk that they were practically unviewable without an adblocker, but that was never due to CSS or the original site design. That was horrible advertising.

    As for coding to IE7 standards, surely you're not suggesting web developers limit themselves to designing with and testing for a 10 year old browser?

    No machine of mine has run IE in ... well more than 10 years. And I'm perfectly content to skip any part of the market that still is. It's just more trouble than it's worth.

    I understand that's not the case for every situation though.

    Anyway, my point was simply that an attractive UI, well executed, enhances functionality and adds value to the application, it does not get in it's way.

    A poorly designed UI gets in the way of the features we spend so much time implementing.

    Or we could just use the CLI in the browser. :)
  • 1
    IE7 has less than 1% market share.

    I think we can burry that dinosour.
  • 0
    @mhall haha yeah.
    I've never got to work on a project with more people than myself.
    I guess it's only a matter of communication and commitment from both front and back end teams
    Or trying to be good at both and do it all on your own.
    That's what I'm trying to do here, but not because I want to be alone.
    Here in Mexico people say "El que mucho abarca, poco aprieta"
    It means that the more skills you try to develop at once, or the more problems you want to fix at the same time, the more ineffective you become
  • 0
    Oh and there's also "Aprendiz de todo, oficial de nada"
    Haha that's a good one.
    It means that if you are learning different stuff all the time, you'll never get to be an expert in anything
  • 0
    @orijin Yeah maybe.... but IE8 is at least a requirement according to me, as its the latest version available for XP.
  • 0
    @sebastian yeah, ie6/7/8 together have a bit more than 2% togehter.

    It's true that's not a number to ignore completely, but considering the fact that Microsoft dropped support for XP in 2014 and the comming of bootstrap 4 dropping support for ie8, it safe to say ie8 if not now at least next year will be obsolete.

    Unless your project specificaly requires support for ie8 I wouldn't include it.
Add Comment