Why Is Front-End Development So Unstable? • Hacker News Board

Re: Why Is Front-End Development So Unstable?

#191

Post by ehnto » Thu, May 31, 2018, 8:43 AM UTC

aaronbrethorst wrote: post #182

Chyzwar wrote: post #166

Earlier quoted context omitted.

That's good, in each cycle, sooner or later you get improvement: webpack over grunt, react over jQuery and npm over vendoring your jQuery plugins. OP forgot how life looked when your web app project was handcrafted HTML page with manually inserted scripts tags. When your form submission was multi-level backend API in PHP. jQuery plugins with 20+ options published randomly on the internet.

I feel like this is a false dichotomy. The choice doesn't have to be roasting squirrels over an open flame/handcrafting PHP pages vs. shiny futurism/Node+React. I have been getting along just fine with Rails, HTML, and a sprinkling of JS for over 10 years.

There is an immense productivity gain to be found in mastering a set of tools. After a while of dogmatic tooling changes you begin to analyze more critically whether the new shiny thing is going to provide any real value. I would argue that for the huge majority of websites, tried and tested tooling is perfectly fine and definitely more robust and supported.

Every tool you introduce is hours of troubleshooting just waiting to happen.

Re: Why Is Front-End Development So Unstable?

#192

Post by rusk » Thu, May 31, 2018, 8:51 AM UTC

I think the quality standard is different.

Front end has to "look good" and be "good enough to use". Little finnicky errors are often tolerated as a user can be expected to work around a certain issues. Since issues can be quickly spotted code hygiene and rigorous software quality practices aren't as important. Also, performance and resource utilisation aren't as important, to a degree anyway.

Back-end, unsupervised, or high-performance code on the other hand is largely invisible to the end user. It has to run for long times without error and if something goes wrong can be tricky to get at, diagnose, and repair.

These requirements demand a higher level of code-hygene. Coding standards, logging, documentation, automated testing etc. etc. which makes developing this kind of code much more expensive than you would expect for something that you ultimately "can't see" (unless something goes wrong).

I've seen organisations struggle with this dichotomy where they're trying to do both without appreciating these distinctions. Product managers getting annoyed that it takes so long to get GUI changes in, while engineers getting annoyed that their (necessary) tech process overhead often gets shorted because "it doesn't add value".

You can get away with taking short-cuts on the front-end, that you can't get away with elsewhere but ultimately this leads to a messy, unwieldy codebase with mountains of tech-debt and once you get to a certain point it makes sense to just throw it out and start it again.

Though "starting again" is considered to be something you should never do [0] with front-end stuff it's a little easier to get away with because, like I say it's all visual, and a good bit easier to test and play with and tease out the subtleties.

[0] https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Re: Why Is Front-End Development So Unstable?

#193

Post by pas » Thu, May 31, 2018, 8:56 AM UTC

adrianratnapala wrote: post #151

bjterry wrote: post #133

Earlier quoted context omitted.

This is a great comment and an amazing insight. What's particularly interesting is that people have attempted to collapse (almost?) every stage of that abstraction hierarchy individually, but none of them have been so successful as to take over the world. If you were writing a desktop application, you would still have at least three of the layers (serialized data on disk, in-memory data, and the rendering of the obje…

Even on the desktop those three layers involve impedance mismatch and much the same pathologies as meredydd describes. But I guess three layers of it are better than 6.

It's data. There's a fix format for serializing it. In a lossless way. I don't know what meredydd talks about, there's no mismatch with regards to data.

You can get the same bits in your JS objects as you have in the DB. If not, that means your system is shit.

The problem with frameworks is not the hardship of funneling data up and down the stack.

The problem is that they are optimizing for different things. React optimizes for simplicity of making components. Angular optimizes for providing a full toolkit. And new versions then focus on different things. Server Side Rendering was hot, but now that Google just executes some JS and penalizes large downloads, it's the quest for less bytes on the wire. And tree-shake-ability. And faster time to first paint.

