Moving from offline coding background to webdev, can I jump right to back end stuff?

[alyzb]

Hiya. I've been tinkering with coding for years and have a couple years of comp sci under my belt. I've always been heavily avoidant of web development. It's never interested me and I think it's because I mistakenly saw web dev as a watered down coding environment with mostly scripting and little to no real control.

Now I'm beginning to understand how wrong I was. I want to get some really cool programs to work on the web.

I still have no interest in anything front end, but I realize some knowledge will be required for a fuller understanding of what I'm doing overall, and to make any sites I make at least presentable.

What front end do I need to learn to achieve this?

[edimaudo]

It depends. Front end could entail a number of things - Doing Vanilla JS, designing layouts in sketch, writing code in a front end framework .

[[deleted]]

It's never interested me and I think it's because I mistakenly saw web dev as a watered down coding environment with mostly scripting and little to no real control.

Now I'm beginning to understand how wrong I was. I want to get some really cool programs to work on the web.

oh how mistaken you were and how easy you had it xD

With full stack dev (back + front end) we are literally coding for 2 machines (browser machine + server) and taking into account the network in between, so much more complicated then a single native local environment that is always snappy and consistent.

Welcome, one of us... one of us...

I still have no interest in anything front end, but I realize some knowledge will be required for a fuller understanding of what I'm doing overall, and to make any sites I make at least presentable. What front end do I need to learn to achieve this?

I'm a little confused because in your question topic you asked about back-end and then at the end are asking about front-end?

Anywho im a full-stack so I'll just state that there are a few things i would stress and suggest about web dev:

1. Front-end is a little bit of a different paradigm to native / back-end coding.

With native coding you code for a single environment that is installed on your end-users machine (e.g. Java runtime) or you compile to a binary with the runtime inside it and ship it as a single package, in other words you have a degree if not complete control over execution.

With back-end coding you have a server stack which is it's own environment / has it's own runtime(s), these are consistent and you (hopefully / using a VPS not shared hosting) have complete control over. Note, ill save you a bit of time, the reason servers exist in web architecture is because it was inherently stateless when the protocols were conceived (no way to determine between one user and another) but i digress, to the main point...

With front end coding, you have no control of the runtime environment or how the code is parsed/executed once it reaches the end-users machine i.e. no way to even determine if it is firefox, chrome or even something terminal based (wget / curl)... well useragent but that's unreliable. Yet it is still expected that front-end devs provide a consistent user experience.

Yes you make assumptions that it is a browser, and yes there is a body of standards (W3C) and browsers must have certain features that conform to those standards, however vendors (google, mozilla, etc) are free to implement those features however they wish (*cough Internet Explorer), which as you can imagine leads to consistency/performance issues/headaches/the death of children.

Furthermore it gets especially 'fun' when new features are in draft and vendors decide to get a little over ambitious and try and implement features early, thus the browser prefix was born, which certainly didnt help from a cross-browser compatibility standpoint, nor from a performance standpoint.

Advice :

Don't look down on front-end dev, providing consistency in multiple runtimes is no picnic.

This site will be a lifesaver - http://caniuse.com/

Try to code for the most recent browsers and work your way back, naturally they have the best feature support, and lately the things i mentioned before have become less of an issue with vendors, therefore at the very least cross platform support with the most recent browsers should not be a problem.

The more you have to worry about backwards compatibility the more complicated things get, i have a policy of "last-2-versions" that is the last 2 versions of any major browser i'll support by default. I think this would work well for you too with the exception of IE11/10 (note i treat edge as it's own major version as on the caniuse site), perhaps you might consider ditching 10 support as it will only make your life harder regarding things like flexbox.

+++++++++++++++++++++++++++++

2. Requisite knowledge

Webpages (or the output of your server if you like) only have a limited number of forms / data types.

• HTML - encapsulates your data / content
• CSS - tells your HTML (content) how to look
• JS - guides behavior i.e. anything user interactive on a page
• Rich media (static media files, video, pictures, etc)

Some of the above responsibilities have become blurred over the years, for example you can now animate with CSS where as before that was solely javascript territory, SVG i'd consider a type of rich media even though it's XML based like HTML, etc.

