5 ms·

I'm trying to build a real application and building real applications seems to need to sew together a whole bunch of real bits n pieces.

davidbanham 11y ago
I build real applications out of real bits and pieces in a modern javascript stack. I do it for a living, have done for a while, and manage a team of people in a company that does it. Don't get hung up on tooling. Things like babel, webpack, ORMs, graphQL, gulp, react, redux, etc etc etc. They're all useful things that have a place in the world. If you try to grok all of them all at once you'll send yourself insane. You don't _need_ any of them. Not a single one. Just write some code to solve the problem in front of you. Then write some more to solve the next one. Then come back and refactor. Then write some more code and solve some more problems. Keep going like that. You'll end up with a useful thing at the end of it. The thing you end up with may not be as modular/scalable/etc as something a seasoned professional could build with All The Tools. That's fine. It'll work. Importantly, though, some slightly muddy, homebaked code will meet your needs a hell of a lot better than a collection of half-understood learning about the most fashionable frameworks of 2015 and no actual code.
- throwaway000020 11y ago
  The paradox is that IMO the simplest way forward is to use the most modern tools. The modern tools and languages are generally there to make things easier. The trouble is that you need to learn those tools and languages before you can get to do it the easy way. For example, I really can't afford to program with any JavaScript language except ES2015 - I just don't have time to try to understand all the weird idiosyncrasies and underpowered crap that is older versions of JavaScript - I need to work with "JavaScript that makes sense" i.e. ES2015. But to do that I need to be able to wrap my head around - and fight all the myriad problems with - getting my ES2015 to compile using the webpack babel toolchain. It's a strange thing about programming that to understand the easiest way to do it you need to have a higher order understanding of the entire programming system that you are working with.
  - _cudgel 11y ago
    The paradox is that IMO the simplest way forward is... I feel like this statement is the crux of the issue. Have you considered that your opinion is simply wrong?
    - johansch 11y ago
      OP: It hurts so much when I run into walls. Everyone else: Stop running into walls then. OP: But they are so shiny. I think running into them is the best way forward for me. Please keep me a trick that allows me to run into them without pain. Everyone else: Eh..
  - throwawayaway 11y ago
    I'm with everyone else here that says you need to forget about the trendy junk and get the job done. Think brutally effective rather than elegant or modern. The simplest most old fashioned method that will work is often good enough. > The trouble is that you need to learn those tools and languages before you can get to do it the easy way. this is never some weird tradeoff, this is simply people selling you bullshit and you buying in.
  - hammerandtongs 11y ago
    Just get babel running without the webpack and modules gorp. I thought it was all a mess too and wasted a few hours. babel ./*js -s -w -d ../../target/ Move on to solving real problems with code. I agree with your sentiment that you should try at least get es2015 going though. Good luck.
  - jryan49 11y ago
    Bleeding edge tools have the drawback of people not fully knowing their flaws and drawbacks.
rifung 11y ago
By real application do you mean complicated? I'll second what others have said; you really don't have to use every framework. I really don't see anything wrong with building it with the simplest tools possible, and then if you feel like you need better tooling finding something which fixes your specific problem. Honestly most things are there to fix some use case, but in my humble opinion you're better off running into said use case before using some framework because you'll understand the problem it addresses and abstractions always leak.
mod 11y ago
I would start with "real applications" that do very simple things. Load in an instagram feed. Query some api and show results. Have one model and make a basic CRUD app around it (todo list?). Do that several times (seriously). Eventually, when you understand all the basic pieces, start tying two of those things together in one app. You'll learn new things. As you go on farther, you'll learn the whole stack piecemeal, in digestible amounts.

davidbanham 11y ago

I build real applications out of real bits and pieces in a modern javascript stack. I do it for a living, have done for a while, and manage a team of people in a company that does it. Don't get hung up on tooling. Things like babel, webpack, ORMs, graphQL, gulp, react, redux, etc etc etc. They're all useful things that have a place in the world. If you try to grok all of them all at once you'll send yourself insane. You don't _need_ any of them. Not a single one. Just write some code to solve the problem in front of you. Then write some more to solve the next one. Then come back and refactor. Then write some more code and solve some more problems. Keep going like that. You'll end up with a useful thing at the end of it. The thing you end up with may not be as modular/scalable/etc as something a seasoned professional could build with All The Tools. That's fine. It'll work. Importantly, though, some slightly muddy, homebaked code will meet your needs a hell of a lot better than a collection of half-understood learning about the most fashionable frameworks of 2015 and no actual code.

throwaway000020 11y ago
The paradox is that IMO the simplest way forward is to use the most modern tools. The modern tools and languages are generally there to make things easier. The trouble is that you need to learn those tools and languages before you can get to do it the easy way. For example, I really can't afford to program with any JavaScript language except ES2015 - I just don't have time to try to understand all the weird idiosyncrasies and underpowered crap that is older versions of JavaScript - I need to work with "JavaScript that makes sense" i.e. ES2015. But to do that I need to be able to wrap my head around - and fight all the myriad problems with - getting my ES2015 to compile using the webpack babel toolchain. It's a strange thing about programming that to understand the easiest way to do it you need to have a higher order understanding of the entire programming system that you are working with.
- _cudgel 11y ago
  The paradox is that IMO the simplest way forward is... I feel like this statement is the crux of the issue. Have you considered that your opinion is simply wrong?
  - johansch 11y ago
    OP: It hurts so much when I run into walls. Everyone else: Stop running into walls then. OP: But they are so shiny. I think running into them is the best way forward for me. Please keep me a trick that allows me to run into them without pain. Everyone else: Eh..
- throwawayaway 11y ago
  I'm with everyone else here that says you need to forget about the trendy junk and get the job done. Think brutally effective rather than elegant or modern. The simplest most old fashioned method that will work is often good enough. > The trouble is that you need to learn those tools and languages before you can get to do it the easy way. this is never some weird tradeoff, this is simply people selling you bullshit and you buying in.
- hammerandtongs 11y ago
  Just get babel running without the webpack and modules gorp. I thought it was all a mess too and wasted a few hours. babel ./*js -s -w -d ../../target/ Move on to solving real problems with code. I agree with your sentiment that you should try at least get es2015 going though. Good luck.
- jryan49 11y ago
  Bleeding edge tools have the drawback of people not fully knowing their flaws and drawbacks.

rifung 11y ago

By real application do you mean complicated? I'll second what others have said; you really don't have to use every framework. I really don't see anything wrong with building it with the simplest tools possible, and then if you feel like you need better tooling finding something which fixes your specific problem. Honestly most things are there to fix some use case, but in my humble opinion you're better off running into said use case before using some framework because you'll understand the problem it addresses and abstractions always leak.

mod 11y ago

I would start with "real applications" that do very simple things. Load in an instagram feed. Query some api and show results. Have one model and make a basic CRUD app around it (todo list?). Do that several times (seriously). Eventually, when you understand all the basic pieces, start tying two of those things together in one app. You'll learn new things. As you go on farther, you'll learn the whole stack piecemeal, in digestible amounts.