20 ms·

In web design, everything easy is hard again

459 points by josephscott 9y ago

csbartus 9y ago
I've just tried to copy paste the title of the article ... but it's impossible ... it's an image. If after 20 years of web design and development you still don't get it, then everything easy is hard again.
- anotheryou 9y ago
  Why would yo want to triple (I guess even more) your work just to have a semantic title when you can use an alt-text?
  - jwilk 9y ago
    But there's no alt text. The code looks like this: <div class="section title"> <h1>Everything Easy is Hard Again</h1> <img src="images/everythingeasy.svg" style="display: block; height:60vw; margin-left:auto; margin-right: auto;"> </div> And <h1> is styled in such a way it's not visible. This is bizarre.
    - fredsted 9y ago
      Bizarre? The h1 is probably there for SEO or screen readers.
golergka 9y ago
I've almost never touched web development, but as an active HN reader I have at least passing familiarity with almost all the terms used in the article. So, honest question: can a person fully understand how modern HTML/CSS work without diving in the source code of one of the browser engines? Because as a developer, if I was forced to use such a complicated technology, grooming source would be my best guess at making any sense out of it.
- anotheryou 9y ago
  No dive necessary if you don't get close to performance limits of browsers. Actually looking at how it's meant to be first is the only sane way, because browsers do whatever the fuck they want and you just have to see what happens.
- GoToRO 9y ago
  As as web developer the most important skill to learn is to let go! You fix it for whatever browsers the client uses and forget about the rest.
  - afarrell 9y ago
    I suspect your parent comment isn't talking about browser compatibility. I suspect it is about learning enough CSS/HTML to write up a page for one browser without feeling like [venetian blind gif]. https://imgur.com/gallery/Q3cUg29 https://imgur.com/gallery/Q3cUg29
- afarrell 9y ago
  http://book.mixu.net/css/ http://book.mixu.net/css/ is a reasonable guide and as a backend dev, I've learned to feel more comfortable with HTML/CSS by reading through it multiple times and making flashcards in a Spaced Repetition app.
- TheAceOfHearts 9y ago
  Yes. Read the whatwg HTML spec for developers [0]. Understanding ALL of CSS is tricky, because it has a long history. It's also incredibly tricky to understand how it all works together when different display modes are combined. But you don't need to understand ALL the parts in order to build something useful. Just skip over the parts you won't be using. Do you think any of the alternatives are truly much better? [0] https://html.spec.whatwg.org/dev/ https://html.spec.whatwg.org/dev/
dvfjsdhgfv 9y ago
I completely share the thoughts of the author of this article. However, I'm not sure if his proposed solution would work for most people. It's not that I want or like to use npm etc. - I'm forced to use them as it's the new default way of working with almost anything useful in today's web development work. An alternative would be to start from scratch - and then reinventing all these things again, making another full circle. There could be another solution. A lot of today's complexity of the web stems from the fact that we're trying to design (web) apps using (HTML) documents. It's like building user interfaces in Word (without VBA). You can, but there are much better ways to do it. Why not to define a set of APIs for creating GUIs? Yes, I mean something like XUL which failed because nobody except Mozilla cared. Make it standard, make it easily themeable, and we can finally throw away this mess of ugly hacks used now to create intricate GUIs for which we have dedicated widgets on the desktop and which we have to reimplement on the web, with mixed results.
- Nition 9y ago
  Yeah, I agree with both you and the article. The biggest problem with website design seems to be that it's all layers on layers on a base that wasn't so great for design in the first place.
- deleted 9y ago
  [deleted]
- mattmanser 9y ago
  Crikey, even the 'reasons' are circular. People were saying that was the problem 10 years ago. Those exact words. Apps aren't docs. All you need to do now is propose a new language and call it XHTML. Or maybe make markup extensible and functional, we could call it, ummmmmm, XSLT.
  - grndn 9y ago
    I came here to say the same thing. :) The fundamental problem is that you want one piece of (semantic) content to be presented on many different platforms with very different design approaches. The current approach uses if-then-else conditions in CSS, and when that fails, if-then-else conditions in JS, and when that fails, complex JS to transform the DOM. The XML/XSLT approach, although clunky, might actually be better in many cases.
randomsearch 9y ago
This is my experience of web development, every time I return to it. I’m really not an expert in web dev, but it _feels_ like web dev has been badly engineered. JavaScript is a very badly designed programming language (yes, even in its modern form), which I think has caused a lot of problems. Many JS developers don’t know much about programming language design, so they can’t see how bad it is, and they make matters worse by not trying to abstract or use JS in a way that reinforces good PL design methods. If you recognise JS as a terribly designed language, then the last thing you would imagine doing is widening its use. But that is exactly what node.js does. You should instead isolate JS and minimise its use. So red flag - something has gone wrong here. It also feels that many web ecosystems have an over-inflated sense of self-importance. This has led to many competing frameworks for the same tasks, that try to do everything. Things are not pythonic. There appear to be an excessive number of package managers involved. There were already plenty of package managers out there - inventing new versions of existing tech makes it harder for everyone and is usually a red flag that someone somewhere is making bad decisions. I need to build a website soon and I’m dreading the front end. At the back end I can use range of solid and well designed languages and technologies, but at the front end I feel like I’ve got to choose the least poor of a bunch of crazy options. If anyone has advice on how someone who prefers rigour, simplicity, elegance, and decent PL design over the latest trend should approach web dev that would be massively helpful. “Sane web dev to minimise the impact of the Web Dev CSS/JS disaster on your life” would be my favourite O’Reilly of all time.
- keldaris 9y ago
  I'm in a similar position, and I've formed the same impression. Furthermore, even though browsers are stuck with JS, given the influx of languages able to compile to JS (or even WebAssembly now) it feels like there should be plenty of options for those of us who would rather stay away from the craziness. Perhaps someone with more frontend experience could comment on what (comparatively) sane, simple and JS-minimizing options are there now?
  - Vinnl 9y ago
    Compiling-to-JS brings in its own set of crazy, and really almost never is worth it. In fact, the only two that make any sense are Babel and TypeScript, and that is only because are (practically) Javascript and because they are stable and widely used projects. If those two wouldn't hold, you'll quickly be running into a whole host of problems w.r.t. interoperability with the rest of the ecosystem, and you'll end up reinventing the wheel again.
vex3d 9y ago
No it's not. You decided to make "easy" tasks complicated. Then rather than learning about new technology you wrote a blog moaning about it. Just stick the basics if that's what you want to do. No need for loaders or preprocessors if you don't want to use them.
dmitriid 9y ago
I've recently realised that most of modern day's web stem from the fact that it's not a platform. It's still just a barely functioning system to display text documents. That's where all the complexity comes from: people are trying to build/collect the missing pieces of a platform, and then try to build their stuff on top of it. And you can see it everywhere: from CSS (which still pretends that modularity doesn't exist or that complex constraints in layouts do not exist) to DOM (which hasn't seen a proper API design in years) to Javascript (whose idea of a standard library is adding an underspecified `fetch` after 15 years of people writing wrappers around XMLHttpRequest).
- ccachor 9y ago
  "(whose idea of a standard library is adding an underspecified `fetch` after 15 years of people writing wrappers around XMLHttpRequest)." So true.
ohazi 9y ago
Choice quotes: > Directness is best in my experience, so a great photo, memorable illustration, or pitch-perfect sentence does most of the work. Beyond that, fancy implementation has never moved the needle much for my clients. > Last month, I had to install a package manager to install a package manager. ... I sure as hell know about spaghetti workflows and spaghetti toolchains. It feels like we’re there now on the web.
- Vinnl 9y ago
  If I want to install Pip, Maven or what-have-you, I'd be using apt.
  - JetSpiegel 9y ago
    You don't install apt, it comes standard.
    - Vinnl 9y ago
      The point is that I'm using a package manager to install a package manager, which is supposedly bad.
  - thaumasiotes 9y ago
    If I wanted to install pip, I'd install virtualenv. (I'd use apt to install virtualenv, sure, but using apt to install pip will eventually turn out to be a mistake.)
- lultimouomo 9y ago
  My personal favorite: > I type clear: both and say a prayer to the box model.
megaman22 9y ago
> There’s a voice in the back of my head saying we’re stuck in a loop and it’s repeating. We’ve completed a lap on a cycle which will go around forever. Another approach for layout will come along five years from now, it will probably resemble floats, and not knowing how to clear a float will bite me in the ass for the second time in my career. This is what I feel like everytime I try to keep up with web tech... For crissakes, the last training I went to had a session on Razor Pages, which set off my PTSD from years of doing ASP.NET WebForms, back before we decided that was a really awful, painful way to do things.
helenius 9y ago
Maybe somewhat related: can anybody guess what the idea behind the images in this article is? <img src="/images/trans.gif" data-src="images/speaking.png"> trans.gif is just a 1x1px invisible pixel.
- merlincorey 9y ago
  Tracking scripts don't need to do anything but read the hit in the access log. That said, it's also trivially easy to output the bytes for a 1x1 invisible gif as the response from your tracking endpoint.
  - Piskvorrr 9y ago
    It is easy, but is it fast? Serving a static GIF has an overhead of ~0, and it doesn't need any executable beyond the HTTP server to run on the machine, except to move the logs out for processing (syslog, rsync, what-have-you, in most cases out-of-band wrt the HTTP server).