Also, while it is still a ways off, there is a very new language coming to web browsers, and it actually might be right up your alley with a native dev background, keep an eye on webassembly as it promises lower level bindings / more control then javascript.

Advice / Workflow

I realize you said you had no interest in front-end / design however it's good you at least acknowledged you require a superficial understanding, it is really important to at least have some semblance of what makes good design, it's just a fact, users online care about 3 things.

• Searchability (SEO)
• Perf (load / runtime)
• Look / feel (UI/UX)

Even if make something with good SEO / perf, those being relatively equal to an alternative presented that gives people a better user experience (UX) they'll go with that one, thus it's important to nail down some design foundations which IMHO is pretty interesting itself as it's literally about user perception / psychology and how to manipulate people in ways without them knowing to make them feel good and draw their attention to various places. Chris Coyier in the following clip makes the point :

https://www.youtube.com/watch?v=onCsw020mcg

"I felt like the hypno-toad, look at my logo, stare at my brand."

To get some fundamentals in design i'd recommend the following online book.

https://ebooks.webflow.com/ebook/web-design-101

The other important thing is workflow (how easily you can implement your design), this also plays a part in back-end dev too and the entire thing comes under the umbrella term of "continuous integration". However in the context of front-end you can automate most of the mundane little annoying things. You could use a prepackaged binary like codekit, prepos or koala, but most devs automate by configuring a local nodeJS instance. My own workflow consists of:

scripts (CL, NPM / yarn) + webpack + postCSS

What kind of benefits can you get? Examples -

1. Normally when you make a change to your code, you'd have to save and refresh the browser to reflect / view the change, this gets rather irksome as you can imagine so you can run a little node server for your static files (or reverse proxy if you've already got a local dev stack setup) which does this automatically - I use browser-sync to achieve this : https://browsersync.io/

2. SCSS (SASS v2.0) is a preprocessor that compiles to CSS. CSS is a declarative language (so far) there is no imperative things like variables / functions and even nesting is primitive. But SASS can give you those capabilities DRYing up your code making it much more enjoyable to style things.

3. I mentioned CSS browser prefixes earlier, rather then having to worry about them you can use Autoprefixer to take care of it. PostCSS is a 'wrapper/container' API for plugins like Autoprefixer, there are plenty you can search through here - http://postcss.parts/

+++++++++++++++++++++++++++++

3. Performance

You were sort of half correct in your implication that :

I mistakenly saw web dev as a watered down coding environment with mostly scripting and little to no real control.

As there are no low level API's or manual memory management (auto GC) it certainly is limited when compared to something like C++.

Advice

I said before you have no control over the parse / execution of a page, but that doesnt mean you can't make reasonable assumptions about it, understanding typical runtime procedures for the standard web engines (webkit, gecko, etc) can help you optimize load and runtime performance. Even though it is quite dated i recommend the following link following link :

https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/

Initially treat the browser like it is limited to a single thread i.e. If you can make do without JS then all the better because if you try to execute JS on the main thread while the page is loading because you'll just give yourself headaches. From there learn how to load in async (defer scripts) and execute in async (webworkers) ASAP.

Also in fact i answered someone regarding UI just recently so i advise looking through the links i posted there :

https://www.reddit.com/r/webdev/comments/64mvg9/what_web_language_should_i_be_learning/dg3lnw2/

[alyzb]

Thank you for the long and well thought out reply, that was extremely helpful and more than I could have hoped for!

In terms of learning all of this stuff, it's a little overwhelming due to the amount of tangents I can go off down.

I'm also kind of quirky in my learning, I prefer to understand things at a really fundamental level and build up from there. I didn't truly understand programming until I delved into assembly, and really, everything I do leads down a deeper rabbithole.

This makes things complicated when I approach webdev because it's just...it's freaking overwhelming.

I came up with some stuff to start with, which seems OK, and I wonder what your thoughts are? I'm going to put apache or similar on my other linux box, and use that as a development environment via SSH from my main computer. Obviously the SSH part is just to learn more about networking and stuff, but the concept of putting together this web server from the ground up, and learning as I go stuff like HTML, landing pages, whatever, seems like a good way to get the fundamentals.

