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

Re: Why Is Front-End Development So Unstable?

#351

Post by jhall1468 » Fri, Jun 01, 2018, 1:05 PM UTC

gkya wrote: post #349

jhall1468 wrote: post #329

Earlier quoted context omitted.

No, we don't. The FOSS community operates on the idea that people that want to contribute to it (financially, programming, etc) can do so. Nothing about open source obligates that behavior, outside of certain licenses. Nobody "owes" FOSS anything either, that's up to them.

It is really shocking people can think this way when also making use of hundreds of people's free labour, and when the very existence of most of programming careers are a direct product of OSS innovation. Hopefuly this attitude is not the widespread one.

Those people are volunteering their time. I'm one of them. But that doesn't mean owed something as a result, that's absurd. I made OSS because I wanted to.

Re: Why Is Front-End Development So Unstable?

#352

Post by mmargerum » Fri, Jun 01, 2018, 2:35 PM UTC

no1youknowz wrote: post #72

zitterbewegung wrote: post #9

Earlier quoted context omitted.

I think more developers should use jquery to prototype an app and move torward a framework when it is needed. The same should be said when adopting redux when using react . Also webpack for building and moving beyond SQLite for data .

> I think more developers should use jquery to prototype an app and move torward a framework when it is needed. They really shouldn't. With VueJS it's not that difficult to get setup and running with the CLI and components is such a game changer. Don't get me wrong. I love jQuery, there's nothing better than taking someone else's library and then extending it. Here's an example [0]. However, one thing that I have lea…

You don’t even need to use a CLI tool or webpack. Just pull in vue js and use regular html/js just like jquery.

Re: Why Is Front-End Development So Unstable?

#353

Post by mmargerum » Fri, Jun 01, 2018, 2:37 PM UTC

megaman22 wrote: post #95

aaron-lebo wrote: post #10

Earlier quoted context omitted.

The difference is that the backend model has been around for 20 years if not more. You're locating lots of old-ish and stable libraries because that's when that stuff was made. Maybe you don't remember the days of Zope, Subway, Turbogears, Paste, Pylons, Werkzeug etc just within Python, but that happened. React is a relatively young model for the web. Wait 10 years and it'll look the same. I personally don't feel it'…

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.

It’s a real stretch to compare a reactive library like vue with vb6. Building uis in vue is a pleasure and you almost entirely avoid ui state bugs since you aren’t directly manipulating the ui controls (dom)

Re: Why Is Front-End Development So Unstable?

#354

Post by rhapsodic » Fri, Jun 01, 2018, 2:47 PM UTC

tracker1 wrote: post #334

rhapsodic wrote: post #277

Earlier quoted context omitted.

>Scale that to a VERY large application. I have. Without problems. >In practice, CSS blows up, other portions of the app stop working correctly. Perhaps in your practice, tracker1. But not in mine. That's what everyone seems to be missing here. This is all a bunch of hand waving to me, because I have a lot of experience shipping a lot of robust, maintainable code, and none of it has been true for me. If you need all…

> because I have a lot of experience shipping a lot of robust, maintainable code, and none of it has been true for me Ave you ever had to work on an application that's more than 5 years old, with an active dev team of 30+ (just the web developers) that have had over 200 hands in the pie including contractors then? I have, and it was a nightmare. Frameworks and modern tools help to take care in these situations. The a…

>Ave you ever had to work on an application that's more than 5 years old, with an active dev team of 30+ (just the web developers) that have had over 200 hands in the pie including contractors then? I have, and it was a nightmare.

I was a rank and file developer on a similar shit show years ago. The main difference was that it was a greenfield project at a startup. The people calling the shots were dead set on using the latest fads -- at the time it was the Rational Unified Process, with all the attendant documentation, and EJBs. I knew that Entity Beans were a monumentally stupid idea when I first read the O'Reilly book about them. And I said so, to anyone who would listen, to no avail. I think the team reached 40 developers at its peak, of which maybe half were totally incompetent. (By my standards.) The schedule slipped rapidly, we were put on mandatory 6 day work weeks, I bailed out, easily finding another job, and eventually the whole project cratered.