- culturedsystems 9y ago
  It's lazy loading the images - when the page initially loads, it only loads one small image (trans.gif), and the file specified in the data-src attribute isn't loaded until you scroll near to the img tag. Specifically, it's using this plugin: http://luis-almeida.github.io/unveil/ http://luis-almeida.github.io/unveil/
  - acqq 9y ago
    The given use of that on frankchimero.com is bad. If I use uMatrix then even enabling scripts for the site won't show the images. Moreover, if the javascript is turned off completely, the proper approach for the given task is having the <noscript and the images properly specified. One of the images is just a PNG of an emoji U+1F632 (my guess). Another of the emoji of the cake. He could have saved on these two completely. That leaves us with the tile svg and the 170K PNG for the face of the author, which should obviously be a 40K JPG. Finally, the img tags on that page don't contain dimensions, whereas it's probably(1) better to still have them: https://www.computerhope.com/issues/ch001158.htm https://www.computerhope.com/issues/ch001158.htm Given the topic of the post (the need to keep things simple when making web pages), I consider these observations relevant. 1) Probably as I'm not in the business and I don't follow most recent developments so I don't know if the arguments from computerhope.com are obsolete by the most recent standards or implementations, so all relevant technical information is welcome.
danieltillett 9y ago
The whole thing is driven by all fields reaching the highest level of complexity their practitioners can understand. Web design in not inherently complex, but it is filled with lots of talented and intelligent people because the pay is good and the conditions cushy compared to say gutting chickens in some factory. The only way to solve to the complexity treadmill is to drive out all the smart people.
- tonyedgecombe 9y ago
  We do have a tendency to make things as complex as we can, which if you are smart is too complex for the majority.
factsaresacred 9y ago
Well written and beautifully presented but these are complaints about progress. > 'my limited needs...Simple, responsive layout' As we all know, limited/simple in the requirements doesn't mean simple to implement. "I want this page to look the same on any size screen, whether viewed horizontally or vertically". OK. It's surprising it's as simple as it is. > 'I thought implementing webfonts was a relatively easy procedure, but I guess not!' No, it is easy. If you want to read 90 pages of marketing-promo disguised as a guide to fonts, do so. But you don't have to. Go to google fonts, pick one, add the URL to the head of your webpage, done. > We’re a long way from the CSS Zen Garden where I started. That way is still there. It's just slow and messy. You can still inline your CSS, use external css files. Whatever you want. > Before, the websites could explain themselves; now, someone needs to walk you through it. Before, scrolling text and gifs were the cutting edge of web technology. Now we have Photoshop, online IDEs, real-time trading applications in the browser. This is magic. And magic isn't easy. Furthermore, modern browser element inspectors provide an excellent explanation of what's happening on a webpage. The web isn't static - as the browser advances we use new tools to handle the possibility as well as the complexity. But the old ways are still available. Although I'm not convinced that the 30 minutes of mental overhead getting to know npm and flexbox beats the mess of external resources, duplicate code and utter pain that was the web of the past.
Falkon1313 9y ago
>simply npm your webpack via grunt with vue babel or bower to react asdfjkl;lkdhgxdlciuhw >[...] >I had to install a package manager to install a package manager. And that's coming from a designer, not a programmer. A few years ago I had to take over a project that required installing something like 6 different package managers, 2 build systems, and a dozen different languages (counting things like jade and coffeescript), including dependencies that somehow required conflicting versions of the same libraries! (It took building pieces of it on 2 separate VMs and then merging them to get it to work.) All to build what turned out to be a simple little web site that in the end was basically 12 static pages and a simple form. That doesn't make things way easier. When I started programming, the key important things were to focus on getting the data model accurate, getting the business logic correct, validating input properly, and producing the desired output. Now that is maybe 5-10% of our workload, the other 90+% is dealing with dependencies, build tools, frameworks, 57 layers of generic abstraction, and all the fragile interconnections and leaky abstractions and compatibility issues between all of those things needed primarily just to simply display a page of content or handle a CRUD form. Sure, they're beautiful and interesting from an intellectual standpoint, and when they're working properly, they do make things that were once quite difficult a lot easier. But they also add a lot of complexity, require a lot of maintenance, and make the simple things much more complicated. Often, it's as if we're flying a squadron of helicopters down to the corner store to get milk (because isn't that cool and fun?!), and by the time the operation's completed and we've returned home and got all the helicopters repaired, we realize that we forgot the milk, or it's already spoiled, or we ended up with a potato instead. I do love playing with the new toys. React is really cool, a lot of the new stuff is interesting. But all those layers, all that indirection, all that distances us from the domain data and business logic can make it a lot harder to solve real problems and produce real value. Sometimes I just want to build something and not have to deal with all that mess.
- RedneckBob 9y ago
  Never though I'd have to run "make clean && config && autoconf && make && make install" to build a web page.
- Donzo 9y ago
  One of the best things about working for myself is that I write all my web stuff in vanilla JS. While I occasionally make errors, they are easy to identify, understand, and debug because the native features of JS are well-understood by modern browsers. Sometime in the last decade, modern web development moved on without me. I can no longer recognize what people are doing with all of these package managers and why they are doing it. I guess from a corporate stand point, it makes sense. You'd want your developers to be like widgets or sprockets, easily replaceable. Hot swappable. Otherwise these guys might build Daedalus-like spaghetti-code mazes and no one will ever be able to replace them. As a one-man operation, I'll stick with vanilla. It's easy to understand and it works forever.
tzahola 9y ago
Actually that’s pretty much what I would expect if I tried to build interactive applications on top of a declarative document format whose standardization was co-opted by the largest advertisement company, while working with novices straight out of last week’s coding bootcamp eagerly reinventing the wheel out of their lack of experience and mentoring.
skrebbel 9y ago
When I worked in embedded systems and systems programming a decade ago, it was totally normal to spend over a day getting your computer set up after joining a new team. Sounds exactly like what the author describes here, so what changed? What changed is that the browser became a popular application platform, forcing frontenders to deal with the stuff everybody else has been doing for decades. I'm not saying this can't be improved, and there's a huge difference between projects in that respect. I know teams where getting up and running is a matter of installing node, yarn, and running a "yarn install" and It Just Works. But the thing is, build tooling is hard and it always has been. This has little to do with web design, except that designers used to have the comfort to be able to ignore it. And that's harder with single-page web apps.
- pgorczak 9y ago
  Not sure if this is about comfort. Those complicated workflows and interfaces pretty much go against the principles of what designers are trying to achieve with their own work.
- mmargerum 9y ago
  He’s exaggerating. You can download a cli tool that lets you create a react or vue web app with Babel, webpack, hot code loading, etc in one command. It just works. I know because I just did it and built a large app from it . I think I added 3 lines to my webpack config to proxy api calls to me real web server. It’s magical to code on the fly and I think people have a short memory or aren’t old enough to remember hand coding make files and waiting 20 minutes for your app to compile and link. Frameworks like vue.js are elegant as all hell and js has the lowest getting shit done to ceremony ratio of any language I’ve ever used. Sure there’s a few gotchas. Try using c++. Now there’s a minefield.
placebo 9y ago
I think it has a great deal to do with abandoning something simple not because it's not good enough to do the job, but because of fear of being left behind, fear of becoming irrelevant in a world where "new and improved" is introduced at an ever growing frequency. Sure, improvement is a good thing, but the question I think we sometimes forget to ask ourselves is when does the cost involved in certain technological improvements (more learning curves, higher process complexity, energy required to stay on top of the rapidly changing technologies and tools etc.) start to become higher than the benefits produced by the so called improvement. I've been in this field long enough to see how many times hype beats common sense, unnecessary complexity beats simplicity, and emotion beats logic (heck, I'd bet it's a common theme outside the technology sector as well) but I'm optimistic - the bottom line is that things are improving and even though things sometimes seem circular, it's more of an upward spiral.
jbverschoor 9y ago
People should understand that html was a document markup language. This means the flow of text. People are using it for applications too. Many websites are a combination of both: A "frame" with navigational headers etc (application). And a document-view. This document view is what html was indented for. The solution is to use this flex-box (which is simply tsacklayouts etc) for the application, and the document-flow for text. edit: oh, and drop the javascripts
root_axis 9y ago
html, css, and jQuery work just about exactly the same as they did a decade ago, nothing stops you from using tools you already understand. If it was up to facebook then react would be the only framework used on the web; problem solved right? In reality, there are different tools for different needs and if you don't understand the specific problems a tool was made to solve then of course you're going to find it confusing. Just because a tool exists doesn't mean you have to use it. These tools were created to solve specific problems that the creators encountered, if you don't have that problem or don't like the solution then why did you pick the tool? The most baffling part is the strange sense of entitlement as if people releasing their work for free on the internet is a burden to some because now they have to decide if they should use this free option. If you want ES6, typescript, flow, components, css modules, SSR, hot code reloading, "universal" code re-use, postcss, bundling, automatic-code splitting, dead code elimination blah blah blah then that's on YOU. Don't blame the tools because you are enticed by their capabilities but not willing to understand why and how they work. If you don't care about that stuff then problem solved: don't bother with them.
- tonyedgecombe 9y ago
  I do wonder how much of the problem is that most of the tools and libraries comes out of organisations like Facebook and Google who have completely different constraints to the majority of us. React might suit Facebook but it probably isn't a good solution for someone who's application only gets a few hundred hits a day.
  - adventured 9y ago
    It's a complete bifurcation of the Web's technology underpinnings. That will keep getting more dramatic. Developers and their pay will bifurcate similarly more and more as time goes on. AWS has 150 services or so now. How many of those does a 12 employee small business need? None most likely. That business's site gets maybe 1,000 or 3,000 or 10,000 hits per month. It's an absurdity to throw all the new tools, libraries, cloud tech etc. at that. Most of the Web looks like that small site, most sites on the Web get very little traffic. So little that you could run it on a $5 Digital Ocean instance and have over 95% of the droplet's use capacity to spare. Does my insurance agent, who operates his own small business, need machine learning? No. And to the extent he does, it'll be built into the tools provided by various insurance carriers, entirely hidden from his daily business operation activities. So who actually needs all of these tools? You nailed it, it's almost entirely isolated to the 0.1% group, the Facebooks, et al.
bullen 9y ago
I still use tables.
sureaboutthis 9y ago
I have found lately that many web things today are based on fads and they have found their way into the standards. In the past, standards were developed through engineering and computer science. Today it's based on fireworks, explosions and emojis. Speed trumps quality. Do not want to think is the motto or slogan. If there is a framework or library I can use then, great, I don't have to know how it works so I won't bother seems to be the mantra today. Which, in my mind, reminds me of "All in the Family" scene where Gloria is talking to her friend. "Daddy said girls don't have sex, only boys do." Friend: "Then who do the boys have sex with?" Meaning, if no one is doing the thinking, who is going to write the code?
- skrebbel 9y ago
  I wonder which recent new web standards you think are fads. Push notifications? Offline web apps? Multithreading? async/await?
  - sureaboutthis 9y ago
    Not a fad but an example of what I mean (and the only one I can think of this early in the morning). "box-sizing". This seems to have been created because people are unwilling or unable to understand the standard "box model". People find box-sizing is easier for them but it is not necessary as it only combines already available and well understood sizing properties. Worse, many even use the '*' hack to apply it to every element on their site which should make one question forcing browsers to do something browsers don't do natively. iirc, there was, or is, even an effort to make emojis part of the standard! I hesitate to give any example at all because every person who doesn't know the box model will downvote my post for the very reason I gave in my original post.
    - TheCoreh 9y ago
      Box-sizing is not a good example of a standard that was poorly engineered: it actually fixes a poorly engineered standard instead. I understand the box model, which is precisely why I think one should not have to perform mental padding calculations just to know how wide an element will be on screen. Content box sizing (the original standard) also makes CSS less composable (since the results of combining multiple classes are harder to account for). Ergonomics are a very important engineering consideration. The <!DOCTYPE html> tag also forces the browser to "do something it doesn't do natively" (enter standards mode) so does "use strict"; these are concessions one has to make when a platform evolves over 25 years and must remain backwards compatible.
user15128 9y ago
you still can write `<html><body><h1>hello world</h1></body></html>`, there is nothing wrong with it! but once you have written a file-browser with an embedded editor in it or anything else at more complex level, you will consider using react and all the things. because complex things are complex. again, for simple things you can easily use simple tools - maybe you should. but of course once you are using react day in day out because you need it for other things - you might just use it for anything because you are familiar with it.
baybal2 9y ago
>Easy is hard again >JavaScript is a very badly designed programming language (yes, even in its modern form), which I think has caused a lot of problems. Many JS developers don’t know much about programming language design, so they can’t see how bad it is, and they make matters worse by not trying to abstract or use JS in a way that reinforces good PL design methods. I attribute much of this to the cargo culture that always dominated the webdev space. I lost count to how many seasoned devs (5+ year) I met who were telling me that "Framework A" is faster than vanilla JS and DOM with which they were built with, or array methods are for some reason faster than loops without function calls. Another weak side of JS today is it being driven by "design by committee" and attempts to treat the patient by measuring the average body temperature of all patients in a hospital. I put to doubt the level of basic CS proficiency of most JS framework authors. Some times they try to appear smarter than they are.
ktpsns 9y ago
Did anybody notice that the 1997's Hello World example https://frankchimero.com/writing/everything-easy-is-hard-again/images/notepad.gif https://frankchimero.com/writing/everything-easy-is-hard-aga... still works? Open the most easy built-in text editor on your system (even on Android one should be able to do that, isn't it), save it, open it with your browser locally. In some aspects, the evolution of the web is similar to what the C language ecosystem experienced. It was dead simple in the beginning --- however the "Hello World" is still the same! Today's users are more demanding in terms of user interfaces and you will not go far without libraries. Same story with building modern "reactive" websites. I personally like that CSS got more powerful, it allows us to build modern websites without JavaScript. That wasn't possible 20 years ago.
- pmlnr 9y ago
  20 years ago was 1998. CSS was the modern thing. JS was called DHTML and was used for mouse trailing bouncing balls. XMLHttpRequest debuted natively in IE6, which was released in 2001, before that, it was ActiveX and nobody used it. You did create modern sites with CSS, without JS.
  - qznc 9y ago
    The days of the CSS Zen Garden. For me, the good old times. http://www.csszengarden.com/ http://www.csszengarden.com/
    - ktpsns 9y ago
      Indeed! CSS Zen Garden was my holy grail 15 years ago.
  - loopbit 9y ago
    > CSS was the modern thing. JS was called DHTML and was used for mouse trailing bouncing balls. Javascript was called Javascript and was used, mostly, for form validation. Dynamic menus, animations... - all of which you couldn't do with CSS alone - were called DHTML. You could even use Javascript in the server. > [...] before that, it was ActiveX and nobody used it. Plenty of people used ActiveX and it was useful, sometimes, although it limited you to IE. But you are forgetting two of the most widely used technologies of the time: Applets and Flash. Fortunately both are out of modern web development. > You did create modern sites with CSS, without JS. You did create sites with CSS, "modern" sites included JS and DHTML. Then, as now, I found that most people complaining about Javascript were really complaining about bad coders and bad implementations; The browser's DOM back then and the mess that is NPM today. The language itself has bad decisions (weak dynamic types) and good features (functional capabilities), exactly like every other language out there.
