What still sucks about front-end web development | Hacker News Reader

What still sucks about front-end web development

pling.org.uk

23 pointscnorthwood17 comments

- Non-semantic HTML

Then why are you using a framework that provides these kind of classes ? dont like the classes , dont use it , or use a semantic CSS framework. You cant complain that tools developed by others that you use for free sucks.

- JavaScript library management

Same stuff, I'm not sure why people complain about all these freebies today. When I started webdev , all these tools were not given , today there are thousands of them,if they suck roll your own tool,by the way i'm pretty sure you could fix bower yourself.

- Media Queries

Not sure what you are complaining about. The way other people use media-queries? why do you care?

If you really want to complain about something , complain about the fact that most browser vendors still dont provide headless browsers for instance, or are slow to implement standards that have existed for 10 years, or release browsers will very bad debugging tools, or mark some nasty bugs as "wont fix"... The people that actually make money when a user browse the internet ... complaining about people that try to fix things without having a huge team behind them is a bit selfish.

The way we can get better as an industry and professionals is by improving and iterating, and reflecting on the current state of the industry and seeing where we want to go next is part of that. I'd rather improve the tools that already exist rather than re-invent my own.

I believe there is something called forking. Instead of complaining , fix the tools yourself and make a pull request.

The current state of the industry is a lot of people are complaining about the freebies they get without contributing back to the open source.

Sometimes people can't contribute back to the projects (lack of time, lack of wilingness to create a fork + put a 'marketing page' up and convince others...).

Constructive criticism (like in this article) is a valid way of trying to convince others that a better way is possible. He is cleary stating the use cases he would like the tools to fix.

Shooting down the critic by saying 'so fix it yourself/so fork off/so go code another lib out of the 30 000 that exists' is, on the other end, not constructive. Do you have better arguments?

Lack of willingness isn't really an argument for "I can't contribute". It's more of a statement of "I don't want to".

Huge peeve of mine: "non-semantic html" Who cares? Why bother? HTML isn't structured, extracting structured data (or the 'meaning'/'information'/'purpose') from soup is always going to be an inexact fumbling, even with ML or machine vision algorithms.

HTML 5 and it's deluge of new elements - used 100% correctly per the spec - is still only semi-structured. There are all kinds of ways to interpret what should go inside an 'article' or 'section' or 'nav' element and people do - you just can't trust the hundred million different interpretations of the spec every web developer brings to the mix. Then there is javascript which may make the page completely blank/unreadable if not enabled and, and .... urgh! Stop pretending like it's something that matters to you. It's only good for readability, I guess. Maybe. I'm not advocating going back to tables, but this is such a piffling little nothing to be concerned about. The important problem is can the information embedded in your webpage be easily extracted despite all the noise?

I don't know of any solutions to the tag soup that is HTML besides introducing structured data via microformats:

- https://support.google.com/webmasters/answer/99170?hl=en&ref...

- http://en.wikipedia.org/wiki/Microformats

- http://microformats.org/

And even that feels like a hack sometimes.

I've started writing a browser that sucks the information out of your webpages and displays it in a very boring, very Web 0.5 kind of way. It's going to have blackjack. And hookers.

RSS is the best thing since sliced bread.

> Who cares?

I care. Semantic HTML is easier to work with when creating, maintaining, interacting with, or consuming HTML.

Semantic HTML doesn't necessarily equate to being more maintainable/scrapable. Have you ever come across the mess trying to emulate table-like behaviour in css with spans/divs?

Within the context of my work, at the level of maintaining and creating the markup col-xs-4 has a much clearer meaning than main-sidebar and it is much more reusable.

It's almost irrelevant from the standpoint of interacting or consuming the markup, and even then there is no injection against telling the world an element is a main-sidebar in addition to being a col-xs-4 which will pull-left and be a list-unstyled.

There has been some discussion as to whether semantic HTML is necessarily the way to go as well.

I don't disagree with point #2 or #3, but I think these are smaller issues in a lot of ways compared to some of the other things I have seen in my short time developing.

I decided to take a break from re-working my wife's website (side/for fun project) and stumbled upon this submission. Ironically, I was just wrestling with how to migrate my pure CSS bootstrap implementation to a semantic ui with Less. Bootstrap is NOT built for abstracting away it's implementation details even if you use Less...I can't get rid of a collapsible nav or input-group-addons. I wish I had a mixin for each...

The author is spot on with his concerns, but I think there is one more to the bower equation. Why does the package manger have to pre-build their assets for me to use them? Why can't I use the grunt files associated with the bower project I imported to build my assets? Let's imagine there is a scenario where I create some sort of grunt config which includes/excludes certain bootstrap js files (I'm assuming that 1) grunt allows me to extend/overwrite the package's variables 2) I can chain the grunt builds of multiple dependencies together...then when I build my project, I only get what I configured.

There's little point complaining about the current state of front-end development while we're on the cusp of the next generation of front-end technology.

e.g. Non-semantic HTML is avoided with Shadow-Dom + Custom Elements + aria attributes & JavaScript library management is mostly solved by ES6 modules.

Semantic HTML is possible now, but the way our tools have been built (and documentation written - e.g., add this class to your element) makes it hard to do the right thing

I'm guessing by your name that you are the author. In the post you ask:

> why does every single Sass/Less framework suggest first in the documentation that you should write your HTML like this?

Most major Sass grid frameworks encourage semantic HTML and always have. See, for example, Chris Eppstein stating the rationale behind blueprint-sass in 2008:

"The biggest advantage of using the "sassified" version of blueprint is that you can use semantic class names again and stop putting "display classes" in your markup." - https://groups.google.com/d/msg/blueprintcss/Yyx9PpZpCRA/wq1...

Both Susy (http://susy.oddbird.net/) and Bourbon Neat (http://neat.bourbon.io/) follow in this tradition.

The Foundation and Bootstrap documentation is targeted at people using the generated CSS, which is why they use non-semantic class names. I'm not familiar with Gumby, but there is no good reason for them to encourage non-semantic class names when using SCSS, although presumably they are assuming their main users are similar to the CSS-only users of Bootstrap and Foundation.

That's great, I wasn't aware of those frameworks, thanks.

For your qualms about non-semantic HTML, I'd check out Neat (http://neat.bourbon.io/). I've used it a few times and it provides pretty much everything you ask for.

> Did we not learn that table designs are bad because they heavily couple the design of your page to the meaning of the document?

Yes.

But lots of people aren't creating documents. They're writing applications.

Reply on news.ycombinator.com