
What still sucks about front-end web development - cnorthwood
http://www.pling.org.uk/journal/2013/what-sucks-about-front-end-development/
======
camus2
\- 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.

~~~
cnorthwood
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.

~~~
camus2
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.

~~~
idlewan
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?

~~~
true_religion
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".

------
lsh
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...](https://support.google.com/webmasters/answer/99170?hl=en&ref_topic=1088472)

\-
[http://en.wikipedia.org/wiki/Microformats](http://en.wikipedia.org/wiki/Microformats)

\- [http://microformats.org/](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.

~~~
integraton
_> Who cares?_

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

~~~
scarecrowbob
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.

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

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

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

~~~
cnorthwood
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

~~~
integraton
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...](https://groups.google.com/d/msg/blueprintcss/Yyx9PpZpCRA/wq1nRU5gxloJ)

Both Susy ([http://susy.oddbird.net/](http://susy.oddbird.net/)) and Bourbon
Neat ([http://neat.bourbon.io/](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.

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

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

------
jacques_chester
> _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.