keypress 9y ago
I love the way that the the author, skirts totally over Javascript, and yet the threads here are full of mild skirmishing. The closing paragraph is the nicest part of the article, mentioning the benefits of legibility. I never disliked the mechanics of html table based layouts, col and row spans, what wasn't so nice was the attribute soup. That made reading the outlines of the html hard. Back in the day we had tools like Dreamweaver, that had a visual design mode. It was quirky so people resorted to programming html in text editors. What's a real shame is that there wasn't a tool that matured to the point, where you could do a little of both. The most interesting part about a website for me, is usually the content, and the rest is pretty much guff. The nicest thing about simple authoring is that it allows the on-boarding of everyone. Not just arty or programming types. This is why Facebook in part took off. Because it made publishing easy. Weeks, months and even years of development just to get to the point of publishing is rather wasteful. Many sites could simply use a template product. Review the end result. Many web sites still just look not much more than, erm, web sites. And many don't work, or even convey or make the information that you simply want to consume easy to find and digest. Loads of technology is thrown at problem, where a simple site map and text based content will suffice. And if a business isn't reactive to customer requests, or doesn't update relevant content - then a site becomes quite superfluous or even a liability.
Jedi72 9y ago
By chance I ended up at the Berkshire Hathaway (Warren Buffets company, more like mega-conglomerate) website today. http://www.berkshirehathaway.com http://www.berkshirehathaway.com If that site is good enough for one of the worlds most valuable corporations, maybe we're just massively over-doing the entire web? Side note, I laughed really hard when I saw that they had a god damn ad hard-coded on the page hahaha. That's how you end up one of the richest investors of all time, waste nothing.
- jgsimmerman 9y ago
  I came across that site probably seven years ago when I was going through Fortune 100 websites and looking at how they were approaching mobile web design, and I had a good laugh at this one. Glad to see they still haven't changed. :)
- marcodave 9y ago
  one thing for sure, it definitely won't need an AMP version any time ever.
codingdave 9y ago
There is a difference between web design and web application development. If you are a designer making brochure sites for small business, you don't need the modern frameworks and toolkits, and you are over-engineering it if you use them. Everyone needs to take a step back and ask why they are building a web site in the first place. My local hair salon really just needs a brochure, and maybe a scheduling widget. A doctors office would need to add on a payment system. Both of which can be achieved by pulling in a script to use a 3rd party solution, while the core web site can remain plain, static HTML... done in Notepad, if you want to get really simple. When you step up to needing some actual functionality, there still is a line in the sand where a few PHP scripts will do the job, and can just be pushed up to a shared web host. When you cross that line, THEN you need modern tools. And many sites will need to go there. But a boutique design firm should be able to go a long way without, and probably could just hire some devs if they do land a project large and complex enough to need that level of code. Just because you can go complex doesn't mean you should.
- deleted 9y ago
  [deleted]
- Chris_Newton 9y ago
  There is a difference between web design and web application development. If you are a designer making brochure sites for small business, you don't need the modern frameworks and toolkits, and you are over-engineering it if you use them. This is true, but the fundamental argument Frank makes in this article is just as applicable to web applications, if not more so. We are now building significant software that happens to be written in JavaScript and to run in a browser. We call the results web applications, but it’s still just software. The basic principles of building software well are still the same: using modular design to decompose a large system into more manageable parts, separation of concerns, choosing the right data structures and algorithms, being systematic about covering different cases... These are all as relevant to developing front-end web applications as any other non-trivial software. None of those things implies a need for overcomplicated tooling. None of those things implies a need for dependency trees with an unmanageable level of complexity. None of these things requires a combination of trial-and-error coding and rapid deployment. You can build large, complex, robust, useful web applications perfectly well without those things. Usually, good tools are simple and do one job well. The tools that have stood the test of time in my web programming toolbox — things like jQuery, Lodash, SASS, Babel, Browserify, Mocha and React — almost invariably fall into that category. I find much less benefit in tools that require more than a few seconds to set up, depend on anything not obviously related, introduce any non-trivial boilerplate that I’m not almost always going to need, or introduce any sort of non-standard changes to source files that aren’t all but guaranteed to work in the long term. Of course there are no absolute rules here, but it has been my experience that heavyweight frameworks, scaffolding generators, build process and the like often trade off short-term convenience against stability and longevity (and often, worse, understanding what is really happening). Like the current emphasis on continuous/rapid everything, that isn’t necessarily a good trade to make if you’re interested in building larger, more complicated, longer-lived software, as we increasingly are in front-end web development.
