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

Re: Why Is Front-End Development So Unstable?

#251

Post by idiocratic » Thu, May 31, 2018, 1:19 PM UTC

bonesss wrote: post #206

tracker1 wrote: post #171

Earlier quoted context omitted.

All of this is why, in the end, more and more... I do things "the hard way". If I'm using a dynamic language WTF do I need an ORM for, if I understand enough to write an SQL command, and use a library for that DB that does parameterized queries? On the front end, I tend to lean towards abstractions that work together... I really like React and the material-ui library's switch to JSS. It's relatively clean, and useful…

> I do things "the hard way". If I'm using a dynamic language WTF do I need an ORM for I think it's mostly premature optimization. People think writing DTOs is challenging, so they want an ORM. But since you end up needing DTOs anwyays, removing SQL capabilities from the app means writing SQL in not SQL, and things like joins suddenly become slow and problematic and result in really heavy systems that are harder to c…

If your application mostly reads from the DB then don't use a ORM. I think ORMs shine when you need to save/update a domain model to a relational DB. In the CQRS world, a fairly typical choice when using a relational DB is to use a ORM for the write side and raw SQL for the read side.

Re: Why Is Front-End Development So Unstable?

#252

Post by emodendroket » Thu, May 31, 2018, 1:19 PM UTC

lkrubner wrote: post #210

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

What is curious is that the tech industry has been very conservative about rethinking these 6 things that you just listed. Why rows in a relational database? Why objects? Why Javascript? And why HTML? We'd surely be in a better place if we got rid of these things and rethought our approach from first principles. I've written about these issues many times before. Regarding the problem with objects, I wrote "Object Ori…

I don't know what you're talking about. People keep trying to replace all of those things.

Re: Why Is Front-End Development So Unstable?

#253

Post by christophilus » Thu, May 31, 2018, 1:19 PM UTC

nostrademons wrote: post #157

Karrot_Kream wrote: post #30

Earlier quoted context omitted.

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.

Is this actually a new phenomena? I remember when I started programming c. 2000, the big-name programming gurus were folks like Kent Beck, Ward Cunningham, Uncle Bob, Ron Jeffries, Dave Thomas, Joel Spolsky, Jeff Atwood, Martin Fowler, et al. While some of them mostly knew their stuff, some were outright hacks (Peter Norvig's vs. Ron Jeffries' attempts to create a sudoku solver is one of my favorite examples [1]). Mo…

> I've learned that there's often an inverse correlation between how good a programmer is and how likely you are to have heard of them.

Yep. I second this. The best programmers on my radar are terrible at self-promotion, and are quite content to be terrible at it.

Re: Why Is Front-End Development So Unstable?

#254

Post by unclebucknasty » Thu, May 31, 2018, 1:21 PM UTC

lkrubner wrote: post #228

Cthulhu_ wrote: post #219

Earlier quoted context omitted.

There have been attempts at rethinking it though; noSQL was the buzzword of a couple of years ago, and even nowdays there's mature tools like Firebase that allow you to store and retrieve data much more directly than e.g. SQL. The challenge in nosql storage is of course data migrations and whatnot. But yeah, in theory you can just open up a MongoDB instance to your front-end and not have to bother with SQL or much of…

Angular and React both rely on Javascript and HTML, so you can't describe them as "designed to be great front-end technologies". HTML was designed for document exchange, it is a descendent of SGML. Javascript was initially meant to be a light weight scripting language that allowed dynamic elements in HTML. It's gotten better over the years, but it is still far from what you would expect if you were trying to build a…

I've been saying the same for years. As long as we are working directly with HTML, we will have these impedance problems.

The component/event model a la Swing et. al. is a far more elegant match for modern Web development, which is now essentially the same as building window-based native applications.

OTOH, HTML was designed for static content delivery. Even if a framework must generate some HTML to remain compatible with browsers, there's no reason we have to work or think in HTML as our central interface model.

Give me a canvas, let me lay out (and style) components, then let me respond to events.

Re: Why Is Front-End Development So Unstable?

#255

Post by emodendroket » Thu, May 31, 2018, 1:22 PM UTC

lkrubner wrote: post #228

Cthulhu_ wrote: post #219

Earlier quoted context omitted.

There have been attempts at rethinking it though; noSQL was the buzzword of a couple of years ago, and even nowdays there's mature tools like Firebase that allow you to store and retrieve data much more directly than e.g. SQL. The challenge in nosql storage is of course data migrations and whatnot. But yeah, in theory you can just open up a MongoDB instance to your front-end and not have to bother with SQL or much of…

Angular and React both rely on Javascript and HTML, so you can't describe them as "designed to be great front-end technologies". HTML was designed for document exchange, it is a descendent of SGML. Javascript was initially meant to be a light weight scripting language that allowed dynamic elements in HTML. It's gotten better over the years, but it is still far from what you would expect if you were trying to build a…

> HTML was designed for document exchange, it is a descendent of SGML. Javascript was initially meant to be a light weight scripting language that allowed dynamic elements in HTML

I always see people saying this, but why does it matter? Electricity was originally piped into homes for lighting, but we don't need an alternate way to power all the electric devices in our home. Unix was designed for computers that are quite different from the ones we use today. And so on.

Re: Why Is Front-End Development So Unstable?

#256

