Live data from Hacker News

In web design, everything easy is hard again

frankchimero.com

291–300 of 335 posts

Re: In web design, everything easy is hard again

#291

>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 coffeescr…

> Sure, they're beautiful and interesting from an intellectual standpoint

constructing an application which consists of updating a table and persisting it in a database for business tomorrow should not be a high art.

Most enterprise / business applications are not much more than glorified form fill-in, and the simple ones don't really deserve the multiple layers of abstraction. If you don't believe me, recall the relief of being able to "just edit the damn data" in the django admin tool when the regular application is misbehaving.

Re: In web design, everything easy is hard again

#292

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 exi…

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

So true.

Re: In web design, everything easy is hard again

#293
post #89

Earlier quoted context omitted.

WebAssembly is not an attractive compile target for general web apps in the foreseeable future, it's going to remain a C/Rust thing unless it changes dramatically. JS is a vastly more attractive compile target for managed, GC'd languages.

> WebAssembly is not an attractive compile target for general web apps in the foreseeable future, it's going to remain a C/Rust thing unless it changes dramatically. How come?

It's too simple to support dynamic language features AFAIK.

Re: In web design, everything easy is hard again

#294

Earlier quoted context omitted.

You said it. You're not an expert. You are comparing a prototype based language to oop languages. You're basically putting the wrong fuel in a car and blaming the car. You are lazy in my opinion because yes there are few resources that teach you how to use the language properly but plenty that compensate for those who want to make it familiar to back end devs. If you looked for good resources you will slowly discover…

While it is certainly possible to understand JS it is - IMO - a waste of brain cycles that we have to live with. There's no doubth in me that even very good Javascript programmers can be significantly better in a better language. E.g. Typescript gives you literally all of JS - and a way to keep things tidy. Typescript which is a compile-to-js language in a weird way proves how lacking js is - while still buildiing on…

I programmed in more than 10 languages and I'm very productive with TypeScript and I doubt there's better language for interface development or I would be using it instead.

What exactly do you propose? I will test it out.

Re: In web design, everything easy is hard again

#295

Earlier quoted context omitted.

>I keep hearing coworkers trash a particular open source project/framework with no understanding of what kind of problems it solves. Also I often think: I keep hearing coworkers adopt particular open source project/framework with no understanding of what kind of problems it solves.

For me it's "premature optimization is the root of all evil". Very often teams will use ages getting up on new frameworks to avoid a little hard programming, only to end up with hard programming wrapped in a huge framework they don't really grok and lots of incidental complexity. Wordpress or whatever will make an email widget easy to source, but if that's only 1% of your project, why impact the other 99% without con…

I agree, but the opposite also happens: teams start by implementing something small themselves because the framework is so 'huge'. Over time, they end up with a semi-huge custom framework because they run into the same issues and feature requests the 'huge' open-source framework ran a few years before them.

Re: In web design, everything easy is hard again

#296

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 confu…

> blah blah blah The real problem here is that all these comp sci "geniuses" want to make a name for themselves with a "real" project and so they create all these garbage tools (compilers, pre-processors, etc) that make things worse by introducing and encouraging more complexity when just using plain JS would work better. A lot of them are Java/C++ people with no experience in web development who see the simplicity o…

As many people here already said, just stick with your simple JS. No need to complain about anything because plain JS still works exactly as it always did.

Re: In web design, everything easy is hard again

#297
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.

Re: In web design, everything easy is hard again

#298

Earlier quoted context omitted.

Okay. So far I haven't had to use the span thingys. For mobile, I'm just assuming that the users smartphone has a Web browser. For fitting on the smartphone screen, each page is just 800 pixels wide, and smartphone screens are that wide? But even if not, my pages are still usable with only 300 pixels wide. My most complicated page sends for just 400,000 bits which seems small enough. There are just two files, HTML an…

The same font size on an 800 pixel wide smartphone as on an 800 pixel wide desktop screen will not be readable at all. Go watch the original iPhone unveiling - https://thenextweb.com/apple/2015/09/09/genius-annotated-wit... - at 01:00:00 or so he shows the New York Times website front page. It's in three columns, like on desktop, meaning you can read nothing until double-tapping to zoom in. 10 years ago, because nobo…

Okay. Thanks.

Actually I have been guessing that smartphone users would somehow magnify my Web pages by a factor of two (2X) or three (3X). Using the horizontal scroll bar, they can get by with just the left 300 pixels. So, with 2X, they would be using 600 pixels on their screen; 3X, 900 pixels. Doing a Google search on smartphone screen pixels, the 900 seems fairly common.

I don't really see a way to present the information to users with fewer than 300 pixels horizontally. My Web pages are so simple I don't see any way to make them still more simple for smartphone screens.

The situation on tables versus DIV, JavaScript, etc. for me versus others appears to be: (1) I'm only developing one Web site and where the screen content is under my control from my design of my user interface (UI) and is especially simple. So, for my Web site, with just two main Web pages, I can do well with tables. (2) If I were Web site front end developer for many different Web sites, responsible only for the Web pages and not for the content, the site overall, or the business paying for the site, then too soon I'd find that tables were too limiting. So, instead, I'd use JavaScript to look up screen sizes, window sizes, pixels, the physical width of the screen in inches (millimeters, points, etc.) and then use DIV elements, more JavaScript, etc. to try to redesign the page for the screen of each user individually.

Net, from (1) and (2) what works for me for my just two Web pages for just my startup is not flexible or powerful enough for Web pages in general. Okay.

For the Apple announcement video, apparently that is blocked in the US on copyright grounds by NBC.

I didn't realize that Web page designers were going to so much trouble to accommodate tiny smartphone screens.

Really, for my Web site, getting a good user experience (UX) for smartphone users will be a strain unless, say, smartphone users are wearing special glasses or are very near sighted!

Thanks for the tutorial.

Re: In web design, everything easy is hard again

#299
post #288
post #273

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 There is a quote from the talk which rings true with many of the c…

That talk is truly awesome. Thanks.

I'm glad you found it useful. Here's a related bonus link :-)

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.

Re: In web design, everything easy is hard again

#300
post #254
post #117

Earlier quoted context omitted.

Elm is the opposite. From this article: https://medium.com/@eeue56/why-type-classes-arent-important-... "Right now, any Elm developer can examine Elm code that another developer has written, and fully understand what is going on. I consider this a major thing that Elm has got right." And "Elm is targeted at the main source of users it has — Javascript developers. Javascript developers may be familiar with typeclasses…

Thanks! Do you know any good (Udemy?) course in Elm that won't take too much time and gets into important parts quickly and thoroughly?

maybe this? https://pragmaticstudio.com/courses/elm
Post reply on HN