xtrapolate 9y ago
When I'm thinking about bloated web frameworks and inefficient libraries, I often come back to memories of 64k demos released by groups such as Farbrausch. Here's what they've pulled off in 2000: https://www.youtube.com/watch?v=Y3n3c_8Nn2Y https://www.youtube.com/watch?v=Y3n3c_8Nn2Y - as somewhat of a "contrast", jQuery alone (3.0.0-alpha1, minified) weighs 84522 bytes. Use (what you deem as) the right tool for the job. As to how we've got to where we are today, there are lots of reasons - but personally, I feel it's pointless to constantly talk about it. Whether things are more complex than they used to be is up for debate, it's entirely subjective. It's natural for things to evolve given the rising popularity and increased demands - but they evolve organically. People flock to frameworks because there's abstraction, and the "dirty work" has been offloaded to a third-party. This saves people time and effort. It's a bet - frameworks come and go, maintainers disappear; that's just the nature of it.
mratzloff 9y ago
Much of the JavaScript ecosystem can be cringeworthy, but recent versions of JavaScript are far better than the days of ES3, and libraries like Babel are high-quality. With modern improvements to XMLHttpRequest, the URL object, and JSX (actually quite easy to use without React), I suspect that creating a fast, modern website using only Babel, Yarn, and a few polyfills (mainly for IE) is quite easy and enjoyable. Of course, if you want a styled date field, autocomplete field, etc., you'll want to use a library, which may have its own dependencies. As for CSS, everyone agrees that flexbox is a godsend.
- victor106 9y ago
  “As for CSS, everyone agrees that flexbox is a godsend.” If flexbox is a godsend CSS Grid is God.
0x445442 9y ago
Web apps are broken and always have been. The whole model was designed to serve and display static hyperlinked documents, not to recreate Excel in a browser. The lure of web apps was serving them from a centrally controlled location thus eliminating the problems that existed with pushing out and updating software on many computers. However, that problem was solved many years ago and I point to iTunes as that inflexion point. It's been easy to push updates to desktop clients for years so the main problem web apps were attempting to solve hasn't been a problem for, like, 15 years. The ultimate irony... The phone app eco-system and how it dwarfs mobile web apps.
mar77i 9y ago
reminds me of http://motherfuckingwebsite.com/ http://motherfuckingwebsite.com/
- komeijist 9y ago
  yeah same here, many takeaways of the article are similar to http://motherfuckingwebsite.com http://motherfuckingwebsite.com to the uninitiated, I recommend also taking a look at http://bettermotherfuckingwebsite.com/ http://bettermotherfuckingwebsite.com/
  - mar77i 9y ago
    Another of my favorites: http://adventurega.me/bootstrap/ http://adventurega.me/bootstrap/
lobo_tuerto 9y ago
I don't get all the ranting. I think the author would be better doing a research about the current technologies for doing websites (as opposed to web apps). For websites I can recommend Bulma, it's an elegant base for modern websites. If you want to manage content for that website you can integrate Hugo an get into the world of static site generators. If you really want to do anything more complex, there is Vue.js. You can still use <table>s for layout if you want, there is nothing forcing you to use CSS Grid. But if you do learn it, you'll be able to produce more complex layouts with a little less effort. There is a free course for that: https://cssgrid.io/ https://cssgrid.io/ I just moved my blog from WordPress to Hugo + Bulma and have been enjoying the journey all along: https://lobotuerto.com https://lobotuerto.com
ThrowAwayFSp 9y ago
>Last month, I had to install a package manager to install a package manager. That’s when I closed my laptop and slowly backed away from it.
devenson 9y ago
It's not hard to make websites, it hard to make fashionable websites. It always takes effort to be fashionable, since it distinguishes your vitality from the dead and dying from yesteryear. If it was easy to fake fashion, everyone would do it, and we'd lose the vitality signal. Fashion changes unpredictably, so it can't be anticipated. All this is a feature, not a bug, so it will never be "solved".
- mrhappyunhappy 9y ago
  Love your comment.
squiggy22 9y ago
Innovation often has casualities and the pace of innovation of the front end particularly has exploded in the last few years combine that with mobile uptake and we have a whole can of soup on our hands. At the moment it feels like we havent quite settled on a proposed standard of build tools and processes which comes across as daunting but imo is also indicative of not reaching the absolute peak. Underneath it all we still have the fundamentals of html css and js and that aint gonna change anytime soon.. I only hope some of the tools we have for layouts settle soon as the browser landscape and chasms are only getting wider as mobile devices and iot throws a whole new can of worms at producing cross browser compatible applications. In my instances that fact alone is choking the web.
lkrubner 9y ago
This is perhaps my favorite part: "If you go talk to a senior software developer, you’ll probably hear them complain about spaghetti code. This is when code is overwrought, unorganized, opaque, and snarled with dependencies. I perked up when I heard the term used for the first time, because, while I can’t identify spaghetti code as a designer, I sure as hell know about spaghetti workflows and spaghetti toolchains. It feels like we’re there now on the web."
whack 9y ago
As a back-end developer, I started off coding ~15 years ago, and hated the entire experience back then. Nowadays, as I look at the tools, frameworks and language enhancements, I'm so glad to be coding in 2018, and not in 2004. The things I can easily accomplish now, far exceed anything I could have done back then. I've heard so many front-end developers/designers say the opposite about their field though, and I wonder why that is. If the newer tools/frameworks are just adding more complexity, or reinventing the wheel, couldn't you just choose not to use them? I suppose some might reply that you're forced to use these new tools/frameworks, because of dependencies on other tools/frameworks that you actually care about. But if that's really the case, and if this frustration is widespread enough, wouldn't people/companies have invested time and effort into supporting the classic-but-equally-good tooling? As someone watching from the outside, I can't imagine a world where an entire industry is running in circles, creating churn devoid of positive value. Maybe I'm too optimistic, but I suspect that many of the complainers are suffering from rose-colored glasses. As a heavy web-user, I've noticed that the functionality and aesthetics of websites have improved dramatically in the past 1-2 decades. The websites I see from the 90s and early 2000s, look like a joke today. I suspect that this improvement is only made possible by the new tooling and frameworks that exist today. That they are indeed more complex, but they still unlock new potential that would be too hard to achieve otherwise. That anyone who tries to use ancient tooling from 10-20 years ago, would find themselves unable to provide an equally good mass-market UX. If this is not the case, I invite someone to prove me wrong.
collinmanderson 9y ago
Addressing the points in the article: "How do I put two things next to each other?" - Just stick with flexbox. It's way easier than floats. If the older methods are easier, just keep using them no problem. "Webfonts?" - 10 years ago we were using "swfir" (flash) for custom fonts. Way harder than font-face. Loading fonts with @font-face doesn't need to be complicated: just serve the woff file and be done with it. There are some optimizations that can be done to make them load faster, but they're not always worth it. SVGs are really nice because you don't need to deal with any resizing. A huge win. Yes, raster images are a little harder because of high-dpi screens. Just send 2x resolution everywhere. Phones are where bandwidth really matters, and they're mostly high-dpi anyway. A 3x dpi phone getting a 2x image is still pretty good. Any of the more complicated solutions are just to make things slightly faster in some cases, which is often not worth it.
wmnwmn 9y ago
This is so true and I'm certain it's related to the noticeable downgrade in web performance and usability over the past five years. So many sites are flabby and slow now because they're retrieving countless packages from CDN's, each time of course with a ssh handshake, etc etc. You can see endless retrievals flashing on the bottom bar, sometimes literally never stopping, as the site keeps doing one thing after another to anticipate what you might want to do, load new content, or whatever. I find the web only barely enjoyable to use anymore. Even the simplest things seem to blow up now, e.g. very often I get "not found" for the Google homepage. Huh? That one's probably on me somehow, but I'm not doing anything different that I know of, but what has changed that I know of is the extreme increase in complexity of internet delivery and programming. And I will just vent one more pet peeve. Not EVERY part of a web page needs to pop something up in your face when you put the mouse over it. Thank you.
stesch 9y ago
I read this article in reader view of the browser.
gjvc 9y ago
This is an excellent piece of writing. The aphorism "Go slow and fix things." is brilliant. I'm stealing that. I implore people reading this thread to watch this Alan Kay video from 1997, where he rather predicts (albeit perhaps implicitly, if not explicitly) that we will reach the situation we are in today. https://www.youtube.com/watch?v=oKg1hTOQXoY https://www.youtube.com/watch?v=oKg1hTOQXoY There is a quote from the talk which rings true with many of the comments here "HTML on the internet has gone back to the dark ages, because it presupposes that there should be a browser which understands its formats" I have found the odd nit with the article: "In one way, it is easier to be inexperienced: you don’t have to learn what is no longer relevant." I think he might mean unlearn, but it's a bit ambiguous. :-)
- devxpy 9y ago
  That talk is truly awesome. Thanks.
  - gjvc 9y ago
    I'm glad you found it useful. Here's a related bonus link :-) https://www.quora.com/Is-there-a-programming-language-thats-effectively-a-successor-to-Smalltalk/answer/Alan-Kay-11 https://www.quora.com/Is-there-a-programming-language-thats-... Dr Kay has been loudly telling us for a long time that we are on the wrong track whilst having already delivered a complete alternative. One can only wonder what his perspective feels like.
abalashov 9y ago
It’s rare that I say someone has truly nailed it, but the author has really nailed it. And while much of the critical response has focused on the difference between design and programming, I can say as someone who has been around the programming block (got started at age 9) that 99% of what he says applies equally well to modern application development and infrastructure.
_pmf_ 9y ago
I'm spending my free time asking on web developer forums how to center something vertically.
kup0 9y ago
This speaks to me strongly, having done this many times: "I’m still not sure I understand it; I type clear: both and say a prayer to the box model."