Post by christophilus » Thu, May 31, 2018, 1:22 PM UTC

ggregoire wrote: post #131

Sorry but I find font-end development pretty stable. Having to learn a new library every 3-4 years (because of a new job, generally) is it really a big deal? In my career I also had to learn Java, PHP, C#, Node.js, bash, batch, Python… Build apps with Spring, CakePHP, Symfony 1 & 2, ASP.NET MVC 3 & 4… Query database with Hibernate, Entity Framework, Linq SQL… Handle dependencies with Maven, Nugget… Store data in Post…

Did you read the article? Here's a snippet from the beginning:

> Do front end technologies actually change that quickly?

> In the sense of major view technologies, probably not... Consider this list of the highest ‘starred’ JavaScript front-end technologies on Github:

  +------------------------------------------------------------+
  | Library          | Stars   | Released       | Age          |
  |------------------------------------------------------------+
  | React            | 96986   | March 2015     | 3 years      |
  | Vue              | 95727   | October 2015   | 2.5 years    |
  | Angular (1)      | 58531   | October 2010   | 7.5 years    |
  | jQuery           | 49061   | August 2006    | 11 years     |
  | Angular (2+)     | 36665   | December 2015  | 2.5 years    |
  | Backbone         | 27194   | October 2010   | 7.5 years    |
  | Polymer          | 19668   | May 2015       | 3 years      |
  | Ember            | 19003   | December 2011  | 6.5 years    |
  | Aurelia          | 10506   | June 2016      | 2 years      |
  | Knockout         | 8894    | July 2010      | 8 years      |
  +------------------------------------------------------------+

> 2.5 years for the youngest isn’t that old in the scheme of things - it’s less than half the support lifespan of your typical desktop OS, for example - but it’s still a ways off our caricature. So what is causing this perception of rapid, even unsustainable change?

Re: Why Is Front-End Development So Unstable?

#257

Post by emodendroket » Thu, May 31, 2018, 1:23 PM UTC

tlrobinson wrote: post #158

So here’s the thing... browsers are generally excellent at maintaining backwards compatibility (see “SmooshGate” for christsake). Old frontend frameworks still work just fine, therefore when you complain about frontend development be “unstable” you’re complaining about other people creating or adopting new frameworks/tools. If these things really aren’t worth learning you are free to continue using the old ones.

Well, you aren't really, because you have to work with other people who want the latest and greatest.

Re: Why Is Front-End Development So Unstable?

#258

Post by janoc » Thu, May 31, 2018, 1:24 PM UTC

tracker1 wrote: post #184

megaman22 wrote: post #95

Earlier quoted context omitted.

The front-end world is rediscovering lessons learned in the days of desktop thick clients from the 90s, if not earlier. I rage far too often that I have to jump through all these hoops to slam out some UI that I could have done in high school with VB6.

That said, most You can do a simple web app with straight HTML, and a light web server app pretty simply. Not as simply, but simply enough if you wanted to.

Well, then take Qt Designer if you must - automatic layout management to gracefully handle window resize.

The amount of crap you have to go through to make that work properly (and even then it won't work right in all cases) using the common web frameworks is just astounding ...

Re: Why Is Front-End Development So Unstable?

#259

Post by qaq » Thu, May 31, 2018, 1:25 PM UTC

toasterlovin wrote: post #245

bonesss wrote: post #206

Earlier quoted context omitted.

> I do things "the hard way". If I'm using a dynamic language WTF do I need an ORM for I think it's mostly premature optimization. People think writing DTOs is challenging, so they want an ORM. But since you end up needing DTOs anwyays, removing SQL capabilities from the app means writing SQL in not SQL, and things like joins suddenly become slow and problematic and result in really heavy systems that are harder to c…

I’m actually quite fond of SQL, but I disagree that ORMs are not a productivity boost. My experience is in Rails and I think ActiveRecord is a pretty clear win for simple queries. That being said, it is pretty common for less experienced developers to not understand what the ORM is actually doing.

On any project of sufficient size there will be fairly advanced reporting functionality that you generally will not be able to do using ORM so you will end up with a mix of ORM and direct SQL. Also ORM forces you to the lowest common denominator for supported RDBMs I generally do not want to be limited to the SQLite features if I am running PostgreSQL

Re: Why Is Front-End Development So Unstable?

#260

Post by player2121 » Thu, May 31, 2018, 1:26 PM UTC

To me this attributes more towards general evolution of the browsers which naturally leads to more complex requirements for the modern web-app. I remember that in 2010, when we started re-writing our desktop apps during our transition to web, the initial requirements were such that it was still possible (although very hacky) to use the latest version of ASP.NET. Then 6 months later we received a new set of requirements which rendered this _latest_ stack useless. We literally had people sleeping under the desks pulling all-nighters trying to transfer a session state between browser and server without dropping an egg. That's was around time when backbone.js came out.

If we compare the things that browsers can do _now_ with what was possible 5y or 10y ago, no wonder why we have so many new frameworks. Browsers are trying to catch up with (or even replace) an OS as a main container for running an application and because it's hard to release all features _at once_ without agreeing on standards, we have a situation when people have to choose a new library each time a new major API/feature is available. And this what I see is the main reason why `front-end development is so unstable`

WebAsm is coming which will again lead to yet another huge re-write.