I work with Segun (the creator of Chakra UI), super cool and down to earth dude. I love that Chakra UI is getting some attention. We have been using it in all our production applications and couldn't be happier. I also just finished creating a short project-based video series on Chakra UI and React yesterday. Have a look if anyone is interested https://www.youtube.com/watch?v=NyG7YJWJd6s&list=PLkZYeFmDua...
Huh. This graphic doesn't feel correct. A shell is also a generic term, so fish, zsh, ksh, dash .. they're all shells. sh is specifically either the Bourne shell or something that's (usually) Bourne shell compatible. (Bash is the Bourne Again Shell; sh with extensions, but still POSIX compliant).
I started https://roadmap.sh with the hopes of doing something similar. It currently only has a few items that I have expertise in plus in the form of a visual representation, however I am going to change it and will soon be reaching out to other people for contributions. It is one of my goals this year to focus fully on it.
Thank you for pointing it out. It is still being modified and will hopefully be fixed this week along with the other changes. It was there in the "common" section in the repository https://github.com/kamranahmedse/developer-roadmap but was missed when moving the roadmap to the website.
1. Yes, git should definitely appear in a common / transverse section. Oh, I see it now appears.
2. What do you mean "missed when moving the roadmap to the website"? Don't you have an automated deployment setup?
3. I see no code at all in the repository. This looks like free-to-contribute documentation, not FOSS then. Still, very good thing that you did it.
4. Also, besides web (that you cover) and embedded (as mentioned in other comments, and writing device driver can be considered similar), there is still also desktop applications, signal processing oriented programming (including electrical, sound, image and similar) and their number-crunching oriented cousins (machine learning, smart data import with added value, data science and similar) and security. I personally know startups that do each of these.
Hey guys, I am the person behind this website. Please know that it is still in progress. I wanted the initial version out so it is just the "roadmap" images for now. However, I am working on making these roadmaps more accessible for the beginners and easier to contribute to. In the list of things planned for the coming week is the textual version for each with different sections (job-ready, intermediate, advanced, overall landscape, etc) and each of the steps are going to be clickable with resources to learn from.
The website and the content is opensource and can be found at https://github.com/kamranahmedse/roadmap.sh. Please feel free to contribute, drop your feedback, feature requests and issues there.
Instead of learning JavaScript frameworks, isn't it better to advise people to learn and master JavaScript itself? I feel learning HTTP, HTTPS, HTML, CSS, and JavaScript inside-out will benefit someone than to try to learn a framework that will disappear very soon. When you know undelying technologies, it is easier to learn new frameworks because they will always be based on underlying technologies.
Learning a framework will enable more participation and contribution _now_. And arguably knowing the framework isn't so important compared to going through the _process_ of learning one; if you know how to do that then you can just latch onto the next up-and-coming framework. But yes, it's certainly also good to master JS itself.
Angular/React/Vue are unlikely to dissappear they've existed for a long time now.
Angular: 3* years *9 if you count AngularJS
React: 6 years
Vue: 5 year
That's a long time by web standards, they also keep up and push native javascript forward.
So yes, learn native JS. Definitely learn a framework though, as those skills are ultimately what you need to work on anything more complex than a simple website.
5-10 years is too little considering the fact that they spent first 2-3 years gaining momentum. Even worse for Angular because it was completely changed along the way. JavaScript knowledge is still relevant even after 24 years. Whatever is on those libraries and frameworks will one day make its way into JavaScript and that will be theur end. Frameworks will come and go. Even the most successfull JavaScript library ever, jQuery, is on the decline because of newer frameworks and features like querySelector.
In my experience, "front-end" these days generally means "web client development", e.g. the opposite of "back-end" (server application).
You're talking about client development in general.
I suppose web clients stole their own term because of the idiosyncrasies with web browsers, like how the server can ship declarative HTML to the browser for a fully-working UI which is a unique phenomenon.
There are issues with this weird distinction though. For example, people will complain how hard "front-end development" is, thinking it's something unique to the web, without knowing that all client development is hard.
In my previous job i was working on game tools with wxWidgets, in my current job i am working on game tools with Qt. In between i got an offer (which i rejected since i am interested in games) for a Qt tool to be used for (IIRC) DNA research (or something like that, i'd just be doing the UI not the actual logic).
Except Android/iOS, everything you listed is dead or dying.
No sane person would pick anything but Electron for a desktop app today, unless you are in a particularly high performance domain (CAD/Graphics/Video/...)
> No sane person would pick anything but Electron for a desktop app today, unless you are in a particularly high performance domain (CAD/Graphics/Video/...)
People who don't hate their users or who don't hate the environment might.
Electron apps use lots of CPU, lots of RAM and lots of energy. I get that they're easy for web devs to make and I've made them before but I'd fight tooth and nail against launching one at scale (like Slack did, for example).
Well, if you make the energy argument, theres a lot more to cut then.
How about high resolution displays? And bit depths? We can perfectly work on a 1024x768x256 colors screen. Imagine how much CPU/GPU cycles that would save.
Are you kidding me? There are many reasons to pick a non-electron platform without the need for particularly high performance. Android/iOS are good examples of the reasons why. There's just so much to be had by integrating with the OS and the environment that the user uses your tool in. Electron is great for a prototype or as a way to get your feet wet in improving the desktop experience. The best user experiences will always be founded on the native technologies of the target platform.
Only if by users you mean people living in the terminal. Yeah, those people hate GUIs, compositing desktops and anything more than monospaced text. Just whisper "Emoji" in their ear and witness the Wrath of Khan unleashed.
I would say exactly the opposite, not using web-tech for GUIs is disrespecting the users, because the end result is an ugly app with a lot of missing features (gif/image/emoji support for example).
Users seem to love their VS Code/Discord apps written in Electron. I wonder why.
I don't want gif/image/emoji support in 100% of the apps I use, so this point is silly. I dislike Electron apps because they tend to break with the OS UI and force whatever the developer thinks I want on me. I don't. Stop it.
Definitely a great idea. gRPC has been a huge benefit for us. I'd also get rid of learning NoSQL databases. It's good to know but in 99% of situations you should be dealing with them especially not before you learn about things further down the list like Docker, RESTful APIs, Auth, etc.
NoSQL is not less important than others. Especially not with the rise of many startups that want to scale and want their sites to be lightning fast (e.g. available at the edge). Many companies I worked lately actually thought the non-traditional databases are becoming more important.
Also distinguishing NoSQL and SQL is quite old and still dating from the CAP theorem which is also becoming obsolete. You have traditional databases and the rest since 'NoSQL' are incorporating SQL features (ACID, joins, etc) and vice-versa, soon it will just be databases with feature X,Y,Z. If you want to add something I would rather add 'distributed databases'. Learn relational databases probably boils down to 'learn SQL'
Knowing which database to use in the landscape is extremely important.
It should imo be:
- Learn SQL
- Learn GraphQL (becoming the new SQL quickly)
- Learn gRPC
- Learn about database features (consistency, distribution, replication, sharding, OLTP, OLAP) and what database to use in which situation.
"becoming the new SQL quickly" - Prisma, who led the way on that front, abandoned this pursuit.
"Learn GraphQL" - I'm not sure you need to learn GraphQL. You need to now that GraphQL is a powerful tool for APIs consumed by third party devs, such as the GitHub or Facebook API. But for internal APIs (and more than 98% of APIs are internal!), GraphQL (and even REST) is overkill and you'd be better off with RPC, such as Wildcard API [1] or gRPC [2]. Many developers will never have to build a GraphQL API in they entire career. Only few companies need to expose their data to third parties.
I would hope new developers ignore comments like yours.
NoSQL databases are just a tool like other tools. And you should know when and why to apply such tools not just dismiss learning them altogether.
Also every developer goes on their own journey. So if someone wants to build a social network then a graph database is going to make more sense even at the beginning than a relational one.
I’ve seen way too many junior developers fall in love with NoSQL databases to recommend them as a starting point. NoSQL is a niche tool whereas relational databases will be the bread and butter in a vast majority of cases. Many junior devs try to use NoSQL for everything and then fuck it all up.
Postgres even supports using NoSQL concepts with JSONB so there’s no reason not to start with it.
I’m sure I’ll get downvoted since HN has been very hostile to real talk lately but I don’t care.
Yes, but the current version of the roadmap makes it seem like NoSQL databases are way more important than they are (IMHO). I would say a junior backend developer needs to know about web servers, REST, AuthN/AuthZ and even Docker way before they need to know about NoSQL.
I'm interested as to why junior developers even need to learn Docker. I'd say learning Docker would be a "nice-to-have," but you can go years, or even forever, without having to deal with it, or even having a need for it. I'm not saying learning Docker is fruitless, just that Junior Developers might not get enough out of learning Docker to put it in good use.
As for NoSQL. I'd say that definitely should be on the roadmap. I've assumed that they've already learned RDBMS, but knowing when to use the two is essential. Most companies now are working with data lakes and unstructured data (e.g. user and session data). Knowing how to get around that flexibility, how to structure your business logic and models, and what tool to pick (i.e. Redis for caching), etc. goes alongside NoSQL knowledge.
Using docker force you to declare step by step what you need to build/use your code. If you combine that with good CI/CD, that easier to provides help to the junior developer if you can quickly reproduce the environment.
I had a bad experience with a project that I was assigned to "help". The build steps documented used incompatible lib version. It's hard to help if you can't even build/run their codes.
I would rethink including "Learn CSS3". CSS has moved away from single versioned spec to modules and levels, so CSS3 does not mean much now. If you want to emphasize some specific parts (like animations), better say so explicitly.
I'd still recommend learning about one of those frameworks to anyone aspiring to be a skilled front-end developer. Not because it is essential to master them, but because there are interesting concepts in there that could help with front-end applications development.
the frontend developer roadmap is a hot mess and looks like it is intended as humor, especially in contrast to the backend developer which is much more descriptive
I've been using Balsamiq since it first came out years ago - it was one of the 1st popular wireframing tools.
It kind of feels like it's stood still though - they've had years to innovate, but haven't really. At the very least, I wish they'd add more shapes/components, because the library you get is severely lacking.