459 points by josephscott 9y ago

I've just tried to copy paste the title of the article ... but it's impossible ... it's an image. If after 20 years of web design and development you still don't get it, then everything easy is hard again.

anotheryou 9y ago
Why would yo want to triple (I guess even more) your work just to have a semantic title when you can use an alt-text?
- jwilk 9y ago
  But there's no alt text. The code looks like this: <div class="section title"> <h1>Everything Easy is Hard Again</h1> <img src="images/everythingeasy.svg" style="display: block; height:60vw; margin-left:auto; margin-right: auto;"> </div> And <h1> is styled in such a way it's not visible. This is bizarre.
  - fredsted 9y ago
    Bizarre? The h1 is probably there for SEO or screen readers.

golergka 9y ago

I've almost never touched web development, but as an active HN reader I have at least passing familiarity with almost all the terms used in the article. So, honest question: can a person fully understand how modern HTML/CSS work without diving in the source code of one of the browser engines? Because as a developer, if I was forced to use such a complicated technology, grooming source would be my best guess at making any sense out of it.

anotheryou 9y ago
No dive necessary if you don't get close to performance limits of browsers. Actually looking at how it's meant to be first is the only sane way, because browsers do whatever the fuck they want and you just have to see what happens.
GoToRO 9y ago
As as web developer the most important skill to learn is to let go! You fix it for whatever browsers the client uses and forget about the rest.
- afarrell 9y ago
  I suspect your parent comment isn't talking about browser compatibility. I suspect it is about learning enough CSS/HTML to write up a page for one browser without feeling like [venetian blind gif]. https://imgur.com/gallery/Q3cUg29 https://imgur.com/gallery/Q3cUg29
afarrell 9y ago
http://book.mixu.net/css/ http://book.mixu.net/css/ is a reasonable guide and as a backend dev, I've learned to feel more comfortable with HTML/CSS by reading through it multiple times and making flashcards in a Spaced Repetition app.
TheAceOfHearts 9y ago
Yes. Read the whatwg HTML spec for developers [0]. Understanding ALL of CSS is tricky, because it has a long history. It's also incredibly tricky to understand how it all works together when different display modes are combined. But you don't need to understand ALL the parts in order to build something useful. Just skip over the parts you won't be using. Do you think any of the alternatives are truly much better? [0] https://html.spec.whatwg.org/dev/ https://html.spec.whatwg.org/dev/

dvfjsdhgfv 9y ago

I completely share the thoughts of the author of this article. However, I'm not sure if his proposed solution would work for most people. It's not that I want or like to use npm etc. - I'm forced to use them as it's the new default way of working with almost anything useful in today's web development work. An alternative would be to start from scratch - and then reinventing all these things again, making another full circle. There could be another solution. A lot of today's complexity of the web stems from the fact that we're trying to design (web) apps using (HTML) documents. It's like building user interfaces in Word (without VBA). You can, but there are much better ways to do it. Why not to define a set of APIs for creating GUIs? Yes, I mean something like XUL which failed because nobody except Mozilla cared. Make it standard, make it easily themeable, and we can finally throw away this mess of ugly hacks used now to create intricate GUIs for which we have dedicated widgets on the desktop and which we have to reimplement on the web, with mixed results.

Nition 9y ago
Yeah, I agree with both you and the article. The biggest problem with website design seems to be that it's all layers on layers on a base that wasn't so great for design in the first place.
deleted 9y ago
[deleted]
mattmanser 9y ago
Crikey, even the 'reasons' are circular. People were saying that was the problem 10 years ago. Those exact words. Apps aren't docs. All you need to do now is propose a new language and call it XHTML. Or maybe make markup extensible and functional, we could call it, ummmmmm, XSLT.
- grndn 9y ago
  I came here to say the same thing. :) The fundamental problem is that you want one piece of (semantic) content to be presented on many different platforms with very different design approaches. The current approach uses if-then-else conditions in CSS, and when that fails, if-then-else conditions in JS, and when that fails, complex JS to transform the DOM. The XML/XSLT approach, although clunky, might actually be better in many cases.

randomsearch 9y ago

This is my experience of web development, every time I return to it. I’m really not an expert in web dev, but it _feels_ like web dev has been badly engineered. JavaScript is a very badly designed programming language (yes, even in its modern form), which I think has caused a lot of problems. Many JS developers don’t know much about programming language design, so they can’t see how bad it is, and they make matters worse by not trying to abstract or use JS in a way that reinforces good PL design methods. If you recognise JS as a terribly designed language, then the last thing you would imagine doing is widening its use. But that is exactly what node.js does. You should instead isolate JS and minimise its use. So red flag - something has gone wrong here. It also feels that many web ecosystems have an over-inflated sense of self-importance. This has led to many competing frameworks for the same tasks, that try to do everything. Things are not pythonic. There appear to be an excessive number of package managers involved. There were already plenty of package managers out there - inventing new versions of existing tech makes it harder for everyone and is usually a red flag that someone somewhere is making bad decisions. I need to build a website soon and I’m dreading the front end. At the back end I can use range of solid and well designed languages and technologies, but at the front end I feel like I’ve got to choose the least poor of a bunch of crazy options. If anyone has advice on how someone who prefers rigour, simplicity, elegance, and decent PL design over the latest trend should approach web dev that would be massively helpful. “Sane web dev to minimise the impact of the Web Dev CSS/JS disaster on your life” would be my favourite O’Reilly of all time.

keldaris 9y ago
I'm in a similar position, and I've formed the same impression. Furthermore, even though browsers are stuck with JS, given the influx of languages able to compile to JS (or even WebAssembly now) it feels like there should be plenty of options for those of us who would rather stay away from the craziness. Perhaps someone with more frontend experience could comment on what (comparatively) sane, simple and JS-minimizing options are there now?
- Vinnl 9y ago
  Compiling-to-JS brings in its own set of crazy, and really almost never is worth it. In fact, the only two that make any sense are Babel and TypeScript, and that is only because are (practically) Javascript and because they are stable and widely used projects. If those two wouldn't hold, you'll quickly be running into a whole host of problems w.r.t. interoperability with the rest of the ecosystem, and you'll end up reinventing the wheel again.

vex3d 9y ago

No it's not. You decided to make "easy" tasks complicated. Then rather than learning about new technology you wrote a blog moaning about it. Just stick the basics if that's what you want to do. No need for loaders or preprocessors if you don't want to use them.

dmitriid 9y ago

I've recently realised that most of modern day's web stem from the fact that it's not a platform. It's still just a barely functioning system to display text documents. That's where all the complexity comes from: people are trying to build/collect the missing pieces of a platform, and then try to build their stuff on top of it. And you can see it everywhere: from CSS (which still pretends that modularity doesn't exist or that complex constraints in layouts do not exist) to DOM (which hasn't seen a proper API design in years) to Javascript (whose idea of a standard library is adding an underspecified `fetch` after 15 years of people writing wrappers around XMLHttpRequest).

ccachor 9y ago
"(whose idea of a standard library is adding an underspecified `fetch` after 15 years of people writing wrappers around XMLHttpRequest)." So true.

ohazi 9y ago

Choice quotes: > Directness is best in my experience, so a great photo, memorable illustration, or pitch-perfect sentence does most of the work. Beyond that, fancy implementation has never moved the needle much for my clients. > Last month, I had to install a package manager to install a package manager. ... I sure as hell know about spaghetti workflows and spaghetti toolchains. It feels like we’re there now on the web.

Vinnl 9y ago
If I want to install Pip, Maven or what-have-you, I'd be using apt.
- JetSpiegel 9y ago
  You don't install apt, it comes standard.
  - Vinnl 9y ago
    The point is that I'm using a package manager to install a package manager, which is supposedly bad.
- thaumasiotes 9y ago
  If I wanted to install pip, I'd install virtualenv. (I'd use apt to install virtualenv, sure, but using apt to install pip will eventually turn out to be a mistake.)
lultimouomo 9y ago
My personal favorite: > I type clear: both and say a prayer to the box model.

megaman22 9y ago

> There’s a voice in the back of my head saying we’re stuck in a loop and it’s repeating. We’ve completed a lap on a cycle which will go around forever. Another approach for layout will come along five years from now, it will probably resemble floats, and not knowing how to clear a float will bite me in the ass for the second time in my career. This is what I feel like everytime I try to keep up with web tech... For crissakes, the last training I went to had a session on Razor Pages, which set off my PTSD from years of doing ASP.NET WebForms, back before we decided that was a really awful, painful way to do things.

helenius 9y ago

Maybe somewhat related: can anybody guess what the idea behind the images in this article is? <img src="/images/trans.gif" data-src="images/speaking.png"> trans.gif is just a 1x1px invisible pixel.

merlincorey 9y ago
Tracking scripts don't need to do anything but read the hit in the access log. That said, it's also trivially easy to output the bytes for a 1x1 invisible gif as the response from your tracking endpoint.
- Piskvorrr 9y ago
  It is easy, but is it fast? Serving a static GIF has an overhead of ~0, and it doesn't need any executable beyond the HTTP server to run on the machine, except to move the logs out for processing (syslog, rsync, what-have-you, in most cases out-of-band wrt the HTTP server).