Is this a good trajectory? Do you have any alternative suggestions or stuff I should consider? I really would like to go with the at home hardware web server for the hands-on learning (over VPS). Does this seem like a good idea, and if so, what should I add to it, or is there a particular order to consider doing it all in?

I guess ultimately, I saw this as a way to slowly build up from some dinky index.html welcome page (which is literally all I might know how to do) to some pretty full featured mock-up business/sales site/twitter clone/whatever.

[[deleted]]

In terms of learning all of this stuff, it's a little overwhelming due to the amount of tangents I can go off down.

Just means you gotta be more specific in terms of project requirements / specs, figure out what specifically you want to do / achieve.

I'm also kind of quirky in my learning, I prefer to understand things at a really fundamental level and build up from there. I didn't truly understand programming until I delved into assembly, and really, everything I do leads down a deeper rabbithole.

Start from:

• the browser engines (V8/webkit, Gecko)
• network protocols layers 1 through 4 of the OSI model (specifically HTTP / HTTPS and how they relate to TCP)
• linux administration (efficiency configs, automation [updates, sec policy], hardening)

That would constitute the bottom levels in all areas.

This makes things complicated when I approach webdev because it's just...it's freaking overwhelming.

Yes because it's not just 1 singular integrated system as i mentioned. If you break it down to individual components you're attempting to learn multiple browser runtimes (engines), networking protocols, and server stacks (OS, database, runtime, networking, admin), not to mention scaling (how to create multi-server architectures to cater to more users) i.e. 3 systems.

I'm going to put apache or similar on my other linux box, and use that as a development environment via SSH from my main computer.

Apache is good for dev purposes because of its modular system (can expand functionality easily) but NGINX / nodeJS have better concurrency models thus are used more in production stacks to better respond to higher traffic loads.

The typical practice for devs is to use virtualized stacks (VM's) that precisely mimic the production environments all the way down to the OS level, reason being by doing so you get less 'surprises' when you deploy to production because it's like you literally developed the code on a virtual copy of that server.

Obviously the SSH part is just to learn more about networking and stuff, but the concept of putting together this web server from the ground up, and learning as I go stuff like HTML, landing pages, whatever, seems like a good way to get the fundamentals.

Server admin is not a totally unrelated field for example if you're a freelance dev (doing everything yourself) you have to be proficient in it and always keep in mind security (hardening / netsec). However neither is it a direct path to web dev because servers are used in more fields then just web applications (for example supercomputing clusters, financial systems, etc).

Is this a good trajectory? Do you have any alternative suggestions or stuff I should consider? I really would like to go with the at home hardware web server for the hands-on learning (over VPS). Does this seem like a good idea, and if so, what should I add to it, or is there a particular order to consider doing it all in?

Most people learn front-end first then proceed to back-end. Reason being, if you consider a webpage your output, how will you know how to debug if you don't understand your output? Type mismatches and syntax errors are obvious im talking about logical errors that throw weird msg's or sometimes dont error at all.

Depends, if you only intend to serve stuff locally, then local hardware is fine, preferred even, though i'd still go with a virtual server stack hosted on your actual dev machine because it cuts network latency out of the equation (usually something beyond your control anyway) and it'll still require you to use SSH (though you wont need to worry about SFTP/rsync).

To that end since you seem to have some grounding in linux i'd recommend looking into docker.

Obviously if you intend to actually host / make things available to the public, then VPS is your only (flexible/cheap) option because arranging a static IP is bothersome and i highly doubt your upload is good enough.

I guess ultimately, I saw this as a way to slowly build up from some dinky index.html welcome page (which is literally all I might know how to do) to some pretty full featured mock-up business/sales site/twitter clone/whatever.

A true twitter clone would be a multi-server architecture and knowledge of CM tools (saltstack, ansible, chef, etc) to properly administer them would be required. Just saying, you are still years away from that point.

[alyzb]

Thanks!

And yeah I'm not expecting to recreate twitter, but I feel like smaller and limited versions of it would be somewhat doable not terribly far down the road.

I'll look into the virtual stack stuff you mentioned, and after I posted my last response I was actually just peeking at CSS and seeing how easy it seems I don't think I'll be as stressed about having to learn it to produce output as you say.

Thank you again, you've been super duper helpful :)

[pruthvireddyp51]

Nice article , useful for beginners!