I'm not going to argue with your experience, tracker1, but all of my experience tells me that the ability of the developers is the best predictor of the outcome of a software development project. And our profession, unfortunately, is awash with incompetent people. For example, people who have worked for over 5 years as a Java developer, who are unable to write a Hello World program in Java from scratch in a plain text editor, and compile it and run it from the command line.

Re: Why Is Front-End Development So Unstable?

#355

Post by detaro » Fri, Jun 01, 2018, 3:04 PM UTC

ryandrake wrote: post #323

detaro wrote: post #301

Earlier quoted context omitted.

And because you don't have time / motivation everyone that has is a self marketer? I agree it's silly to expect every developer to have a blog. I strongly disagree with the only motivation for it being self marketing, or it being a somehow unreasonable question if you have one.

I agree there are talkers and there are do-ers, and very few who are good at both. They do exist but they are rare. This is true for many professions, not just programmers.

Sure. Luckily the blogs written by the two categories are fairly easy to tell apart. Even checking if the domain is medium.com or something else is a good first estimate, but to be sure you should look at the content.

Re: Why Is Front-End Development So Unstable?

#356

Post by diegoperini » Fri, Jun 01, 2018, 3:41 PM UTC

toasterlovin wrote: post #345

ontologiae wrote: post #344

Earlier quoted context omitted.

Using PostgreSql, I tend now to directly generate query result in json. It implies an architecture model where you put the business logic and type safety in the RDBMS. It reduces the number of layers for a lot of functionalities.

How does version control work for an architecture like this?

In my experience, migration scripts that include modifications to output JSON (as ALTER TABLE statements) are always tracked and programmed to be auto-executed on each version update.

Re: Why Is Front-End Development So Unstable?

#357

Post by tracker1 » Fri, Jun 01, 2018, 7:24 PM UTC

mirkules wrote: post #197

tracker1 wrote: post #185

Earlier quoted context omitted.

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…

I take umbrage with your PHP reference... JavaScript the language is pretty damned consistent, and nice. The browser APIs, that's a different story.

As to PhotoShop or GarageBand, I think there's some more flushing out to do as far as APIs, and frankly that kind of stuff might be workable with WebAssembly. It would take a lot of effort to convert everything, also, not sure if you can use WASM in WebWorkers, but that may be more ideal. As to the cost, are you meaning overhead, or programming cost?

I'd guess a not insignificant number of "native" apps for mobile are at least partly framed web apps. Also, I would probably just reach for React Native and re-use as much as possible, which would still leverage JS for most of it.

In the end it depends... you get a LOT from web applications today. I see it as a bigger boost for internal/corporate/enterprise applications. Because you don't have to manage wide infrastructure and updates in nearly the same ways, you can simply do server deploys and be done.

Also the 1996 apps reference was in that most UI toolkits default to looks that haven't changed much since 1990's and aren't skinnable in the least. I remember the late 90's and early 2000's, litestep and winamp were two of my favorite things. I know that was user customizations of apps, over developer/designer. All the same, maybe I want my site/app to look like Material Design over Bootstrap, or something else.

Re: Why Is Front-End Development So Unstable?

#358

Post by tracker1 » Fri, Jun 01, 2018, 7:38 PM UTC

janoc wrote: post #258

tracker1 wrote: post #184

Earlier quoted context omitted.

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

I'm referring to CSS media queries in HTML/CSS, which don't have a nearly as clean equivalent for applications. Even then, I've done better with React. If I had to build native apps today, I'd look for a React Native adapter for whatever platform or reach for electron first.

Re: Why Is Front-End Development So Unstable?

#359

Post by pas » Fri, Jun 01, 2018, 7:41 PM UTC

fauigerzigerk wrote: post #280

pas wrote: post #193

Earlier quoted context omitted.

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

>You can get the same bits in your JS objects as you have in the DB. If not, that means your system is shit. I'm not sure what exactly you mean by that. But one thing is absolutely clear. You cannot automatically derive a logical layer from the layer above or below. If you could, there would be no reason to have seperate (logical) layers in the first place. That's why you get an "impedance mismatch" that has to be br…

