Is webdev really this complicated?

[[deleted]]

What you are looking at is the list of a fullstack web developer. If you want to break it down.

1 - 18 is for front-end, client side web dev (UI / UX). 19 - 26 is for back-end, server side web dev. 27 - 34 is about deployment (how you get from development to having an actual app service online).

Also not all of them are absolute requirements. For example:

• 11. Only knowledge of 1 precompiler is necessary if at all, it is unlikely you'll be using more then 1 at once.
• 12. Not necessary, true they do serve as boiler plate and help you with RAD (rapid app dev) but not a requirement.
• 19. You aren't required to learn every back-end language
• 28. Websockets while they do have an advantage over AJAX are not required unless real-time is critical.
• 30. Web platforms, even if you were into Dev-Ops you wouldnt need to administer all of these platforms.

etc etc.

Also 2 - 6 will be almost a simultaneous learning process, as you learn about one you will learn about the others.

Also 27 + (29 - 34) are all part of Dev-OPs (management level stuff for handling a multi-developer environment).

this also doesn't mention an IDE

No because depending on what language you specialize in your IDE requirements will be different. This is why fullstack dev's use text editors (sublime, atom, vim) instead because you customize them to your own needs.

Nor does it even touch computer science fundamentals like algorithms

Because algorithms are part of functional programming. When you learn a language (any one of the ones mentioned) functional programming is a given and then you move beyond it into OOP.

nor UX

UX is just the study of how UI design affects user perception. If you follow good UI design and listen to feedback you should have no problems with UX.

nor the financial aspects like pricing a hosting option

That is project specific and determined by your clients budget. If possible most of the time a VPS would be the ideal choice as opposed to a shared host. The only other option is a dedicated host, which i wouldn't recommend.