culturedsystems 9y ago
It's lazy loading the images - when the page initially loads, it only loads one small image (trans.gif), and the file specified in the data-src attribute isn't loaded until you scroll near to the img tag. Specifically, it's using this plugin: http://luis-almeida.github.io/unveil/ http://luis-almeida.github.io/unveil/
- acqq 9y ago
  The given use of that on frankchimero.com is bad. If I use uMatrix then even enabling scripts for the site won't show the images. Moreover, if the javascript is turned off completely, the proper approach for the given task is having the <noscript and the images properly specified. One of the images is just a PNG of an emoji U+1F632 (my guess). Another of the emoji of the cake. He could have saved on these two completely. That leaves us with the tile svg and the 170K PNG for the face of the author, which should obviously be a 40K JPG. Finally, the img tags on that page don't contain dimensions, whereas it's probably(1) better to still have them: https://www.computerhope.com/issues/ch001158.htm https://www.computerhope.com/issues/ch001158.htm Given the topic of the post (the need to keep things simple when making web pages), I consider these observations relevant. 1) Probably as I'm not in the business and I don't follow most recent developments so I don't know if the arguments from computerhope.com are obsolete by the most recent standards or implementations, so all relevant technical information is welcome.

danieltillett 9y ago

The whole thing is driven by all fields reaching the highest level of complexity their practitioners can understand. Web design in not inherently complex, but it is filled with lots of talented and intelligent people because the pay is good and the conditions cushy compared to say gutting chickens in some factory. The only way to solve to the complexity treadmill is to drive out all the smart people.

tonyedgecombe 9y ago
We do have a tendency to make things as complex as we can, which if you are smart is too complex for the majority.

factsaresacred 9y ago

Well written and beautifully presented but these are complaints about progress. > 'my limited needs...Simple, responsive layout' As we all know, limited/simple in the requirements doesn't mean simple to implement. "I want this page to look the same on any size screen, whether viewed horizontally or vertically". OK. It's surprising it's as simple as it is. > 'I thought implementing webfonts was a relatively easy procedure, but I guess not!' No, it is easy. If you want to read 90 pages of marketing-promo disguised as a guide to fonts, do so. But you don't have to. Go to google fonts, pick one, add the URL to the head of your webpage, done. > We’re a long way from the CSS Zen Garden where I started. That way is still there. It's just slow and messy. You can still inline your CSS, use external css files. Whatever you want. > Before, the websites could explain themselves; now, someone needs to walk you through it. Before, scrolling text and gifs were the cutting edge of web technology. Now we have Photoshop, online IDEs, real-time trading applications in the browser. This is magic. And magic isn't easy. Furthermore, modern browser element inspectors provide an excellent explanation of what's happening on a webpage. The web isn't static - as the browser advances we use new tools to handle the possibility as well as the complexity. But the old ways are still available. Although I'm not convinced that the 30 minutes of mental overhead getting to know npm and flexbox beats the mess of external resources, duplicate code and utter pain that was the web of the past.

Falkon1313 9y ago

>simply npm your webpack via grunt with vue babel or bower to react asdfjkl;lkdhgxdlciuhw >[...] >I had to install a package manager to install a package manager. And that's coming from a designer, not a programmer. A few years ago I had to take over a project that required installing something like 6 different package managers, 2 build systems, and a dozen different languages (counting things like jade and coffeescript), including dependencies that somehow required conflicting versions of the same libraries! (It took building pieces of it on 2 separate VMs and then merging them to get it to work.) All to build what turned out to be a simple little web site that in the end was basically 12 static pages and a simple form. That doesn't make things way easier. When I started programming, the key important things were to focus on getting the data model accurate, getting the business logic correct, validating input properly, and producing the desired output. Now that is maybe 5-10% of our workload, the other 90+% is dealing with dependencies, build tools, frameworks, 57 layers of generic abstraction, and all the fragile interconnections and leaky abstractions and compatibility issues between all of those things needed primarily just to simply display a page of content or handle a CRUD form. Sure, they're beautiful and interesting from an intellectual standpoint, and when they're working properly, they do make things that were once quite difficult a lot easier. But they also add a lot of complexity, require a lot of maintenance, and make the simple things much more complicated. Often, it's as if we're flying a squadron of helicopters down to the corner store to get milk (because isn't that cool and fun?!), and by the time the operation's completed and we've returned home and got all the helicopters repaired, we realize that we forgot the milk, or it's already spoiled, or we ended up with a potato instead. I do love playing with the new toys. React is really cool, a lot of the new stuff is interesting. But all those layers, all that indirection, all that distances us from the domain data and business logic can make it a lot harder to solve real problems and produce real value. Sometimes I just want to build something and not have to deal with all that mess.

RedneckBob 9y ago
Never though I'd have to run "make clean && config && autoconf && make && make install" to build a web page.
Donzo 9y ago
One of the best things about working for myself is that I write all my web stuff in vanilla JS. While I occasionally make errors, they are easy to identify, understand, and debug because the native features of JS are well-understood by modern browsers. Sometime in the last decade, modern web development moved on without me. I can no longer recognize what people are doing with all of these package managers and why they are doing it. I guess from a corporate stand point, it makes sense. You'd want your developers to be like widgets or sprockets, easily replaceable. Hot swappable. Otherwise these guys might build Daedalus-like spaghetti-code mazes and no one will ever be able to replace them. As a one-man operation, I'll stick with vanilla. It's easy to understand and it works forever.

tzahola 9y ago

Actually that’s pretty much what I would expect if I tried to build interactive applications on top of a declarative document format whose standardization was co-opted by the largest advertisement company, while working with novices straight out of last week’s coding bootcamp eagerly reinventing the wheel out of their lack of experience and mentoring.

skrebbel 9y ago

When I worked in embedded systems and systems programming a decade ago, it was totally normal to spend over a day getting your computer set up after joining a new team. Sounds exactly like what the author describes here, so what changed? What changed is that the browser became a popular application platform, forcing frontenders to deal with the stuff everybody else has been doing for decades. I'm not saying this can't be improved, and there's a huge difference between projects in that respect. I know teams where getting up and running is a matter of installing node, yarn, and running a "yarn install" and It Just Works. But the thing is, build tooling is hard and it always has been. This has little to do with web design, except that designers used to have the comfort to be able to ignore it. And that's harder with single-page web apps.

pgorczak 9y ago
Not sure if this is about comfort. Those complicated workflows and interfaces pretty much go against the principles of what designers are trying to achieve with their own work.
mmargerum 9y ago
He’s exaggerating. You can download a cli tool that lets you create a react or vue web app with Babel, webpack, hot code loading, etc in one command. It just works. I know because I just did it and built a large app from it . I think I added 3 lines to my webpack config to proxy api calls to me real web server. It’s magical to code on the fly and I think people have a short memory or aren’t old enough to remember hand coding make files and waiting 20 minutes for your app to compile and link. Frameworks like vue.js are elegant as all hell and js has the lowest getting shit done to ceremony ratio of any language I’ve ever used. Sure there’s a few gotchas. Try using c++. Now there’s a minefield.

placebo 9y ago

I think it has a great deal to do with abandoning something simple not because it's not good enough to do the job, but because of fear of being left behind, fear of becoming irrelevant in a world where "new and improved" is introduced at an ever growing frequency. Sure, improvement is a good thing, but the question I think we sometimes forget to ask ourselves is when does the cost involved in certain technological improvements (more learning curves, higher process complexity, energy required to stay on top of the rapidly changing technologies and tools etc.) start to become higher than the benefits produced by the so called improvement. I've been in this field long enough to see how many times hype beats common sense, unnecessary complexity beats simplicity, and emotion beats logic (heck, I'd bet it's a common theme outside the technology sector as well) but I'm optimistic - the bottom line is that things are improving and even though things sometimes seem circular, it's more of an upward spiral.

jbverschoor 9y ago

People should understand that html was a document markup language. This means the flow of text. People are using it for applications too. Many websites are a combination of both: A "frame" with navigational headers etc (application). And a document-view. This document view is what html was indented for. The solution is to use this flex-box (which is simply tsacklayouts etc) for the application, and the document-flow for text. edit: oh, and drop the javascripts

root_axis 9y ago

html, css, and jQuery work just about exactly the same as they did a decade ago, nothing stops you from using tools you already understand. If it was up to facebook then react would be the only framework used on the web; problem solved right? In reality, there are different tools for different needs and if you don't understand the specific problems a tool was made to solve then of course you're going to find it confusing. Just because a tool exists doesn't mean you have to use it. These tools were created to solve specific problems that the creators encountered, if you don't have that problem or don't like the solution then why did you pick the tool? The most baffling part is the strange sense of entitlement as if people releasing their work for free on the internet is a burden to some because now they have to decide if they should use this free option. If you want ES6, typescript, flow, components, css modules, SSR, hot code reloading, "universal" code re-use, postcss, bundling, automatic-code splitting, dead code elimination blah blah blah then that's on YOU. Don't blame the tools because you are enticed by their capabilities but not willing to understand why and how they work. If you don't care about that stuff then problem solved: don't bother with them.

tonyedgecombe 9y ago
I do wonder how much of the problem is that most of the tools and libraries comes out of organisations like Facebook and Google who have completely different constraints to the majority of us. React might suit Facebook but it probably isn't a good solution for someone who's application only gets a few hundred hits a day.
- adventured 9y ago
  It's a complete bifurcation of the Web's technology underpinnings. That will keep getting more dramatic. Developers and their pay will bifurcate similarly more and more as time goes on. AWS has 150 services or so now. How many of those does a 12 employee small business need? None most likely. That business's site gets maybe 1,000 or 3,000 or 10,000 hits per month. It's an absurdity to throw all the new tools, libraries, cloud tech etc. at that. Most of the Web looks like that small site, most sites on the Web get very little traffic. So little that you could run it on a $5 Digital Ocean instance and have over 95% of the droplet's use capacity to spare. Does my insurance agent, who operates his own small business, need machine learning? No. And to the extent he does, it'll be built into the tools provided by various insurance carriers, entirely hidden from his daily business operation activities. So who actually needs all of these tools? You nailed it, it's almost entirely isolated to the 0.1% group, the Facebooks, et al.

bullen 9y ago

I still use tables.

sureaboutthis 9y ago

I have found lately that many web things today are based on fads and they have found their way into the standards. In the past, standards were developed through engineering and computer science. Today it's based on fireworks, explosions and emojis. Speed trumps quality. Do not want to think is the motto or slogan. If there is a framework or library I can use then, great, I don't have to know how it works so I won't bother seems to be the mantra today. Which, in my mind, reminds me of "All in the Family" scene where Gloria is talking to her friend. "Daddy said girls don't have sex, only boys do." Friend: "Then who do the boys have sex with?" Meaning, if no one is doing the thinking, who is going to write the code?

skrebbel 9y ago
I wonder which recent new web standards you think are fads. Push notifications? Offline web apps? Multithreading? async/await?
- sureaboutthis 9y ago
  Not a fad but an example of what I mean (and the only one I can think of this early in the morning). "box-sizing". This seems to have been created because people are unwilling or unable to understand the standard "box model". People find box-sizing is easier for them but it is not necessary as it only combines already available and well understood sizing properties. Worse, many even use the '*' hack to apply it to every element on their site which should make one question forcing browsers to do something browsers don't do natively. iirc, there was, or is, even an effort to make emojis part of the standard! I hesitate to give any example at all because every person who doesn't know the box model will downvote my post for the very reason I gave in my original post.
  - TheCoreh 9y ago
    Box-sizing is not a good example of a standard that was poorly engineered: it actually fixes a poorly engineered standard instead. I understand the box model, which is precisely why I think one should not have to perform mental padding calculations just to know how wide an element will be on screen. Content box sizing (the original standard) also makes CSS less composable (since the results of combining multiple classes are harder to account for). Ergonomics are a very important engineering consideration. The <!DOCTYPE html> tag also forces the browser to "do something it doesn't do natively" (enter standards mode) so does "use strict"; these are concessions one has to make when a platform evolves over 25 years and must remain backwards compatible.

user15128 9y ago

you still can write `<html><body><h1>hello world</h1></body></html>`, there is nothing wrong with it! but once you have written a file-browser with an embedded editor in it or anything else at more complex level, you will consider using react and all the things. because complex things are complex. again, for simple things you can easily use simple tools - maybe you should. but of course once you are using react day in day out because you need it for other things - you might just use it for anything because you are familiar with it.

baybal2 9y ago

>Easy is hard again >JavaScript is a very badly designed programming language (yes, even in its modern form), which I think has caused a lot of problems. Many JS developers don’t know much about programming language design, so they can’t see how bad it is, and they make matters worse by not trying to abstract or use JS in a way that reinforces good PL design methods. I attribute much of this to the cargo culture that always dominated the webdev space. I lost count to how many seasoned devs (5+ year) I met who were telling me that "Framework A" is faster than vanilla JS and DOM with which they were built with, or array methods are for some reason faster than loops without function calls. Another weak side of JS today is it being driven by "design by committee" and attempts to treat the patient by measuring the average body temperature of all patients in a hospital. I put to doubt the level of basic CS proficiency of most JS framework authors. Some times they try to appear smarter than they are.

ktpsns 9y ago

Did anybody notice that the 1997's Hello World example https://frankchimero.com/writing/everything-easy-is-hard-again/images/notepad.gif https://frankchimero.com/writing/everything-easy-is-hard-aga... still works? Open the most easy built-in text editor on your system (even on Android one should be able to do that, isn't it), save it, open it with your browser locally. In some aspects, the evolution of the web is similar to what the C language ecosystem experienced. It was dead simple in the beginning --- however the "Hello World" is still the same! Today's users are more demanding in terms of user interfaces and you will not go far without libraries. Same story with building modern "reactive" websites. I personally like that CSS got more powerful, it allows us to build modern websites without JavaScript. That wasn't possible 20 years ago.

