3 ms·

> But why should it be? The goal of building web sites and apps isn't to use the latest shiny new technologies. I agree that it shouldn't be, but I don't agree

> But why should it be? The goal of building web sites and apps isn't to use the latest shiny new technologies. I agree that it shouldn't be, but I don't agree that it's possible for it not to be, mainly because browsers are constantly changing and improving and assumptions older frameworks had become irrelevant over a long enough time period (certainly over 5 years). This is precisely the reason why Angular is having to make such drastic re-write - they're trying to align better with Web Components and other ECMA6 features that are coming down the pipeline. I hate to stereotype but often people who complain about the volatility of web development tools and frameworks are people who are traditionally server-side developers who have enjoyed a relatively stable deploy target for periods much longer than 5 years. Trust me, I wish it was the same for front-end development. > And if we're talking about app-style development, why should someone who invests significant time and resources to build, say, an intranet app to automate some function in their business not expect that app to still work five years from now? Because building desktop style applications using old web technologies is really freaking hard. If it wasn't, we there wouldn't be such a huge deluge of web frameworks to help do it. > This is why standards and stability are important, and it's why "living standards" are a pile of [expletive deleted], and it's why it's a bad thing that some browsers currently have very rapid release cycles with an obvious emphasis on adding new shiny things at the expense of maintaining support for older technologies, and it's why you shouldn't build anything you might need to maintain for more than a year or two with the JS framework du jour. I can't really disagree with you here and that's why I find React so compelling because they're kind of saying "fuck you" to the standards committees and building something they know works whether or not the promises of ECMA6 and HTML5 come to fruition. > A lot of front-end devs today make building simple user interfaces to access databases seem awfully complicated. Every time I read articles like this one I become more convinced that most of that complexity is of their own making. They talk down to old school developers who put most of the logic on the back end, or who build interactions using jQuery, but sites written 5 years ago using those technologies still work and can still be maintained just fine. I wouldn't bet on that being true for anything built with a framework like Angular or React today. I'm guessing you're not a front-end developer so forgive me if I'm wrong, but what you're saying is absurd. It is hard. Much harder, in fact, than building an iOS or Android App which rely on sane frameworks built by single entities to function perfectly within one sandboxed environment. Web applications like Google Docs are every bit as sophisticated as native mobile apps but must be built without the benefit of native performance and monolithic, corporate-sponsored SDKs. Putting "most of the logic on the backend" isn't a viable solution for native mobile apps, why would it be a viable solution for desktop-style web apps? Just step back for a moment and compare the functionality you get from a framework like Angular or Ember to the functionality you get with the iOS or Android SDK and you will see they are all solving generally the same problem in the same way. The only difference is that there are far more choices of frameworks on the Web (which is both a curse and a blessing).

Silhouette 12y ago
I'm guessing you're not a front-end developer so forgive me if I'm wrong, but what you're saying is absurd. It is hard. I suspect that we'll have to agree to disagree on that. I'd say building a real-time control system for an aircraft is hard. Writing safety-critical firmware for a medical device that must have literally no serious bugs because if you miss one then people could actually die is hard. Accurately modelling global weather patterns is hard. Building a database that can support Google or Facebook or global financial systems is hard. Writing networking algorithms that can manipulate hundreds of gigabits per second of network traffic on today's commodity hardware is hard. Performing voice recognition and natural language processing to allow a computer to respond to verbal commands in everyday language is hard. In contrast, writing a relatively small, primarily text/form-based UI as a front-end to simple database is not hard, whether as a desktop app, or a mobile app, or a web app. It just isn't. There are no out-of-the-ordinary performance requirements. No-one is going to die or lose a million dollars per hour if it has a bug. There's no fundamental problem to solve that requires the development of new algorithms. It's like 2/10 on the scale of hard software problems. It's interesting that you started your post by talking about assumptions underlying frameworks changing and you kept coming back to the 5 year time scale. As I see it, the fundamentals of HTML, CSS and JS haven't really changed very much in two decades. Likewise, the patterns we see in modern web and mobile UIs -- things like data binding, and MV*, and bundling updates together so you only do one expensive re-render -- have been widely used in desktop software for decades as well. So I'm wondering what fundamental assumptions could have changed so much in just a few years that a JS framework would no longer be useful so quickly, and I'm thinking maybe they were bad assumptions in the first place. Of course a few of the details have evolved over time. And of course it's nice that there are now JS libraries to support some of those patterns as a ready-made tool so we don't have to set them up ourselves. Still, we've been using the same ideas, even in front-end web development, since long before Angular or React was on the scene. Implementing those patterns in JS using general programming principles isn't difficult, nor is it particularly time-consuming, given that you probably build these kinds of tools once per project and we're talking about projects large and important enough to have a multi-year lifespan. Much of the JS community for the past few years has just been kind of flailing around learning the same old lessons all over again, with varying degrees of success. So I'm puzzled by this recurring idea in discussions about JS frameworks that all we could do before we had the likes of Angular and React was store data in the DOM and use arbitrarily large amounts of trivial jQuery. That is not a world I recognise. No doubt quite a few sites/apps did work like that; there are plenty of low-skilled people who write software, after all. But plenty of other sites/apps were built by real software developers who used real software design skills, just like any other programming project. Right now, I'm working professionally on multiple web front-ends that predate most or all of these JS frameworks, yet have been doing their job and adapting to changing requirements successfully for longer than anything written in those frameworks has been around. They each have their own considered software design, and they still use techniques like publish-subscribe, bundled rendering updates, separate models, and so on. So as I said at the beginning, I'm afraid we'll just have to agree to disagree. I can't accept the premise that building a typical UI that is mostly text/forms and talks to a database is difficult to do without a framework. Countless programmers have been doing it on numerous different platforms for decades. It's just that a significant part of the JS community only just noticed and started borrowing the same ideas.

