First off, goofy paint programs are NOT design tools, no matter how many ignorant artsy-fartsy types under the DELUSION that they are "designers" might think so in their utter and complete ignorance of accessibility.
MOST of the things you mentioned -- such as SaSS, Bootstrap, Node, Angular -- are a giant middle finger to efficiency, good practices, and accessibility when it comes to building websites! As an accessibility advocate, your simply saying "full stack JS developer" made me CRINGE at the idea of even allowing you anywhere NEAR a front end as to even reach that point, you would have had to tell the "unwritten rule of JavaScript" to take a flying leap!
... ok, I see that look on your face. What is, the "unwritten rule of JavaScript"?
If you can't make a fully working page without JavaScript FIRST, you likely have zero damned business adding scripting to it!
Mind you, that applies to WEBSITES. Applications built with web technologies are a whole different ballgame since you pretty much KNOW that scripting is available if it even runs -- but with websites, as the old saying goes "this is the Internet, the only thing you know about who will visit your site is you have no clue who will visit your site"
That's why accessibility is job one -- and that means, semantic markup, separation of presentation from content, progressive enhancement -- basically things that you generally won't have if you start out screwing around with a paint program or WYSIWYG focusing on screen appearance before you even have a working layout and codebase based on the content.
To me web design is like architectural design, mechanical design, electrical design, and so forth. There are standards, specifications, and guidelines you MUST adhere to if you care about the end result actually being useful to users. If you don't know about dynamic fonts and why they are important, elastic layout and why it's needed, semi-fluid layout and the reasoning behind it, then by the time you get to responsive layout you'll have tied both hands behind your back... and NONE of that is stuff you can really develop in some goofy paint program.
To really dial in better what to tell you, I think we'd need a better idea of just how much HTML and CSS you REALLY know... but my page here explaining the approach I advocate may be a bit of an eye opener for you:
cutcodedown.com/article/progressive_enhancement
I'd also suggest reading my "what's wrong with your website" article, as well as the one talking about frameworks being incompetent nonsense.
For those afraid of following links, generally a PROPER DESIGN methodology should start with the content or a reasonable facsimile of future content, organized in a flat text editor to make sense as if HTML doesn't even exist. You then mark it up semantically - "semantic markup" just being a sick euphemism for "using HTML properly" we use so as not to upset the 4 tranny and 5 lip-service short bus re-re's who still have their cranium wedged up 1997's rectum - using your tags to say what things are, NOT what they look like. Since that's the SEMANTIC stage semantically neutral tags like DIV and SPAN have no business in there. Much less if you know how to use numbered headings SHOCK properly HTML 5's garbage SECTION, NAV, ARTICLE, MAIN, HEADER and FOOTER become pointless redundancies.
Only once you have semantic markup of content in a logical document order do you start adding CSS to make your layoutS -- yes, PLURAL. I usually start with a screen media pre-CSS3 desktop layout... a lot of people will say to start with a mobile layout, and I consider that utterly and completely back-assward! Small displays are what we CAN target with media queries... why would you start out with what you can target and modify -- doesn't it make more sense to start with what you CAN'T specifically target?!? Since this is the layout stage, THIS is when you add DIV and SPAN but only when you need them -- either to group tags for mass selection, or as containers for style; WITHOUT saying what that style is. Even your id's and classes should say what things are or why they are receiving style and NOT what you want it to look like. (which is why OOCSS and garbage like bootcrap basically just smear manure all over sites built with them!)
Again, separation of presentation from content. In that same way if you use the <style> tag, you're doing something wrong, and the style="" attribute should be used with an eyedropper only for when that style is conveying content, NOT appearance.
See, there's more to a website than what it looks like on screen media... Not all users are sighted, search engines don't have eyeballs, many sighted users require a degree of assistance. All legitimate concerns that a REAL designer takes into account, that the artists under the DELUSION that they are designers are woefully ignorant of!
From there you use media queries with testing your content to see when it breaks, and making the site responsive to adjust for that. Since an ACCESSIBLE design (aka one not telling users to go plow themselves) should be built with dynamic fonts (% or EM) with elastic layout (padding, margins, widths in EM) and semi-fluid (a max width to prevent long lines from being hard to follow) based in elastic, so too should most of your media queries be elastic (measured in EM)! That way when the system or browser default font-size is non-standard, your layout adjusts accordingly to the available space.
... mind you, that's just the layout stage. The "make it pretty" colours, fonts and other such decorations should be the LAST part of the process, not the first. That way you know the style is viable to the content... that it can adjust TO any content so you aren't forced to write content to the layout. That last one being a common failing in the shlock vomited up by the PSD jockeys who THINK they know what design is...
Then and only then should the fully functioning properly written fully accessible page be enhanced with JavaScript... If needed or desired; quite often it's not... quite often JS is a waste of bandwidth, time and effort for stuff that might "wow" a first time visitor, but by the time they've come back twice you're already pissing them off.
It's called progressive enhancement, you start at the bottom and slowly add stuff, so that should ANY of the fancy bits fail to function, the page is still useful to visitors REGARDLESS of what browser they are on. Hence the page "gracefully degrades" on legacy user agents, non-visual user-agents, people with stuff blocked or unavailable in their browser, etc, etc...
... and to anyone out there who thinks that stuff doesn't matter, be thankful you're not making websites for certain governments, banks, or public utilities where in places like the UK you can be fined for failing to meet certain minimum functionality and accessibility norms!
Bottom line, you want to be a REAL designer and not some artsy-fartsy snake oil doctor scamming nubes like the halfwits, morons and fools that fill the template whorehouses like themeForest or TemplateMonster? READ (and comprehend) the WCAG -- BOTH 1.0 and 2.0, take the time to understand them... Go through and read articles on NNGroup regularly. Research common failings like "False simplicity"...
More importantly, understand (and this is the hard part) that as a REAL designer, you're not creating the style to stroke your own ego, nor are you even designing to the wants and needs of the client (which is why you often have to educate the client) -- you are designing to meet the needs of visitors to the site; hence why "CONTENT FIRST" development is the same thing as "VISITORS FIRST" planning... and why most of the "gee ain't it neat" scripttardery people sleaze onto websites is a waste of bandwidth more prone to pissing off visitors by getting in their way than it is actually making the result more useful.
IT's the difference between trying to scam people with $10 templates that are unfit to even be on the web, and charging a grand a pop for a working coded layout that actually qualifies as quality work... Quality work that won't end up tanking the client's site thanks to telling users with accessibility needs (or even normal needs) to sod off, wasting bandwidth increasing hosting costs, or resulting in fines for failing to meet the requirements of laws around the globe!
Lemme just close with some "required reading":
http://baymard.com/blog/false-simplicity
456bereastreet.com/archive/200704/lame_excuses_fo…