rbrtsmith

So NodeJS isn't a framework it's a JavaScript runtime on the server-side. There are several frameworks and libraries built on top of Node such as Express and Koa. I'd definitely spend a bit of time getting familiar with Node On the frontend React is considered a library but I'd say it sits somewhere in the middle of a framework and a library. I'd definitely look into learning this, Angular is pretty horrible and getting less popular, Vue I don't like much either but it is gaining popularity but still way behind React in the job market. Most frontend jobs I see are asking for experience with React. The distinction between a framework and a library is a bit muddied and to be honest I don't think distinguishing is really that helpful. Both are essentially dependencies that we'd download via NPM and import to your application (assuming it's a JavaScript app). Many will suggest that React is a library and Gatsby, NextJS and so on are frameworks built on top of React. I suppose you can look at a framework as an underpinning for the whole project (or service) Although React sort-of does this also.

Create good content. Simple it will benefit SEO and people who do visit will return. No tricks, hacks or workarounds. Just good content (with well structured markup, mobile friendly, accessible etc)

That's exactly what we have done, we dispatch events like clicks and so on manually, which is straightforward with React, maybe less so if you have a WordPress+jQuery setup. So with that we get a fairly accurate representation.

Can you describe how the data is misleading? Like I say we employ experts in this field and didn't choose GA because others are using it, we do extensive research into any choice of platform be it content management, Ecommerce management, CI/CD and so on. Analytics is no exception. I agree with BlueDreamer that GA can be overkill for small projects but with GDPR you can still have high numbers, there are workarounds that don't involve the storing of cookies - you can programatically trigger events and detect which user they come from with a bit of server-side work.

I'm not directly involved with Analytics in current and any former roles however most places I've worked at have dedicated teams and most of those places use Google Analytics It must be decent given they have very experienced engineers working in that area and the companies being as large as they are have a vested interest in that data and improving conversion rates.

Neither are the way to go. WordPress is better than Wix. But Contentful + Gatsby for example will blow away a WordPress site in terms of security, uptime, hosting cost, ability to handle extremely high traffic, performance (just about every metric you can think of). This is because Gatsby will generate a static site (raw HTML files) that will load from Netlify for example where you can host a static site for free and because there's no database lookup when people visit your site it will load much faster and be more secure. If the DB goes down your website will not. How this works is that when you publish some content to Contentful (or another headless CMS) it will trigger a webhook which you can use to trigger a Gatsby build - Gasby will pull the data from the database and re-deploy the website. You can actually do the same with the WordPress API and combine it with Gatsby, however Contentful is a much better CMS than WordPress. I'd never use WordPress in the "traditional" way again and if forced to use it I'd stick to the headless output that it has. The only scenario I can think of where a statically generated website won't work are those that are highly dynamic e.g. - You are running large numbers of A/B tests - The website has quite heavy user personalisation It's worth noting that Gatsby can still fetch data on the client so it will work fine for a shop where the stock levels change rapidly, you can statically generate all the pages without the stock levels and then fetch the them on the client side when the application loads in.

Of course it's true nobody knows everything. You should know the knowledge required to get a junior role might seem vast, it is! but that's a drop in the ocean compared to the level of knowledge that a principal engineer who's being doing this for years might know. And even those guys don't know everything, far from it. A senior / principal engineer will be expected to take on most tasks and many they won't know how to solve it or have even used that tech before - they'll quickly learn as and when they need it. This is what I do now. I don't learn something because I might need it. I'll wait until I do need it and then learn. As I've said before most "full-stack" developers I've met aren't what I'd call really full stack. They're usually good at front-end or backend and know a little bit about the other side. I've seen loads of awful frontend code and UX decisions from "full-stack" developers who aren't really. I imagine back-end engineers have said the same. I'm comfortable creating my own services on the server side like a GraphQL services / lambda that talks to a DB, comfortable deploying that to AWS and setting up API Gateway etc, but I'm far from a full-stack dev because my skillset is so heavily weighted to the front-end. Being able to do a bit of the other side doesn't make one full-stack. IMO you should be as competent as the engineers in those areas and that's rarely the case. Ironically two people I work with are exceptionally good at both areas but still label themselves as front-end devs. Full-stack is often a marketing buzzword to try and ask for a higher salary, that's what I've seen. But as for learning the full-stack at least at a fundamental level I think that's a good thing but don't feel you have to try and become a full-stack dev. I'd still suggest being more niche for your first role and look at front-end or backend and specialise.

Just job titles, pretty much interchangeable. Some might argue that software engineering includes more architecture, infrastructure but I really don't think it matters. My Job title is a senior software engineer but I've also been a front-end developer, JavaScript engineer. I did similar things in all those roles.

I started a blog in around 2015 and stopped shortly after but having been working as an employee and contractor I didn't really need it to market myself, having big companies and strong reputation within them has strengthened my CV and references. I've had a few positions where I was headhunted based on people I've previously worked with wanting me on their team. If you're freelancing or consulting I think having a blog makes more sense. I'd only do it as a permie if it's something you actually enjoy doing which I do not.

If going with Mongo I'd also go with a service that provides that database such as mLab rather than attempting to roll your own. It's just not worth the effort. We use DynamoDB at work for our NoSQL database which works a little differently to Mongo but a good choice if you are using AWS for your hosting. There is also Firebase which I use for my personal projects, that's also NoSQL database as a service and is very easy to interface with the client side - I don't have a backend at all with this setup which means I can host it for free on Netlify and only have to pay for the domain name and DNS.

The PDF thing you can do in the browser or on the server side (with Node in this instance) there's pre-made packages that will do this e.g. https://www.npmjs.com/package/pdfkit

I should add that with JavaScript it works slightly differently to an interpreter. An interpreter like the one used in Bash scripts will interpret one line than execute then interpret the next line. JavaScript has what is called Just in Time Compilation (JiT) where the whole program is complied just before it gets executed, things like closures would just not work if it was interpreted line by line. There's some more information on it here https://stackoverflow.com/questions/7807235/javascript-just-in-time-compilation These are nuances however and knowledge of this isn't really required for day to day working with the language. The fact JS uses JiT is a detail you don't really need to care about. I see JavaScript as a compile target and I either write in the latest Es version or TypeScript and just allow the transpiler (Babel in my case) to handle the output and make sure that it's going to run correctly. (This is aside from the odd few polyfills that you might need to be added manually) For Node you'd want Babel to compile to the correct Node version target e.g. Node 12 if you're running Node on a Lambda function.

I guess what I meant was that I never have to interact with var. What stuff compiles down to doesn't really matter as it's not meant for human to read it. The same way there's little point to being able to read binary code as a web developer because we'll never read what our code is eventually compiled to.

Welcome to WDF Gavin

Oh of course you want the keyword, I guess not everybody here is using a linter as if you are something like that'd be caught immediately. True you want to know how var works, but even if you didn't and came across it you can spend all of about 2 minutes looking at MDN to find out what it does. I've not seen var being used anywhere for at least a few years though I'm fortunate enough to not have to touch very legacy codebases.

let and const are two of many features used in modern JavaScript. Typically you'd need to compile (often referred to as transpiling) this code AKA ESNext/ES6 into regular JavaScript (ES5) to be fully browser compatible, some features are already implemented but some are not so I'd recommend using a tool like Babel to do this job for you. @Jack Why do you suggest that ommiting var completely is a bad idea? If you are compiling down there is really no benefit to using var these days. I've used const and let exclusively for the past 3-4 years, if you're unfortunate enough to be working on REALLY old projects then it's good to know how var works. All of these keywords have what is known as lexical scope which means functions declared within a block can access variables outside of the function body, variables declared inside the function are not available outside of the function unless you leverage closure (returning those variables in some way) var declarations will be hoisted to the top of the function they are declared in and can be reassigned to let declarations are only hoisted to the top of the block they are declared in (block being curly braces) and can be reassigned const declarations are also hoisted to the top of the block and cannot be reassigned to (often confused to be immutable which isn't the case) If you are using ES6 with Babel then I'd always go with const unless you have a good reason to re-assign (which shouldn't be that often) in which case use let.

