Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In web design, everything easy is hard again

frankchimero.com

Post reply on HN
Print view View original

151–160 of 335 posts

Re: In web design, everything easy is hard again

#151

Post by eitland »

jugularkill wrote: post #139
randomsearch wrote: post #9

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

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 top of it.

Re: In web design, everything easy is hard again

#152

Post by adventured »

tonyedgecombe wrote: post #106
root_axis wrote: post #42

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…

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.

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.

Re: In web design, everything easy is hard again

#153

Post by gaius »

adventured wrote: post #134
gaius wrote: post #129

Earlier quoted context omitted.

Necessary how? All the actually useful things you can do on the web you could have done with a 90s browser. I bet Amazon still works in one! Moving apps into browsers is a step backwards for most apps and most users. I was using Jupyter the other day; it’s clunky as hell compared to MathCAD from 20 years ago. We use 1000x the computing power, literally, to deliver 10% of the experience. Keeps a lot of devs employed I…

> All the actually useful things You're pre-emptively trying to define what's useful for everybody else. That's the only way your premise works. In my equally subjective view, XMLHttpRequest radically altered and improved the useful things you can do with the Web. You can't use a 90s browser for Google Maps, Gmail, YouTube, nearly any online productivity software, and dozens of other common activities on the Web toda…

All those things existed before they became web sites, and they aren’t web sites for any particularly good reason today. Email is a good example. GMail is Outlook rewritten in VBA running inside Word.

Let me guess... you’re a JS dev and you think “little upvote arrows” are where the real value is?

Re: In web design, everything easy is hard again

#154

Post by rco8786 »

randomsearch wrote: post #9

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

> There appear to be an excessive number of package managers involved.

Largely agree with your assessment except for this. Which package managers are you referring to? 99% of the js world uses npm, and the other 1% uses yarn. I’m not aware of a single other package manager in the web ecosystem. In fact this is probably one thing where they got it right.

Re: In web design, everything easy is hard again

#155

Post by naasking »

randomsearch wrote: post #9

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

> I’m really not an expert in web dev, but it _feels_ like web dev has been badly engineered.

It is, but it's getting better because so many different approaches have been tried that some of the more scalable and maintainable ones have been worked out. Also, (thank heavens) browser support is a lot more consistent now.

> I need to build a website soon and I’m dreading the front end.

If you're a software developer, I recommend some atomic/functional CSS toolkit, like Tachyons. That will free you from having to do probably 90% of the CSS work you used to have to do, and it matches a more programmer-type mindset to styling elements.

I'm building a site now, and so far it I've just needed to define some style classes for the colours, and the rest of the styling is already included out of the box via their reusable classes.

For the JS side, really depends what sort of dynamism you're looking for. You can go with a tiny JS library for polyfilling and standardizing browser behaviour [1] if you're just doing simple DOM manipulations, or if you expect to be doing a lot of AJAX with dynamic rendering, go with something like Surplus [2], or Vue, React or Mithril if you want something more standard.

[1] https://github.com/naasking/PithyDOM

[2] https://github.com/adamhaile/surplus

Re: In web design, everything easy is hard again

#156

Post by skrebbel »

guitarbill wrote: post #104
skrebbel wrote: post #72

Earlier quoted context omitted.

You can't honestly propose XSLT as a programming language in a thread where half the comments are about how shitty JavaScript is. I mean, JavaScript isn't God's gift to mankind, but XSLT? I have a very hard time coming up with a worse programming language than XSLT, across all dimensions. INTERCAL, maybe? If XSLT had been proposed as a satirical esoteric programming language, people would've laughed and believed it.…

> I have a very hard time coming up with a worse programming language than XSLT What a straw-man argument. He clearly says "[t]he XML/XSLT approach", which is not advocating that XSLT is the best thing ever, but that we ought to consider that the people who developed XSLT had a similar problem to solve, thought hard about it, and came up with that. Many years later, it isn't out of this world that we could come up wi…

> What a straw-man argument. He clearly says "[t]he XML/XSLT approach",

That's a good point. I think I'm so scarred by how much I dislike XSLT that I fail to read comments that are positive about it in good faith. Clearly a mistake on my part, thanks.

Re: In web design, everything easy is hard again

#157

Post by [deleted] »

randomsearch wrote: post #9

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

[deleted]

Re: In web design, everything easy is hard again

#158

Post by naasking »

bitL wrote: post #146
seanmcdirmid wrote: post #143

Earlier quoted context omitted.

Monads existed before their connection to category theory was discovered (by Wadler and company), they just didn’t have an elegant way of describing or naming but. them, and definitely the connection allowed them to push them more. The biggest problem of very functional code on the web is simply debugging it. So much control flow is buried in compositions that there isn’t much to grab on in terms of break points or v…

Exactly. Debugging is one of the biggest problems with FP, and when you hear some prolific Haskell hackers talking about no longer being capable of understanding code they produced 10 years ago at the peak of their mental performance, it's difficult to commit to it exclusively.

> Debugging is one of the biggest problems with FP

I don't see why that's a problem with FP and not just the lack of tooling in most FP languages. Debugging in F# via Visual Studio is a breeze, and OCaml's time travelling debugger looks pretty good.

Re: In web design, everything easy is hard again

#159

Post by saas_co_de »

root_axis wrote: post #42

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 of JS as a flaw and want to recreate the s--tshow they are used to working with because the complexity makes them feel smart and special.

That is just human nature though. The same argument has been going on for decades between C and C++ people. Nothing new here.

Re: In web design, everything easy is hard again

#160

Post by naasking »

fulafel wrote: post #89
randomsearch wrote: post #49

Earlier quoted context omitted.

TypeScript has previously been recommended, so I will take a look. I assume web assembly will bring sanity to the frontend PL world, which will be a step forward.

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?

Post reply on HN