Maybe I misunderstood the original comment, but the claim was that frameworks are leaky (this I wholeheartedly agree with, and this of course leads to impedance mismatches, after all, pixels on the screen are very different from an SQL DB, but that's why we have the libraries and frameworks, to help us do this translation from one layer to the other, to glue together very different functional components of systems). But then follows it up with talk about data. How JSON and SQL is not a great match. Which is nonsense. You can losslessly represent the same data in both JSON and SQL, you can engineer a perfect system for handling data (you use the same field and column types, lengths, constraints, validation, and so on on both the front- and the backend, and it works), the mismatch is not around data.

The problems are about development trade offs (TypeScript vs JS, small library - few features, complexity - code modularization + chunked lazy loading, optimization - script load time vs development time, and throw in cross browser compatibility; supported features vs complexity - HTTP/2 is nice, and fast, but it's more complex plus you need HTTP1.1 too for old clients, and maybe your API somewhere doesn't support prefetch, or you can't hint your backend to push that to the client, or you can't access the raw request after the framework extracted the request attributes, blablabla), visual communication (current/modern components vs old jQuery sprinkled DOM result in different sites; mobile first, mobile browsers, React Native and Ionic). And these trade offs are different over time. So we get different frameworks over time. And since the change in browsing is very fast, and the effort to start a new framework is small, we get a lot of new unstable frameworks. (And since those frameworks rarely mature really, we get a lot of new ones, because there's not really a "sunk cost" for developers when abandoning the old ones. And it's easy and hip to pick up new skills, and try them out on a new project, etc.)

Also, you can put the "business logic" into one place, and represent it and then push that representation to the client. (GWT, Scala.js, or crude autogenerated forms, point and click website/workflow builders, and so on). Of course, if you want to change the system, then it might be a big pain in the ass to represent something very different than what it was designed for, so these kinds of entombed vertical complexity barriers lead to a metastable state - when you hack something quick on the layer most accessible for you with respect to the task, instead of properly implement it in the whole vertical stack, and these hacks grow and the elegant single source representation of business logic goes out of the window. (Or if you implement everything in one place, you are destined to implement a very powerful - or verbose - DSL to describe the "front end logic" - which should be CSS, and the DB optimization logic - which should be SQL, and so on.)

Re: Why Is Front-End Development So Unstable?

#360

Post by tracker1 » Fri, Jun 01, 2018, 7:46 PM UTC

rhapsodic wrote: post #354

tracker1 wrote: post #334

Earlier quoted context omitted.

> because I have a lot of experience shipping a lot of robust, maintainable code, and none of it has been true for me Ave you ever had to work on an application that's more than 5 years old, with an active dev team of 30+ (just the web developers) that have had over 200 hands in the pie including contractors then? I have, and it was a nightmare. Frameworks and modern tools help to take care in these situations. The a…

>Ave you ever had to work on an application that's more than 5 years old, with an active dev team of 30+ (just the web developers) that have had over 200 hands in the pie including contractors then? I have, and it was a nightmare. I was a rank and file developer on a similar shit show years ago. The main difference was that it was a greenfield project at a startup. The people calling the shots were dead set on using…

I came into my example above 5 years in... it was "Enterprise" .Net and not Java, but a lot of the same techniques at play... I hated it all. I'll take today's JS/NPM ecosystem over those days. I rally against ORM, and DI/IOC frameworks to the end, they aren't needed in JS.

That said, I'm not saying no frameworks/libraries/tools, and am okay minimizing. But I'd rather use Vue, React, Redux and other libraries/patterns than not in most cases, and find them better overall than ad-hoc jQuery. And don't get me wrong, I've written a lot of ad-hoc and organized code without modern tooling. I'll take today's module systems, builders and bundlers.

As to Java hello world, frankly every time I've had to touch a Java project, it takes 2-3 days to get a build environment running on a local dev machine... it's nightmarish. I've never even taken to learning Java from scratch my exposure has been so bad. I did learn C# from the command line compiler and a book early on, I didn't have VS to hold my hand. I later did learn VS etc, and that was nicer still.

Getting the pieces together with node/js has been difficult, and painful and a slow process even keeping up with node since it was first announced in 2009. It's taken effort. But anything more than a quick demo, I'd rather have it. I'll leave TypeScript/flow and similar alone though, I don't think they bring more than they take most of the time.