Oh, wow, I hadn’t realized the Character Viewer (the window opened by that shortcut) had gotten so much easier to use in more recent macOS versions – or did I never notice that top-right button that converts the floating palette into a popup near the cursor?
Opening the Character Viewer as a palette window keeps keyboard focus in the text field you are in, so it requires a lot of mouse usage to search for and to insert the character you want. I see that after toggling the Character Viewer to the popup mode (the default mode on macOS 10.15), the search field is focused after pressing ⌃⌘Space, the arrow keys select a character, and I can insert the selected character with Return. That’s much more convenient.
I know that I didn’t justify my argument against React. I don’t know React, and I decided not to talk bad about it.
What I wanted to clarify is that I can do my everyday tasks without React. I am working in the web industry for almost ten years, and I have been part of many website projects, some pretty big ones. Knowing HTML, CSS, JavaScript, and its possibilities is hugely undervalued these days. I don’t need to know 0(n) or similar algorithms to build a site that is looking good, performing well, and is accessible to most of the users.
That is just my opinion, and I wanted to make a statement. Knowing React, algorithms, or anything similar might get you a job, but it doesn’t mean you could build a well-performing, fast, and easy to use and understand website.
I want to thank everyone for their comments. I appreciate the passion in these discussions, and I know everyone is talking from their point of view. I just wish to see more sites that aren’t bad and that follow the best practices.
I wish the conclusion had named the best 3 sites. It’s never a bad thing to be positive and call out the sites and developers doing the best work of the lot.
What are some tips for learning web development that are unique to web development? IE tips like “focus” and “stay up to date” apply to all areas of computing.
For backend stuff: build a simple HTTP (1.1) server. Pick your language of choice, start out with something ultra-basic like listening on a socket and responding to everything with a hard-coded 200 OK. Then layer in more complexity: parse the method out of the request, say, and only respond 200 OK to a GET, and 405 to everything else. Keep going, adding little bits until you get up to something like being able to have a directory of HTML files and serve up the right one in response to the requested URL, or 404 if not found. Keep going: see if you can implement basic CGI support – getting enough of it right to be able to run simple scripts old-school cgi-bin style isn’t that hard, and several programming languages’ standard gateway protocols are still very CGI-ish, so it’s a useful programming model to understand. Maybe for a “final project” build a simple MVC-ish framework with full separation of concerns: URL routing, data-retrieval, rendering.
For frontend, similar things. Start with a blank HTML file, and work your way up to something moderately complex, marking up elements appropriately. Add in CSS and fiddle with different things until you understand what the “cascade” part is about, the layout algorithms, and so on. Pick a site you think looks nice and start poking at it in your browser’s dev tools, see if you can find out how they got that nice-looking layout to happen. Or start adding basic JavaScript. No framework, not even jQuery – just play with the language, getting familiar with the low-level DOM APIs. Final project: pull it all together and try building a small offline web app like a to-do list using local storage and auto-updating UI based on application state. Same ideas as backend here about learning separation of concerns.
Extra credit: build the same app from both frontend and backend, and hook them together.
Or, more succinctly, I always try to push people to understand the web platform itself – HTTP, HTML, CSS, JavaScript, how dynamic web applications work and are structured in code – because that knowledge is permanent, while particular libraries or frameworks may be here today and “who even uses that anymore” tomorrow.
There’s a difference, to me, between “iterate on a thing” (generic advice, not super helpful) and “here’s a particular thing to iterate on, with suggestions for the first couple iterations and what you’ll learn from it” (specific advice for a particular field of programming, hopefully helpful).
I know these bits of advice applies to all aspects of learning, but I still think it could be useful to beginner web devs.
If you ever tried to learn a new skill, I bet you spent time playing around with something unrelated. I wanted to emphasize that keeping the focus is critical to make progress more quickly.
Regarding other advice, I wanted to sum everything up and encourage beginners to keep learning and improving their skills, but to make a plan on how to do it. Without a plan, you could easily get discouraged or lost.
Think Google Sites, Squarespace or Wix. These are WYSIWYG interfaces where you drag and drop text boxes, images, forms and so on to create pages. They are technically CMSes, but a lot less sophisticated and but more easily made to show a custom page than a true CMS like drupal.
Wow, cool! Do you know by chance if there’s a builtin shortcut that would let me easily insert an em-dash (—) on Windows? Can I maybe somehow enter it quickly from keyboard through this Win+. dialog?
Yes, on Windows there are Alt code shortcuts. It requires a numpad keyboard, with Numlock turned on. If you’re on a Laptop, most should allow you to simulate the Numpad by pressing Fn + (you’ll have to look it up per manufacturer and device model).
Anyways, specifically for your request:
Left Alt + 0151
That is, hold down left Alt and type in 0151 in the numpad and then left go of left Alt. This works for all sorts of other characters, as well. A simple search will find you plenty more.
Lists a bunch of things that any front-end engineer should be doing. I don’t see how this role is not a subset of related roles. And based on my (limited) experience, this job is generally performed that way by designers and engineers without having CSS-specific people.
That is precisely the problem—the term engineer. The intention was to bring CSS role as a new one for developers who have a stronger sense for building cross-browser, responsive, accessible components, and layouts. We are not engineers if we make themes or standalone components in the UI library.
Apologies, I used engineer too loosely. I believe anyone who’s top concerns aren’t reliability and sustainability cannot really call themselves an ‘engineer,’ and ‘developer’ is a much more appropriate term then for what we’re covering.
My question clarified then is, is there a market for people with CSS skills but without other web development skills? I haven’t seen one, but I’m not as involved in the industry side of tech as I used to be.
Of course, there is, but you have to have web development skills. For example, you could create a solid theme from design for the site without even introducing a single line of JavaScript code. If you have WordPress skills, that could be a WordPress theme. If not, you could make a solid theme, and someone else could implement it. That’s what I am doing most of the time. And static sites, but that is another topic.
What kind of project? You never say. I see a list of packages including sass, Babel, and more. Is this for building static websites? Would I use this instead of create-react-app?
Under the “project structure” section on the SPRO homepage, there’s a big tree output. I suggest annotating at least the directories with how each of them is used in the build process. Annotating the gulp file lines would also be helpful. For example, I have no idea what both gulpfile.js/.kss.js and gulpfile.js/kss.js are. Why are there two? Why is one hidden?
You know what this dingus does. It may seem self-evident to you from the structure. That sometimes makes it hard to write down the obvious stuff in documentation without careful outlining. I’d recommend grabbing a friend who works in tech but might not be a front-end specialist, and having them read over your homepage and take notes on their questions.
Thank you for your comment. I appreciate it. I will try to update the documentation for the project very soon.
Now, to answer your questions:
It is not for building static websites, but it could be. It could be also used for WordPress theme development. The idea is that it could be used for any kind of project that needs to generate and compile CSS, JS, HTML, image or font files.
KSS stands for Knyle Style Sheets. That library parses CSS comments and generates styleguide.
I’ve worked remote for the last three years, and my take on is vastly different than yours.
I don’t go to an office or co-working space. I like saving time on commuting – even though I did enjoy my 10km cycle to work at my last job – and it’s much more distraction-free, especially since most offices/co-working spaces are effectively open office plans, and thus productivity-killers.
I also enjoy the freedom it gives me (see next point).
I don’t have strict work hours, or a strict schedule, or anything of the sort. Basically, I work when I feel like it and don’t when I don’t feel like it. This may sound strange, but I found it works incredibly well. Sure, some weeks I don’t do much, but other weeks I work a lot and get a tremendous amount of work done, just because I feel like it.
Not sticking to any sort of schedule is helpful, since I’ve got more time for other things in my less-productive weeks, I can maximize my productivity much more. Overall, I think I can fairly say that on the whole I’ve been one of the most productive people in the company in the last few years.
Your schedule also sounds a lot like the “work for 8 hours in a block”-schedule. I don’t like that kind of schedule at all. I much prefer “work for a few hours, do the dishes, do some shopping, maybe meet up with a friend, do another hour of work, cook for girlfriend and have dinner, chat some, work for another two hours”-kind of schedule (again, this depends on what I feel like; some days I do work for 8 – or more – hours straight, but it’s not forced).
Distractions are not much more of an issue for me than when I worked in the office. People slack of in offices all the time: chatting at the coffee machine, browsing reddit, etc. Remote work isn’t all that different, IMHO.
I don’t think there’s a one-size-fits all approach here; clearly your approach works well for you, so great! It’s just interesting that my approach is almost diametrically opposite.
The other points (health, loneliness, hobby, fresh air, etc.) are more relatable for me.
Buy noise reducing headphones or large over-ear headphones to remove noise coming from outside and other places.
Having a dedicated room does wonders. I used to work on the couch, kitchen table, etc. It used to take extreme concentration sometimes, and it actually becomes exhausting. A room dedicated to work takes this stress off.
Share things happening IRL with your remote co-workers. This helps with bonding.
Multi-monitor is nice but not necessary. I actually find it distracting but there are times it’s helpful.
I know it’s mentioned but want to emphasize: try to get out at lunch and set a hard time for stopping work. Otherwise you’ll be working until 8pm (or 1am) every day, which I’m sure is common among us.
I never use headphones, except for calls. I like to hear what’s happening around me in the offices around me. I should note that I have a big office just for myself and there is nobody who could bother me.
Heh. I mean nothing too serious when I say this, but somewhere, some time ago, someone mentioned how developers kind of go into an “autistic state”, where we have no choice but to tune out everything and have extreme focus. I feel music helps me get into this state. But it also takes time to come out of this state. I generally feel extremely emotionless as well and time is nothing.
I know, but the way they described it (me just paraphrasing), the possible relation is interesting and makes me think it is plausible.
That is also why I worded it the way I did. There is also this general idea autism is a horrible thing or a joke. It is such a wide spectrum. Here I guess I’m talking specifically about being “obsessive” and lacking emotion. These are good traits for any skilled worker.
I know many people with autism and autistic tendencies and ultimately to me they are just people wired differently, that’s all, and have their own dis/advantages.
To indirection: I’m with mattgreenrocks on using flow. There’s even a great book that popularized it called Peopleware. If you haven’t read it, buy and read it soon as possible. Then pass it on. :)
To everyone: Well, unless there’s someone better aimed at developers that covers the same stuff about team dynamics and especially flow. Is Peopleware still the best in its class or no? Probably should also collect free resources online covering all those points in relatively-short, accessible writing. I do see bits and pieces show up in submissions.
Also, searching for it showed me there was a more recent update (3rd edition). I think the lessons are timeless enough that I’m safe in recommending the older version for its cheaper, used copies. Folks not worried about that might wonder if newer one is better, though. Is it?
Using the term flow will absolutely be more acceptable, heh. I just mentioned what I did here because I trust lobste.rs will see I have zero malicious intent behind my words, and curious to hear if anyone has heard this…idea, or whatever we want to call it.
Wow, you have different work ethics than me. I like yours, but I love to spend time with my family in the afternoon and the evening.
Your post reminded me of a company where I worked before. Some employees would prefer to arrive at work way later than me. I was always the first one in the office. But I was also the first one to leave. I guess this hasn’t changed.
This increased efficiency is reflected in lower costs and, potentially, higher revenues.
If you’re going to make this kind of statement, it would ideally be backed up with some numbers. The only numbers in the post are the score on the Google PageSpeed Insights.
It’s worth noting that on that metric, the transition to a static site generator achieved the same score as the optimized Wordpress installation: 99. The missing 1% was caused by a caching issue with Google Analytics that persisted after the transition and was resolved by using a CloudFlare app (which I assume works around that issue in some way.)
In the same way that you should select a a relational, key/value, or document database based on how you need to interact with your data, the choice of static site generator or more traditional CMS should be driven by how you intend to interact with your content.
The static/dynamic debate, like most in technology, is a pendulum that swings back and forth. Right now, it is swinging toward static, although that trend is not necessarily driven by need as much as herd mentality. I don’t think the general advice to replace all traditional CMS systems with static site generators is driven by a measured comparison of all pros and cons. Here’s what you get with a static site generator:
Better performance as a result of pre-computing HTML content at authoring time.
The ability to interact with your content using familiar software development tools and workflows.
But here is what you give up:
The ability to make content changes from any computer on the internet, no git/GitHub/development tools/text editors required.
The ability to use a variety of useful WYSIWYG editors to create content. WYSIWYG word processors are nice in a lot of ways and probably preferred for many styles of writing.
The ability to do anything dynamic on the server at page load time.
Ultimately it comes down to what you need from a productivity standpoint. If you really just want to write prose, it’s probably worth using Wordpress, Ghost, etc. instead of a static site generator. This will allow you to focus on the content and not the tools. I think many people wish they wrote more, and at least for me, messing around with static site generator tools is a distraction from writing. But if you want to use Markdown and edit your content as if it were source code or have more control over the toolchain used to create your content, then perhaps a static site generator is the way to go.
Thank you for your comment.
I’m sorry I didn’t get the numbers, let’s just say that I saved 10$/month on hosting.
I agree with you about pros/cons, but for me, the pros overcome the cons anytime.
And I can change the content from any device in the world if I have access to Github repository - I’ve added hooks on Netlify to trigger deployment from my repo.
Either way, thank you for digging deep into this topic, I like a quality discussion.
Thanks for posting what you saved! Netlify looks like a pretty useful service for a lot of projects that don’t need a backend, and this is the first I have heard of it.
I think I left out one of the other pros of static site generators, which is that everything (templates, configuration, and content) cab be kept in a single repository. With a dynamic setup, there is usually a database, which makes deployment or site migration more complicated. Anyone who has had to move a Wordpress site between hosts has wished for this!
The big reason I prefer static site generators is that I can write content while offline. This is huge to me, as I do most of my writing and editing while commuting.
Thank you for this! I tried to move my Wordpress blog to Jekyll but stalled because I really didn’t want to learn the Ruby to do some customizations. (This was basically the same problem I had with Movable Type back in the day.)
Once you reach enlightenment and realize that stuff like comments is just useless fluff in your blog, static rendering is the Only Way^tm. I’ve been running a statically generated Blosxom blog for almost a decade now.
Totally pointless. Cmd + Ctrl + Space is the default key combo to bring up the character palette, you can then search for whatever character you want.
Oh, wow, I hadn’t realized the Character Viewer (the window opened by that shortcut) had gotten so much easier to use in more recent macOS versions – or did I never notice that top-right button that converts the floating palette into a popup near the cursor?
Opening the Character Viewer as a palette window keeps keyboard focus in the text field you are in, so it requires a lot of mouse usage to search for and to insert the character you want. I see that after toggling the Character Viewer to the popup mode (the default mode on macOS 10.15), the search field is focused after pressing ⌃⌘Space, the arrow keys select a character, and I can insert the selected character with Return. That’s much more convenient.
On newer Macs (at least the legend for it, it’s prob available or configurable), it’s just straight up bound to pressing fn.
Thanks for the comment. I am going to update the article with this information.
Sounds good. Sorry if I came across as harsh.
This isn’t really correct. See their docs on Github integration.
Shopify does automatically minify assets when they are served, including CSS and JS.
Didn’t know that. I’ll take a look and edit the article. Thank you!
Happy to help!
Updated: https://www.silvestar.codes/articles/nightmare-dx-shopify/
I know that I didn’t justify my argument against React. I don’t know React, and I decided not to talk bad about it. What I wanted to clarify is that I can do my everyday tasks without React. I am working in the web industry for almost ten years, and I have been part of many website projects, some pretty big ones. Knowing HTML, CSS, JavaScript, and its possibilities is hugely undervalued these days. I don’t need to know 0(n) or similar algorithms to build a site that is looking good, performing well, and is accessible to most of the users.
That is just my opinion, and I wanted to make a statement. Knowing React, algorithms, or anything similar might get you a job, but it doesn’t mean you could build a well-performing, fast, and easy to use and understand website.
I want to thank everyone for their comments. I appreciate the passion in these discussions, and I know everyone is talking from their point of view. I just wish to see more sites that aren’t bad and that follow the best practices.
I wish the conclusion had named the best 3 sites. It’s never a bad thing to be positive and call out the sites and developers doing the best work of the lot.
Thank you for the comment. I will definitely update the report with this information.
Great, thank you!
Updated!
What are some tips for learning web development that are unique to web development? IE tips like “focus” and “stay up to date” apply to all areas of computing.
For backend stuff: build a simple HTTP (1.1) server. Pick your language of choice, start out with something ultra-basic like listening on a socket and responding to everything with a hard-coded 200 OK. Then layer in more complexity: parse the method out of the request, say, and only respond 200 OK to a GET, and 405 to everything else. Keep going, adding little bits until you get up to something like being able to have a directory of HTML files and serve up the right one in response to the requested URL, or 404 if not found. Keep going: see if you can implement basic CGI support – getting enough of it right to be able to run simple scripts old-school cgi-bin style isn’t that hard, and several programming languages’ standard gateway protocols are still very CGI-ish, so it’s a useful programming model to understand. Maybe for a “final project” build a simple MVC-ish framework with full separation of concerns: URL routing, data-retrieval, rendering.
For frontend, similar things. Start with a blank HTML file, and work your way up to something moderately complex, marking up elements appropriately. Add in CSS and fiddle with different things until you understand what the “cascade” part is about, the layout algorithms, and so on. Pick a site you think looks nice and start poking at it in your browser’s dev tools, see if you can find out how they got that nice-looking layout to happen. Or start adding basic JavaScript. No framework, not even jQuery – just play with the language, getting familiar with the low-level DOM APIs. Final project: pull it all together and try building a small offline web app like a to-do list using local storage and auto-updating UI based on application state. Same ideas as backend here about learning separation of concerns.
Extra credit: build the same app from both frontend and backend, and hook them together.
Or, more succinctly, I always try to push people to understand the web platform itself – HTTP, HTML, CSS, JavaScript, how dynamic web applications work and are structured in code – because that knowledge is permanent, while particular libraries or frameworks may be here today and “who even uses that anymore” tomorrow.
Even that sounds like iterating development, which is useful outside web programming too.
There’s a difference, to me, between “iterate on a thing” (generic advice, not super helpful) and “here’s a particular thing to iterate on, with suggestions for the first couple iterations and what you’ll learn from it” (specific advice for a particular field of programming, hopefully helpful).
Not just to all areas of computing, but applies to nearly any aspect of life.
I know these bits of advice applies to all aspects of learning, but I still think it could be useful to beginner web devs.
If you ever tried to learn a new skill, I bet you spent time playing around with something unrelated. I wanted to emphasize that keeping the focus is critical to make progress more quickly.
Regarding other advice, I wanted to sum everything up and encourage beginners to keep learning and improving their skills, but to make a plan on how to do it. Without a plan, you could easily get discouraged or lost.
Never heard the term page builder before. Does this just mean CMS?
Maybe tools like FrontPage? But I thought that was depreciated a long time ago…
Actually, I was referring to tools like these: https://www.wpbeginner.com/beginners-guide/best-drag-and-drop-page-builders-for-wordpress/.
The article mentions “ I am referring to the WordPress and Shopify ecosystems here”. So CMS-ish.
Think Google Sites, Squarespace or Wix. These are WYSIWYG interfaces where you drag and drop text boxes, images, forms and so on to create pages. They are technically CMSes, but a lot less sophisticated and but more easily made to show a custom page than a true CMS like drupal.
Emoji Keyboard: it’s build in on most OSes, no need for a extension (macOS: ctrl + cmd + space, windows: win + . (or win + ; ))
Didn’t know that. Thanks.
Wow, cool! Do you know by chance if there’s a builtin shortcut that would let me easily insert an em-dash (—) on Windows? Can I maybe somehow enter it quickly from keyboard through this
Win+.dialog?Yes, on Windows there are Alt code shortcuts. It requires a numpad keyboard, with Numlock turned on. If you’re on a Laptop, most should allow you to simulate the Numpad by pressing Fn + (you’ll have to look it up per manufacturer and device model).
Anyways, specifically for your request:
Left Alt + 0151That is, hold down left Alt and type in 0151 in the numpad and then left go of left Alt. This works for all sorts of other characters, as well. A simple search will find you plenty more.
No numpad on my laptop and no luck for me it seems. I’ll have to stay with thirdparty tools apparently :/
The section
Lists a bunch of things that any front-end engineer should be doing. I don’t see how this role is not a subset of related roles. And based on my (limited) experience, this job is generally performed that way by designers and engineers without having CSS-specific people.
That is precisely the problem—the term engineer. The intention was to bring CSS role as a new one for developers who have a stronger sense for building cross-browser, responsive, accessible components, and layouts. We are not engineers if we make themes or standalone components in the UI library.
Apologies, I used engineer too loosely. I believe anyone who’s top concerns aren’t reliability and sustainability cannot really call themselves an ‘engineer,’ and ‘developer’ is a much more appropriate term then for what we’re covering.
My question clarified then is, is there a market for people with CSS skills but without other web development skills? I haven’t seen one, but I’m not as involved in the industry side of tech as I used to be.
Of course, there is, but you have to have web development skills. For example, you could create a solid theme from design for the site without even introducing a single line of JavaScript code. If you have WordPress skills, that could be a WordPress theme. If not, you could make a solid theme, and someone else could implement it. That’s what I am doing most of the time. And static sites, but that is another topic.
Netlify is pretty good to host static websites and also has a feature to host contact forms. There are plenty of alternatives out there.
Yup, Netlify Forms are great, too. But Netlify Forms don’t have a client-side validation and some other features that Kwes have.
What kind of project? You never say. I see a list of packages including sass, Babel, and more. Is this for building static websites? Would I use this instead of create-react-app?
I clicked through to your project’s homepage to learn more at https://starter.silvestarbistrovic.from.hr/
Under the “project structure” section on the SPRO homepage, there’s a big
treeoutput. I suggest annotating at least the directories with how each of them is used in the build process. Annotating the gulp file lines would also be helpful. For example, I have no idea what bothgulpfile.js/.kss.jsandgulpfile.js/kss.jsare. Why are there two? Why is one hidden?You know what this dingus does. It may seem self-evident to you from the structure. That sometimes makes it hard to write down the obvious stuff in documentation without careful outlining. I’d recommend grabbing a friend who works in tech but might not be a front-end specialist, and having them read over your homepage and take notes on their questions.
Thank you for your comment. I appreciate it. I will try to update the documentation for the project very soon.
Now, to answer your questions:
Stay tuned for updates!
I’ve worked remote for the last three years, and my take on is vastly different than yours.
I don’t go to an office or co-working space. I like saving time on commuting – even though I did enjoy my 10km cycle to work at my last job – and it’s much more distraction-free, especially since most offices/co-working spaces are effectively open office plans, and thus productivity-killers.
I also enjoy the freedom it gives me (see next point).
I don’t have strict work hours, or a strict schedule, or anything of the sort. Basically, I work when I feel like it and don’t when I don’t feel like it. This may sound strange, but I found it works incredibly well. Sure, some weeks I don’t do much, but other weeks I work a lot and get a tremendous amount of work done, just because I feel like it.
Not sticking to any sort of schedule is helpful, since I’ve got more time for other things in my less-productive weeks, I can maximize my productivity much more. Overall, I think I can fairly say that on the whole I’ve been one of the most productive people in the company in the last few years.
Your schedule also sounds a lot like the “work for 8 hours in a block”-schedule. I don’t like that kind of schedule at all. I much prefer “work for a few hours, do the dishes, do some shopping, maybe meet up with a friend, do another hour of work, cook for girlfriend and have dinner, chat some, work for another two hours”-kind of schedule (again, this depends on what I feel like; some days I do work for 8 – or more – hours straight, but it’s not forced).
Distractions are not much more of an issue for me than when I worked in the office. People slack of in offices all the time: chatting at the coffee machine, browsing reddit, etc. Remote work isn’t all that different, IMHO.
I don’t think there’s a one-size-fits all approach here; clearly your approach works well for you, so great! It’s just interesting that my approach is almost diametrically opposite.
The other points (health, loneliness, hobby, fresh air, etc.) are more relatable for me.
I’ve worked from home for the last 2 years and I’m right with you on basically all points.
Some additional points from myself:
I never use headphones, except for calls. I like to hear what’s happening around me in the offices around me. I should note that I have a big office just for myself and there is nobody who could bother me.
Heh. I mean nothing too serious when I say this, but somewhere, some time ago, someone mentioned how developers kind of go into an “autistic state”, where we have no choice but to tune out everything and have extreme focus. I feel music helps me get into this state. But it also takes time to come out of this state. I generally feel extremely emotionless as well and time is nothing.
Man our profession is something else.
Depicting it as an ‘autistic state’ is not very charitable IMO. It’s just a flow state, and it is sometimes required to really understand a system.
It can be extremely draining but it is a tool to employ when necessary.
I know, but the way they described it (me just paraphrasing), the possible relation is interesting and makes me think it is plausible.
That is also why I worded it the way I did. There is also this general idea autism is a horrible thing or a joke. It is such a wide spectrum. Here I guess I’m talking specifically about being “obsessive” and lacking emotion. These are good traits for any skilled worker.
I know many people with autism and autistic tendencies and ultimately to me they are just people wired differently, that’s all, and have their own dis/advantages.
To indirection: I’m with mattgreenrocks on using flow. There’s even a great book that popularized it called Peopleware. If you haven’t read it, buy and read it soon as possible. Then pass it on. :)
To everyone: Well, unless there’s someone better aimed at developers that covers the same stuff about team dynamics and especially flow. Is Peopleware still the best in its class or no? Probably should also collect free resources online covering all those points in relatively-short, accessible writing. I do see bits and pieces show up in submissions.
Also, searching for it showed me there was a more recent update (3rd edition). I think the lessons are timeless enough that I’m safe in recommending the older version for its cheaper, used copies. Folks not worried about that might wonder if newer one is better, though. Is it?
Using the term flow will absolutely be more acceptable, heh. I just mentioned what I did here because I trust lobste.rs will see I have zero malicious intent behind my words, and curious to hear if anyone has heard this…idea, or whatever we want to call it.
Oh, I gave you benefit of the doubt. I was pushing you toward a standard term and a resource you might like. :)
Wow, you have different work ethics than me. I like yours, but I love to spend time with my family in the afternoon and the evening. Your post reminded me of a company where I worked before. Some employees would prefer to arrive at work way later than me. I was always the first one in the office. But I was also the first one to leave. I guess this hasn’t changed.
If you’re going to make this kind of statement, it would ideally be backed up with some numbers. The only numbers in the post are the score on the Google PageSpeed Insights.
It’s worth noting that on that metric, the transition to a static site generator achieved the same score as the optimized Wordpress installation: 99. The missing 1% was caused by a caching issue with Google Analytics that persisted after the transition and was resolved by using a CloudFlare app (which I assume works around that issue in some way.)
In the same way that you should select a a relational, key/value, or document database based on how you need to interact with your data, the choice of static site generator or more traditional CMS should be driven by how you intend to interact with your content.
The static/dynamic debate, like most in technology, is a pendulum that swings back and forth. Right now, it is swinging toward static, although that trend is not necessarily driven by need as much as herd mentality. I don’t think the general advice to replace all traditional CMS systems with static site generators is driven by a measured comparison of all pros and cons. Here’s what you get with a static site generator:
But here is what you give up:
Ultimately it comes down to what you need from a productivity standpoint. If you really just want to write prose, it’s probably worth using Wordpress, Ghost, etc. instead of a static site generator. This will allow you to focus on the content and not the tools. I think many people wish they wrote more, and at least for me, messing around with static site generator tools is a distraction from writing. But if you want to use Markdown and edit your content as if it were source code or have more control over the toolchain used to create your content, then perhaps a static site generator is the way to go.
Thank you for your comment. I’m sorry I didn’t get the numbers, let’s just say that I saved 10$/month on hosting. I agree with you about pros/cons, but for me, the pros overcome the cons anytime. And I can change the content from any device in the world if I have access to Github repository - I’ve added hooks on Netlify to trigger deployment from my repo. Either way, thank you for digging deep into this topic, I like a quality discussion.
Thanks for posting what you saved! Netlify looks like a pretty useful service for a lot of projects that don’t need a backend, and this is the first I have heard of it.
I think I left out one of the other pros of static site generators, which is that everything (templates, configuration, and content) cab be kept in a single repository. With a dynamic setup, there is usually a database, which makes deployment or site migration more complicated. Anyone who has had to move a Wordpress site between hosts has wished for this!
The big reason I prefer static site generators is that I can write content while offline. This is huge to me, as I do most of my writing and editing while commuting.
Thank you for this! I tried to move my Wordpress blog to Jekyll but stalled because I really didn’t want to learn the Ruby to do some customizations. (This was basically the same problem I had with Movable Type back in the day.)
I’m happy this article was helpful to you.
Once you reach enlightenment and realize that stuff like comments is just useless fluff in your blog, static rendering is the Only Way^tm. I’ve been running a statically generated Blosxom blog for almost a decade now.
I’m glad we’re on the same page here. I think static is just more performant in every way.