KayleighMiller is that your real name? and are you really from the United Kingdom? given can barely string a sentence together and your photograph is a stock photo

Nobody cares about certificates or whatever when they hire you. You'll need a CV that is appealing and you have gained some experience in the tech stack they use. Essentially they want to see you have the ability to add value, and for a junior the main thing we'd look for is enthusiasm and ability to learn. The bar to entry for frontend developers or backend developer is considerably lower to a full-stack developer. Perhaps do the TreeHouse course then focus on the area you enjoy the most - backend or frontend. Once you have a job spend a few years learning and then you might be in a better place to learn "the other side" so to speak and become a full-stack dev. Bear in mind this isn't the only progression. I know frontend developers who do little to no backend and still get paid a fortune and are very senior in the business. When I said Treehouse is all you need I meant that I just did their frontend course and used what I'd been taught to build some examples to demonstrate to employers. I didn't get any certificate for the course it was just a load of focused tutorials which for the most part were very good. I don't know if the full stack course goes into enough depth given the entry level for full stack developers is much higher.

As for Google crawlers they like sites that they can navigate around and see content without having JS enabled, however having some functions requiring JS that are not heavily reliant on content won't have a negative effect. That said the SEO agency that we're working with have said that Google can crawl pages that require JS, but those crawls happen less frequently. If you only update your website once a week it will be fine having content behind JavaScript, it only really matters for websites that update on a regular basis.

The website working without JS is mostly quite straightforward to do on basic websites but it really depends on what you are building. To replicate the Moonpig editor for example that would be pretty much impossible to do without JavaScript and would cost so much money to implement it really isn't worthwhile. Fortunately with frameworks such as React where you write barely any raw HTML, instead it's in what's known as JSX which eventually gets transformed into HTML you can do this work on the server so the user gets a raw HTML document sent and then the bundle loads and hydrates the application. If they have no JS they still see the page and will do server side routing, although some functions depending on how they're implemented will not work. Something like the Editor mentioned above is much more difficult to make work with JS turned off.