And as browsers and the web changes, so do frameworks. And frameworks try to target, at the same time, both the future, and the very present problems, they try to provide instant gratification, yet try to optimize for the future.

So they usually look half-assed useless pieces of autogenerated-by-MS-Word code all the time. But they work, nevertheless, and power a lot of sites.

Re: Why Is Front-End Development So Unstable?

#194

Post by [deleted] » Thu, May 31, 2018, 9:01 AM UTC

sanderjd wrote: post #111

davidjnelson wrote: post #101

Earlier quoted context omitted.

That really is an amazing book :-)

Man, I couldn't get through it! It seemed like its own kind of hype-y proselytizing and I didn't find its examples spoke to the kind of issues I actually have. Maybe I didn't give it enough of a chance, but I don't know, I had been hearing for years that it's so great and I was really excited to start reading it, and it just didn't speak to me at all. Anyway, YMMV I guess!

[deleted]

Re: Why Is Front-End Development So Unstable?

#195

Post by kuon » Thu, May 31, 2018, 9:05 AM UTC

freedomben wrote: post #15

kuon wrote: post #4

I work with elm now for frontend. It has often been criticized for being too conservative and slow paced in its development. But the result is that code is easier to maintain, libraries have a great quality and most of the time there is only one, obvious, way of doing something.

Somewhat unrelated, but a couple of questions for you: 1. How did you learn elm? 2. Was elm your first functional language? (Not wanting the "javascript is a functional language" battle here plz) 3. What is your backend written in? Do you maintain that? 4. What libraries do you make use of? 5. Any regrets?

1. By chance, after a long and tiring typescript project, I looked for something else.

2. No, my first functional language was clojure script, which I tried before elm, I liked the concept but just couldn't bare the syntax.

3. Phoenix elixir, I do maintain it. (in fact I'm more of a backend programmer)

4. Now I work mostly with style-element (the alpha, called stylish elephant) which is the only "framework like" library I use. Otherwise I use different utility libraries for date, color manipulation (hsluv which I wrote the elm implementation), data structure manipulation (many in elm-community, like list.extra)... I use way less libraries that I would with JS, and that's good.

5. No.

Re: Why Is Front-End Development So Unstable?

#196

Post by mseebach » Thu, May 31, 2018, 9:07 AM UTC

sanderjd wrote: post #111

davidjnelson wrote: post #101

Earlier quoted context omitted.

That really is an amazing book :-)

Man, I couldn't get through it! It seemed like its own kind of hype-y proselytizing and I didn't find its examples spoke to the kind of issues I actually have. Maybe I didn't give it enough of a chance, but I don't know, I had been hearing for years that it's so great and I was really excited to start reading it, and it just didn't speak to me at all. Anyway, YMMV I guess!

It's not a religious text or anything (I suspect that the proselytising tone comes from the fact that at the time it was written, it's recommendations were still a bit controversial, especially in the kind of organisations likely to have these kinds of codebases). If it's not useful to you, then that's that. The point is, other books written ten years ago by people with deep expertise (rather than a hypey blog post by someone who just discovered some principle five minutes ago) probably will be.

Re: Why Is Front-End Development So Unstable?

#197

Post by mirkules » Thu, May 31, 2018, 9:09 AM UTC

tracker1 wrote: post #185

mirkules wrote: post #146

Earlier quoted context omitted.

To expand on your point, somewhere along the line, the web went from a content delivery mechanism to a full GUI + content delivery mehanism. The allure and advantages to developing a full GUI on the web are many, including portability and availability. But the downside is that you are suddenly developing to the lowest common denominator - the browser - which not only has to support the "old" web but complicated GUIs…

There are drag/drop APIs defined... but people make abstractions... This happens even in desktop UI development. There are LOTS of front-end libraries.. but it takes a lot of effort to make them, so there are still far fewer. The web is easily flexible, and configurable in terms of how you deliver your UX... you aren't hamstrung into creating something that looks like it was made in 1996.