pmlnr 9y ago
20 years ago was 1998. CSS was the modern thing. JS was called DHTML and was used for mouse trailing bouncing balls. XMLHttpRequest debuted natively in IE6, which was released in 2001, before that, it was ActiveX and nobody used it. You did create modern sites with CSS, without JS.
- qznc 9y ago
  The days of the CSS Zen Garden. For me, the good old times. http://www.csszengarden.com/ http://www.csszengarden.com/
  - ktpsns 9y ago
    Indeed! CSS Zen Garden was my holy grail 15 years ago.
- loopbit 9y ago
  > CSS was the modern thing. JS was called DHTML and was used for mouse trailing bouncing balls. Javascript was called Javascript and was used, mostly, for form validation. Dynamic menus, animations... - all of which you couldn't do with CSS alone - were called DHTML. You could even use Javascript in the server. > [...] before that, it was ActiveX and nobody used it. Plenty of people used ActiveX and it was useful, sometimes, although it limited you to IE. But you are forgetting two of the most widely used technologies of the time: Applets and Flash. Fortunately both are out of modern web development. > You did create modern sites with CSS, without JS. You did create sites with CSS, "modern" sites included JS and DHTML. Then, as now, I found that most people complaining about Javascript were really complaining about bad coders and bad implementations; The browser's DOM back then and the mess that is NPM today. The language itself has bad decisions (weak dynamic types) and good features (functional capabilities), exactly like every other language out there.

keypress 9y ago

I love the way that the the author, skirts totally over Javascript, and yet the threads here are full of mild skirmishing. The closing paragraph is the nicest part of the article, mentioning the benefits of legibility. I never disliked the mechanics of html table based layouts, col and row spans, what wasn't so nice was the attribute soup. That made reading the outlines of the html hard. Back in the day we had tools like Dreamweaver, that had a visual design mode. It was quirky so people resorted to programming html in text editors. What's a real shame is that there wasn't a tool that matured to the point, where you could do a little of both. The most interesting part about a website for me, is usually the content, and the rest is pretty much guff. The nicest thing about simple authoring is that it allows the on-boarding of everyone. Not just arty or programming types. This is why Facebook in part took off. Because it made publishing easy. Weeks, months and even years of development just to get to the point of publishing is rather wasteful. Many sites could simply use a template product. Review the end result. Many web sites still just look not much more than, erm, web sites. And many don't work, or even convey or make the information that you simply want to consume easy to find and digest. Loads of technology is thrown at problem, where a simple site map and text based content will suffice. And if a business isn't reactive to customer requests, or doesn't update relevant content - then a site becomes quite superfluous or even a liability.

Jedi72 9y ago

By chance I ended up at the Berkshire Hathaway (Warren Buffets company, more like mega-conglomerate) website today. http://www.berkshirehathaway.com http://www.berkshirehathaway.com If that site is good enough for one of the worlds most valuable corporations, maybe we're just massively over-doing the entire web? Side note, I laughed really hard when I saw that they had a god damn ad hard-coded on the page hahaha. That's how you end up one of the richest investors of all time, waste nothing.

jgsimmerman 9y ago
I came across that site probably seven years ago when I was going through Fortune 100 websites and looking at how they were approaching mobile web design, and I had a good laugh at this one. Glad to see they still haven't changed. :)
marcodave 9y ago
one thing for sure, it definitely won't need an AMP version any time ever.

codingdave 9y ago

There is a difference between web design and web application development. If you are a designer making brochure sites for small business, you don't need the modern frameworks and toolkits, and you are over-engineering it if you use them. Everyone needs to take a step back and ask why they are building a web site in the first place. My local hair salon really just needs a brochure, and maybe a scheduling widget. A doctors office would need to add on a payment system. Both of which can be achieved by pulling in a script to use a 3rd party solution, while the core web site can remain plain, static HTML... done in Notepad, if you want to get really simple. When you step up to needing some actual functionality, there still is a line in the sand where a few PHP scripts will do the job, and can just be pushed up to a shared web host. When you cross that line, THEN you need modern tools. And many sites will need to go there. But a boutique design firm should be able to go a long way without, and probably could just hire some devs if they do land a project large and complex enough to need that level of code. Just because you can go complex doesn't mean you should.

deleted 9y ago
[deleted]
Chris_Newton 9y ago
There is a difference between web design and web application development. If you are a designer making brochure sites for small business, you don't need the modern frameworks and toolkits, and you are over-engineering it if you use them. This is true, but the fundamental argument Frank makes in this article is just as applicable to web applications, if not more so. We are now building significant software that happens to be written in JavaScript and to run in a browser. We call the results web applications, but it’s still just software. The basic principles of building software well are still the same: using modular design to decompose a large system into more manageable parts, separation of concerns, choosing the right data structures and algorithms, being systematic about covering different cases... These are all as relevant to developing front-end web applications as any other non-trivial software. None of those things implies a need for overcomplicated tooling. None of those things implies a need for dependency trees with an unmanageable level of complexity. None of these things requires a combination of trial-and-error coding and rapid deployment. You can build large, complex, robust, useful web applications perfectly well without those things. Usually, good tools are simple and do one job well. The tools that have stood the test of time in my web programming toolbox — things like jQuery, Lodash, SASS, Babel, Browserify, Mocha and React — almost invariably fall into that category. I find much less benefit in tools that require more than a few seconds to set up, depend on anything not obviously related, introduce any non-trivial boilerplate that I’m not almost always going to need, or introduce any sort of non-standard changes to source files that aren’t all but guaranteed to work in the long term. Of course there are no absolute rules here, but it has been my experience that heavyweight frameworks, scaffolding generators, build process and the like often trade off short-term convenience against stability and longevity (and often, worse, understanding what is really happening). Like the current emphasis on continuous/rapid everything, that isn’t necessarily a good trade to make if you’re interested in building larger, more complicated, longer-lived software, as we increasingly are in front-end web development.

xtrapolate 9y ago