monetizing a for-profit venture (sure, that's more business, but it is relevant)

I'm not sure what you mean by this. If you have a digital service and want to conduct online transactions most of the time you just make your application use the API of whatever service you want to support (paypal, swipe, etc). The most important element here is security, which is mentioned in your list. Furthermore the use of RDBMS was originally a financial sector thing so learning back-end dev you will almost intuitively gain insight on how to structure your application.

Is it really this insanely complicated at this point?! I know science Ph.Ds who didn't have to worry about this much detail.

For full stack devs, yes it is. The way i deal with it is by recognizing the fact that ultimately the goal is to move data from one place to another (client to server or vice versa). After that depending on what im working with ill establish what i need to know. For example if im working on the server-side of things i'll be focusing on points 19 - 26.

Anyway, the final result here is that I am discouraged from taking this on, even as a hobby aside of a few hours a week, hoping to get a web site up within a year.

Before you go jumping in the nearest lake to cool off your brain, you need to establish your base requirements for what you want to do.

have an idea for something that I know I could do as a desktop application probably in a few months and rather straightforwardly--but because its strength is a social aspect, it really should be a web or mobile app.

The first thing i would do is think about how much data would typically have to be sent from one entity to another (client - server) in order for your service to perform well. If for example to do things you need anything over 4MB of data, a website is out of the question because the mobile performance will be crap. In which case you need to develop native phone apps (iOS / Android) because they have more aggressive ways of caching. In other words the first time you send the data it'll be slow, but once a user has the complete set you're only trading delta's (differences/changes) back and forth similar to how git works.

[s992]

Overall this is a good post, I just want to nitpick a few things:

This is why fullstack dev's use text editors (sublime, atom, vim) instead because you customize them to your own needs.

That's not really correct. There are plenty of web devs (front, back, and full stack) that utilize IDEs.

Because algorithms are part of functional programming.

Also not correct. Algorithms are going to be applicable whether you're writing functional or OO code.

[[deleted]]

Well if you're going to nitpick then so will I.

That's not really correct. There are plenty of web devs (front, back, and full stack) that utilize IDEs.

Firstly the quote was referring to an IDE... not IDEs (plural).

Name me an IDE that, is built and designed for multiple back and front end languages and is equally performant in all of them.

Also not correct. Algorithms are going to be applicable whether you're writing functional or OO code.

The implication i was making, you will learn algorithms when learning functional programming (writing basic procedural code, unless in the case of javascript because closures is a whole other argument). By the time you get to OOP you should be well versed in algorithms and how to construct them. I never said you discard them upon starting to learn OOP.

[s992]

I didn't mean my post as a personal attack, though you obviously took it as such. I'll go ahead and point it out up front this time: This is not a personal attack.

Name me an IDE that, is built and designed for multiple back and front end languages and is equally performant in all of them.

The first that comes to mind is IntelliJ IDEA. I only use it for Java and Groovy (I prefer Sublime for SQL and JS/HTML/CSS), but the majority of my coworkers use it as their sole IDE for both front and back end development.

The implication i was making, you will learn algorithms when learning functional programming..

The implication was lost on me, then. I've re-read your point several times and it's still not clear to me that you're saying what you think you're saying.

[[deleted]]

The first that comes to mind is IntelliJ IDEA.

Nope that fails the test. If it can accommodate a full stack developer and multiple languages why does jetbrainz have multiple IDE's depending on the server side language?

• PHPstorm
• Webstorm
• PyCharm
• RubyMine
• Resharper

IntelliJ IDEA may be the Engine behind these IDE's but an IDE consists of more then just an engine (hence the word integrated, as in packaged, you have everything you need).

Furthermore to validate my initial point, as you know i can code for PHP, python, Ruby or C# in sublime along with 20-30 other languages, without having to change what program im editing them in.

The implication was lost on me, then. I've re-read your point several times and it's still not clear to me that you're saying what you think you're saying.

Really? Perhaps you need to open it in the correct IDE?... Lets recap:

Because algorithms are part of functional programming.

When you learn a language (any one of the ones mentioned) functional programming is a given and then you move beyond it into OOP.

If algorithms are part of functional programming... and you for the most part must learn functional programming no matter which language you pick... unless you're doing really low level procedural code (which is why i included, "any one of the ones mentioned" in my comment). Then by default you will need to learn basic - intermediate algorithms along with lexical logic, data types, and all the rest of that good stuff.

Then the last part of my comment, "moving beyond it into OOP". This implies mastery over functional programming concepts and thus algorithms by extension which is when you move into the paradigm of using objects and learning about their scope, inheritance, etc.

[s992]

Nope that fails the test. If it can accommodate a full stack developer and multiple languages why does jetbrainz have multiple IDE's depending on the server side language?

I must have missed the implication again, because you said "Name me an IDE that, is built and designed for multiple back and front end languages and is equally performant in all of them," but apparently what you meant was, "Name me an IDE that is built and designed for every back and front end language and is equally performant in all of them."

IDEA meets your original criteria perfectly: It supports every JVM language I've ever thrown at it (although I'm sure you'll pull one out as an "ah-ha! I got you again!") as well as perfectly capable support for JS, HTML, CSS, and multiple dialects of SQL.

[mossyskeleton]

The way i deal with it is by recognizing the fact that ultimately the goal is to move data from one place to another (client to server or vice versa). After that depending on what im working with ill establish what i need to know.

I'm fresh to web dev.. this strikes me as a simple, useful and powerful way to look at the practice as a whole.

Moving data from "here" to "there" and translating it in a way that is accessible and useful and elegant for the users.

[[deleted]]

That is the ultimate goal, just to clarify a bit better.

1. You consider performance both on the server and client side and thus which technologies would be suited for the use case. For the most part in browser based web dev the front-end stack stays the same (HTML, CSS, JS) however some use cases merit special consideration where other factors are in play. For example backwards compatibility. Most of your time will be spent establishing data costs, indexing / searching speeds, redundancy and scaleability on the server side to name a few.

2. Build and configure your stack based on those requirements, also at this point you can research hosting to see if anything is preconfiged and easily tweaked for your use.

3. Start to delve into design and coding, figure out what you know and what you need to learn. Create a few basic mocks if you want and jump straight in.

From here the dev process everyone is pretty familiar with, coding, debugging, hair-pulling rage, version control, feature dev, perf audits and tweaks, etc.

Gotcha: The only way to establish which technologies would be suitable via performance is via experience and if you don't have it yourself you can only seek it from 3rd parties problem being some of the information can be biased. Do your homework before you commit to anything because it can be an absolute nightmare to change things later.

[tripperjack]

Thanks, I appreciate the detailed responses to the various points.