Hacker News Reader

Comment by kamranahmed_se | Hacker News Reader

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.

View on HN

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.

Frontend roadmap completly ignores everything that isn't a Web browser.

So no Qt, wxWidgets, Android, iOS, WPF, Forms, UWP, WinUI, GNOME, KDE, ...

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.

These days, I think the job-ad word coding is:

- Frontend = In a web browser; HTML, CSS, JavaScript

- Mobile = Android, iOS

- Desktop = Qt, wxWidgets, WPF, Forms, UWP, WinUI, GNOME, KDE

Implying desktop job ads exist...

Plenty of them, specially in automation.

And games, medical, research, etc.

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).

I think job descriptions saying "Frontend Developer" and "Backend Developer" nowadays imply the Web.

Except when it doesn't.

I think this would come as news to a large group of people, including myself. I've only ever imagined a front end developer working on the web.

Another large group of people has been doing frontend before Web existed.

Meanings change. I think what you mean would be called an application or GUI programmer today.

Mobile and Desktop are different beasts from Web Frontend and require different (although related) skillsets.

It is still frontend nonetheless.

Agreed - should probably read " web frontend" or something similar.

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.

Edit: spelling errors

If they don't have any respect for their users I guess.

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.

Because they offer a gratis plugin eco-system over the competition that outweighs the disadvantage of running a memory hungry application.

Other than VSCode, my computers are free from Electron virus.

IMO, you could put Remote Procedure Call (RPC) technologies such as gRPC for backend developer.

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.

[1]: https://github.com/reframejs/wildcard-api

[2]: https://grpc.io/

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.

There is also Wildcard API [1] for Node.js

[1]: https://github.com/reframejs/wildcard-api

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.

Please add web components to frontend, instead of pick a framework...

Yes.

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.

This is an outstanding piece of work. Kudos.

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

Reply on news.ycombinator.com