I agree with this. I'd continue using Gulp (in most cases) on an existing project that already has it. But if starting something new I'd use npm + webpack. I don't find writing webpack configs that fustrating to be honest, it's just a big JavaScript object, much like Gulp is a combination of functions. True the documentation for Webpack was poor but that's much improved and Webpack 4 does a lot out of the box already with sensible defaults built in. The thing is that Webpack is able to solve some very complicated engineering problems such as code splitting with just a little bit of config, to try and replicate this via Gulp or an alternative would be very challenging. It's also requires a bit of a mindset shift such as everything being imported being treated like a module such as JS, CSS, images, fonts etc.

Perhaps you are giving yourself problems that are too complicated given your level of experience, or perhaps the problems need breaking down into smaller ones. I've studied electronics and have a degree in sound engineering and I can tell you that the problems to solve in software engineering (at an entry point level) are no more difficult than electronics. Usually the point where it "clicks" is when a problem has been sufficiently broken down and you start to solve the parts one by one then at the point where you bring them together is when it typically "clicks". That said I've been doing this professionally for almost 6 years and there's still problems that I cannot solve day to day. Sometimes you'll have to experiment a number of ways or seek additional help. A developer isn't expected to be able to solve everything alone, we almost all collaborate., communication skills are actually critical, no one is likely to hire an engineer that is unable to communicate and work with others effectively. On a day to day basis it's quite rare that we have to solve a complex algorithm, you should just build stuff for the web as your learning. I'm not sure what it is you are doing but if you've been trying for 12 months or more and aren't in a position to get a junior job then your approach needs another look.

I'd go with Webpack although the two have slightly different jobs. Webpack is what is known as a bundler and it's primary job is to bundle JavaScript modules together into (traditionally) a single file that can be served up. If JavaScript modules (e.g. import/export syntax) is new to you take a read of https://www.freecodecamp.org/news/javascript-modules-a-beginner-s-guide-783f7d7a5fcc/ Gulp is basically a task runner. I haven't used it for ages because you can achieve the same directly in your package.json scripts section. See https://www.freecodecamp.org/news/introduction-to-npm-scripts-1dbb2ae01633/ In the modern way of working people mostly use a combination of npm scripts and webpack to build the frontend code and bundle. You'd use npm to run webpack. e.g. ``` "scripts": { "build": "webpack --production", "dev": webpack-dev-server --development" } ``` Other common tasks that you'd put in here are linting, automated tests (to make sure your application works), execute bash scripts and so on. You'd use Git for your version control and a service like Github to host the code. Github is really powerful and allows you to do things like run all the linting and tests when you push to a branch and will only allow merges to master when all of these pass (known as Continuous Integration / CI). When merged to master your CI can run again and once it passes begin a deployment to put it live (Known as continuous delivery). This way there are no manual deployments. It's a far more productive workflow than manually deploying to live and it's safer too especially when working as part of a team.

You're right about not touching core. When we removed parts of the dashboard / gave areas restrictive access it was almost all done though the functions file, never touched the core. Nowadays (If forced to use WordPress) I'd only use the REST endpoint (or GraphQL if it exists) then you're using WordPress to manage content and that only (which is what it always should have been IMO). Then you're frontend is not tied into anything WordPress related at all apart from fetching the data from an endpoint(s) that your wordpress setup exposes. This is still going to be a bit more painful that say Contentful to manage so unless a customer was specifically wanting a WordPress UI to work in then I'd give it a miss, but it's still a big improvement from the coupled mess that WordPress traditionally is.

You should definitely learn about databases, there are two popular types NoSQL (e.g. Mongo, DynamoDB) and SQL based (e.g. MySQL, Postgres). You'll want to learn about how this data is served e.g. JSON or GraphQL A full stack developer should be able to build a moderately complex application and should as a minimum have knowledge of the following areas. Deployment (Cloud based, AWS, Google Cloud Platform, Docker, CI/CD etc. There is a LOT to learn in this area) Databases, Backend - Microservices, FaaS, CMS, REST, GraphQL servers etc Frontend - HTML, CSS, JS (ES6, React), A11Y, UX patterns General - You should know how to write automated tests for your application with unit/integration/end-to-end tests, you should know how HTTP works in detail - what do the status codes mean, what about headers? cache-control etc etc. You should also have a good grasp of security - how do you handle authentication. You'll need to learn about capturing logs for front and backend systems (CloudWatch, Kibana, Grafana, SpeedCurve for performance monitoring). You'll need to know how Cookies work as they're used extensively. I've said this before and I'll say it again though: If you're looking for your first role then going straight for full stack is setting the bar very, very high. Most full stack developers have been working professionally for years before they really attain the level of knowledge to market themselves in this way. Of course the choice is yours but you really are giving yourself a mountain to climb which is made much harder if you aren't already working full time as a developer (Working with others you'll learn much faster than doing online courses alone.) I don't know anybody who's a full-stack dev that learnt it all upfront, they all got a job in a specialism and branched out. It's worth noting that you'll make things a bit easier if you focus on JavaScript as you can use the language on the client and the server rather than having to learn multiple languages.