Silhouette 12y ago

I'm guessing you're not a front-end developer so forgive me if I'm wrong, but what you're saying is absurd. It is hard. I suspect that we'll have to agree to disagree on that. I'd say building a real-time control system for an aircraft is hard. Writing safety-critical firmware for a medical device that must have literally no serious bugs because if you miss one then people could actually die is hard. Accurately modelling global weather patterns is hard. Building a database that can support Google or Facebook or global financial systems is hard. Writing networking algorithms that can manipulate hundreds of gigabits per second of network traffic on today's commodity hardware is hard. Performing voice recognition and natural language processing to allow a computer to respond to verbal commands in everyday language is hard. In contrast, writing a relatively small, primarily text/form-based UI as a front-end to simple database is not hard, whether as a desktop app, or a mobile app, or a web app. It just isn't. There are no out-of-the-ordinary performance requirements. No-one is going to die or lose a million dollars per hour if it has a bug. There's no fundamental problem to solve that requires the development of new algorithms. It's like 2/10 on the scale of hard software problems. It's interesting that you started your post by talking about assumptions underlying frameworks changing and you kept coming back to the 5 year time scale. As I see it, the fundamentals of HTML, CSS and JS haven't really changed very much in two decades. Likewise, the patterns we see in modern web and mobile UIs -- things like data binding, and MV*, and bundling updates together so you only do one expensive re-render -- have been widely used in desktop software for decades as well. So I'm wondering what fundamental assumptions could have changed so much in just a few years that a JS framework would no longer be useful so quickly, and I'm thinking maybe they were bad assumptions in the first place. Of course a few of the details have evolved over time. And of course it's nice that there are now JS libraries to support some of those patterns as a ready-made tool so we don't have to set them up ourselves. Still, we've been using the same ideas, even in front-end web development, since long before Angular or React was on the scene. Implementing those patterns in JS using general programming principles isn't difficult, nor is it particularly time-consuming, given that you probably build these kinds of tools once per project and we're talking about projects large and important enough to have a multi-year lifespan. Much of the JS community for the past few years has just been kind of flailing around learning the same old lessons all over again, with varying degrees of success. So I'm puzzled by this recurring idea in discussions about JS frameworks that all we could do before we had the likes of Angular and React was store data in the DOM and use arbitrarily large amounts of trivial jQuery. That is not a world I recognise. No doubt quite a few sites/apps did work like that; there are plenty of low-skilled people who write software, after all. But plenty of other sites/apps were built by real software developers who used real software design skills, just like any other programming project. Right now, I'm working professionally on multiple web front-ends that predate most or all of these JS frameworks, yet have been doing their job and adapting to changing requirements successfully for longer than anything written in those frameworks has been around. They each have their own considered software design, and they still use techniques like publish-subscribe, bundled rendering updates, separate models, and so on. So as I said at the beginning, I'm afraid we'll just have to agree to disagree. I can't accept the premise that building a typical UI that is mostly text/forms and talks to a database is difficult to do without a framework. Countless programmers have been doing it on numerous different platforms for decades. It's just that a significant part of the JS community only just noticed and started borrowing the same ideas.