Delivery and flexibility are the greatest pros. But while the delivery mechanism is great, the UI has to be delivered and interpreted every time, through an unknown engine that theoretically follows a spec. This results in a) slower execution times and b) inconsistencies in how the UI is interpreted. Javascript browser applications are simply slower and less stable for than their native counterparts for those reasons.

All that on top of a language which is on par with PHP as far as consistency, and often times worse.

With regards to your 1996 comment, again I beg to differ. Try writing Photoshop or GarageBand as a web app. I shudder to think what that would look like, and the cost each would incur.

There is a reason that "mobile web apps" have lost the battle to native, essentially - the friction to deliver an app is much smaller (app stores), every platform is more-less consistent and the apps are smoother and faster instead of choppy and half-baked for web apps. I would much rather, for example, use a Home Depot app than their website. Or Coinbase vs. GDAX (even though GDAX is more feature-rich). I can't even think of a webapp that I'd rather use (on a regular basis) if an app is available instead.

But maybe I'm just a graybeard who can't accept change. Or maybe I'm simply old enough to remember what 1996 was like for UI, and that the web today feels like those times, just with prettier icons. Likely a combination of both.

Re: Why Is Front-End Development So Unstable?

#198

Post by accnumnplus1 » Thu, May 31, 2018, 9:12 AM UTC

Karrot_Kream wrote: post #30

freedomben wrote: post #8

This is a really well-written and well-thought out piece. The author touches on a number of points but never gets polemical. This piece resonated with me particularly well: > Be wary of self-promotion > Over the last few years I’ve seen much more aggressive self-marketing in the JavaScript world, possibly due to the rise of paid online training materials and the employment/consulting advantage of being a Github ‘cele…

I'm finding the growing celebrity culture of programming to be troubling. I find that programming is becoming less and less about code or architecture and more about evangelism and marketing, but I'm not sure what changed in the incentive structure for this to happen, and I would like to find out. Aside: This has made me reconsider being a career programmer.

It's gone mainstream, and just like the internet going mainstream, it isn't what it used to be. These days I only enjoy the programming I do on the weekend.

Re: Why Is Front-End Development So Unstable?

#199

Post by colinmegill » Thu, May 31, 2018, 9:20 AM UTC

Chyzwar wrote: post #166

meredydd wrote: post #56

Web frameworks are churn-y because they are incredibly leaky abstractions covering really awkward impedance mismatches. This means that they are never quite satisfactory - and that just to use one, you need to be capable of building a new one yourself. Think of a typical web app. Your data exists: 1. As rows in a database, accessed via SQL 2. As model objects on the server, accessed via method calls and attributes 3.…

That's good, in each cycle, sooner or later you get improvement: webpack over grunt, react over jQuery and npm over vendoring your jQuery plugins. OP forgot how life looked when your web app project was handcrafted HTML page with manually inserted scripts tags. When your form submission was multi-level backend API in PHP. jQuery plugins with 20+ options published randomly on the internet.

Strongly agree. What was a larger team is now a part time project. That's a goal and outcome of the churn.

Re: Why Is Front-End Development So Unstable?

#200

Post by wiennat » Thu, May 31, 2018, 9:26 AM UTC

freetonik wrote: post #160

_bxg1 wrote: post #82

At some point, when modules get "micro" enough, the effort of managing them and learning their usage outweighs the effort of implementing the thing yourself. Most JavaScript projects seem to walk that line quite closely. I'm a React developer at work, but I recently gave Vue a try at home. This is one of the things that most stood out to me about it. React makes a selling point out of the fact that it's "just renderi…

If I remember correctly, first versions of React were similar in that respect: you could just add a script tag to your page and you that’s it (save for the mount-point thing).

You still can do the same with the current version.