When I'm thinking about bloated web frameworks and inefficient libraries, I often come back to memories of 64k demos released by groups such as Farbrausch. Here's what they've pulled off in 2000: https://www.youtube.com/watch?v=Y3n3c_8Nn2Y https://www.youtube.com/watch?v=Y3n3c_8Nn2Y - as somewhat of a "contrast", jQuery alone (3.0.0-alpha1, minified) weighs 84522 bytes. Use (what you deem as) the right tool for the job. As to how we've got to where we are today, there are lots of reasons - but personally, I feel it's pointless to constantly talk about it. Whether things are more complex than they used to be is up for debate, it's entirely subjective. It's natural for things to evolve given the rising popularity and increased demands - but they evolve organically. People flock to frameworks because there's abstraction, and the "dirty work" has been offloaded to a third-party. This saves people time and effort. It's a bet - frameworks come and go, maintainers disappear; that's just the nature of it.

mratzloff 9y ago

Much of the JavaScript ecosystem can be cringeworthy, but recent versions of JavaScript are far better than the days of ES3, and libraries like Babel are high-quality. With modern improvements to XMLHttpRequest, the URL object, and JSX (actually quite easy to use without React), I suspect that creating a fast, modern website using only Babel, Yarn, and a few polyfills (mainly for IE) is quite easy and enjoyable. Of course, if you want a styled date field, autocomplete field, etc., you'll want to use a library, which may have its own dependencies. As for CSS, everyone agrees that flexbox is a godsend.

victor106 9y ago
“As for CSS, everyone agrees that flexbox is a godsend.” If flexbox is a godsend CSS Grid is God.

0x445442 9y ago

Web apps are broken and always have been. The whole model was designed to serve and display static hyperlinked documents, not to recreate Excel in a browser. The lure of web apps was serving them from a centrally controlled location thus eliminating the problems that existed with pushing out and updating software on many computers. However, that problem was solved many years ago and I point to iTunes as that inflexion point. It's been easy to push updates to desktop clients for years so the main problem web apps were attempting to solve hasn't been a problem for, like, 15 years. The ultimate irony... The phone app eco-system and how it dwarfs mobile web apps.

mar77i 9y ago

reminds me of http://motherfuckingwebsite.com/ http://motherfuckingwebsite.com/

komeijist 9y ago
yeah same here, many takeaways of the article are similar to http://motherfuckingwebsite.com http://motherfuckingwebsite.com to the uninitiated, I recommend also taking a look at http://bettermotherfuckingwebsite.com/ http://bettermotherfuckingwebsite.com/
- mar77i 9y ago
  Another of my favorites: http://adventurega.me/bootstrap/ http://adventurega.me/bootstrap/

lobo_tuerto 9y ago

I don't get all the ranting. I think the author would be better doing a research about the current technologies for doing websites (as opposed to web apps). For websites I can recommend Bulma, it's an elegant base for modern websites. If you want to manage content for that website you can integrate Hugo an get into the world of static site generators. If you really want to do anything more complex, there is Vue.js. You can still use <table>s for layout if you want, there is nothing forcing you to use CSS Grid. But if you do learn it, you'll be able to produce more complex layouts with a little less effort. There is a free course for that: https://cssgrid.io/ https://cssgrid.io/ I just moved my blog from WordPress to Hugo + Bulma and have been enjoying the journey all along: https://lobotuerto.com https://lobotuerto.com

ThrowAwayFSp 9y ago

>Last month, I had to install a package manager to install a package manager. That’s when I closed my laptop and slowly backed away from it.

devenson 9y ago

It's not hard to make websites, it hard to make fashionable websites. It always takes effort to be fashionable, since it distinguishes your vitality from the dead and dying from yesteryear. If it was easy to fake fashion, everyone would do it, and we'd lose the vitality signal. Fashion changes unpredictably, so it can't be anticipated. All this is a feature, not a bug, so it will never be "solved".

mrhappyunhappy 9y ago
Love your comment.

squiggy22 9y ago

Innovation often has casualities and the pace of innovation of the front end particularly has exploded in the last few years combine that with mobile uptake and we have a whole can of soup on our hands. At the moment it feels like we havent quite settled on a proposed standard of build tools and processes which comes across as daunting but imo is also indicative of not reaching the absolute peak. Underneath it all we still have the fundamentals of html css and js and that aint gonna change anytime soon.. I only hope some of the tools we have for layouts settle soon as the browser landscape and chasms are only getting wider as mobile devices and iot throws a whole new can of worms at producing cross browser compatible applications. In my instances that fact alone is choking the web.

lkrubner 9y ago

This is perhaps my favorite part: "If you go talk to a senior software developer, you’ll probably hear them complain about spaghetti code. This is when code is overwrought, unorganized, opaque, and snarled with dependencies. I perked up when I heard the term used for the first time, because, while I can’t identify spaghetti code as a designer, I sure as hell know about spaghetti workflows and spaghetti toolchains. It feels like we’re there now on the web."

whack 9y ago

As a back-end developer, I started off coding ~15 years ago, and hated the entire experience back then. Nowadays, as I look at the tools, frameworks and language enhancements, I'm so glad to be coding in 2018, and not in 2004. The things I can easily accomplish now, far exceed anything I could have done back then. I've heard so many front-end developers/designers say the opposite about their field though, and I wonder why that is. If the newer tools/frameworks are just adding more complexity, or reinventing the wheel, couldn't you just choose not to use them? I suppose some might reply that you're forced to use these new tools/frameworks, because of dependencies on other tools/frameworks that you actually care about. But if that's really the case, and if this frustration is widespread enough, wouldn't people/companies have invested time and effort into supporting the classic-but-equally-good tooling? As someone watching from the outside, I can't imagine a world where an entire industry is running in circles, creating churn devoid of positive value. Maybe I'm too optimistic, but I suspect that many of the complainers are suffering from rose-colored glasses. As a heavy web-user, I've noticed that the functionality and aesthetics of websites have improved dramatically in the past 1-2 decades. The websites I see from the 90s and early 2000s, look like a joke today. I suspect that this improvement is only made possible by the new tooling and frameworks that exist today. That they are indeed more complex, but they still unlock new potential that would be too hard to achieve otherwise. That anyone who tries to use ancient tooling from 10-20 years ago, would find themselves unable to provide an equally good mass-market UX. If this is not the case, I invite someone to prove me wrong.

collinmanderson 9y ago

Addressing the points in the article: "How do I put two things next to each other?" - Just stick with flexbox. It's way easier than floats. If the older methods are easier, just keep using them no problem. "Webfonts?" - 10 years ago we were using "swfir" (flash) for custom fonts. Way harder than font-face. Loading fonts with @font-face doesn't need to be complicated: just serve the woff file and be done with it. There are some optimizations that can be done to make them load faster, but they're not always worth it. SVGs are really nice because you don't need to deal with any resizing. A huge win. Yes, raster images are a little harder because of high-dpi screens. Just send 2x resolution everywhere. Phones are where bandwidth really matters, and they're mostly high-dpi anyway. A 3x dpi phone getting a 2x image is still pretty good. Any of the more complicated solutions are just to make things slightly faster in some cases, which is often not worth it.

wmnwmn 9y ago

This is so true and I'm certain it's related to the noticeable downgrade in web performance and usability over the past five years. So many sites are flabby and slow now because they're retrieving countless packages from CDN's, each time of course with a ssh handshake, etc etc. You can see endless retrievals flashing on the bottom bar, sometimes literally never stopping, as the site keeps doing one thing after another to anticipate what you might want to do, load new content, or whatever. I find the web only barely enjoyable to use anymore. Even the simplest things seem to blow up now, e.g. very often I get "not found" for the Google homepage. Huh? That one's probably on me somehow, but I'm not doing anything different that I know of, but what has changed that I know of is the extreme increase in complexity of internet delivery and programming. And I will just vent one more pet peeve. Not EVERY part of a web page needs to pop something up in your face when you put the mouse over it. Thank you.

stesch 9y ago

I read this article in reader view of the browser.

gjvc 9y ago

This is an excellent piece of writing. The aphorism "Go slow and fix things." is brilliant. I'm stealing that. I implore people reading this thread to watch this Alan Kay video from 1997, where he rather predicts (albeit perhaps implicitly, if not explicitly) that we will reach the situation we are in today. https://www.youtube.com/watch?v=oKg1hTOQXoY https://www.youtube.com/watch?v=oKg1hTOQXoY There is a quote from the talk which rings true with many of the comments here "HTML on the internet has gone back to the dark ages, because it presupposes that there should be a browser which understands its formats" I have found the odd nit with the article: "In one way, it is easier to be inexperienced: you don’t have to learn what is no longer relevant." I think he might mean unlearn, but it's a bit ambiguous. :-)

devxpy 9y ago
That talk is truly awesome. Thanks.
- gjvc 9y ago
  I'm glad you found it useful. Here's a related bonus link :-) https://www.quora.com/Is-there-a-programming-language-thats-effectively-a-successor-to-Smalltalk/answer/Alan-Kay-11 https://www.quora.com/Is-there-a-programming-language-thats-... Dr Kay has been loudly telling us for a long time that we are on the wrong track whilst having already delivered a complete alternative. One can only wonder what his perspective feels like.

abalashov 9y ago

It’s rare that I say someone has truly nailed it, but the author has really nailed it. And while much of the critical response has focused on the difference between design and programming, I can say as someone who has been around the programming block (got started at age 9) that 99% of what he says applies equally well to modern application development and infrastructure.

_pmf_ 9y ago

I'm spending my free time asking on web developer forums how to center something vertically.

kup0 9y ago

This speaks to me strongly, having done this many times: "I’m still not sure I understand it; I type clear: both and say a prayer to the box model."