Hacker News new | comments | show | ask | jobs | submit login

My take is that a greater percentage of websites can be written in HTML and CSS than currently are: both in the sense of websites that could be entirely written in HTML and CSS and as portions of websites that can be written in HTML and CSS instead of with something else.

Many of current batch of tools were developed to meet the needs of engineering teams at scale: e.g. Angular @ Google and React @ Facebook. Their heritage is not "hobbyist programmer" friendly. They are great if the hobby is reading about technology. But many many of those opinions embedded in Django and Rails only become natural once a person is deeply familiar with the culture of their communities.

My advice, do the simplest thing that will work and make something. Pick tools that require a lower level of commitment to an overall architecture as the need arises. Stay out of silos and rabbit holes.

Good luck.

I can't agree more. The tons of frameworks and libraries coming out are suited to specific use cases, more web applications than simple sites, and using them unnecessariy will not gain any advantages. If you just want to "setup a website every now and then", your current skillset is more than sufficient. Don't fall into the trap of using new technology for the sake of using new technology.

You may notice that when late 90s/early 2000s sites get posted to HN, there are often a set of comments on how quick-to-load and readable they are.

Completely this.

If I teleported here from the 90s, first thing I'd need to wrap my head around is how HTML and CSS have changed. I'd be learning a responsive framework (or even hand-rolling it, so you know how it works) like bootstrap. And doing a very basic website.

And if html5 & responsive css aren't enough to wrap your head around at once, I'd create a github account, and start with github pages. That'll let you use the static site generator Jekyll. The combination of all three will do pretty much all you need for 90% of the sites out there.

After that, then I'd look at a stack that lets you have some degree of interactivity and persistence in order to build web apps.... But for now, clean responsive websites would be the way forward.

Take a look at Susy for layout, bit more flexible than Bootstrap:


Also for static site generators take a look at:

https://middlemanapp.com/ (Ruby) http://gohugo.io/ (Go) https://github.com/getpelican/pelican (Python)

When you need to go beyond static sites and take a look at the web frameworks - Ruby on Rails is the obvious one, but I reckon that Meteor (https://www.meteor.com/) could be a good bet now that it has matured. Might save you a lot of time when compared to RoR for certain tasks.

Imo I'd hold off on susy. Bootstrap is a great start for a beginner abs it's used in a ton of environments.

I took several years away from the front-end to focus on Backend and DevOps, only recently re-upping my front-end-fu. Since I knew CSS 2.0, I found Bootstrap quite easy to pick up and be productive with in about a day, not previously knowing CSS griding. And I found myself saying over again, holy shit where was this back in "my day"!

Agreed. Also, avoid every other tool that is potentially 'next-gen' compared to what provides the functionality you need. For someone with the goal of publishing web sites, Bootstrap css and js will get you pretty much all the way. Don't worry about moving beyond them until you actually feel you have to.

Staying out of silos and rabbit holes would probably mean avoiding bootstrap, github and the like. Totally agree on building clean, responsive sites though.

Yeah. Bring back text/plain and the idea of progressive enhancement. I started trying to learn React.js and fell down the rabbit hole you mentioned.

I second this. Additionally, if the choices are still overhelming and you have an idea of what you really want to build, I would suggest trying something like writing cucumber features[1] and running them in a headless browser.

I'm sure many people will tell you about their negative experiences and how writing these kinds of "tests" are slow or misleading or a waste of time. But I would say that deciding what your software does--even in an abstract and gradual fashion--gives you tremendous freedom in knowing that all the other choices are just implementation details of a larger design. (As the parent says, a "lower level of commitment".)

[1] https://cucumber.io

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact