13 ms·

As a hobbyist web dev using Rails, I am watching the JavaScript ecosystem from some distance - the mere JS experience I have is very vanilla or through Stimulus

• Tade0 3y ago
  Svelte itself might not survive, but the idea of adding reactivity at compile time will remain, because it's just too attractive to abandon it. For one, in Svelte you're getting a legible stack trace - something that JS frameworks stopped delivering over a decade ago. To finally know which change triggered the rendering that errored out just by looking at the stack trace is a game changer.
  • dorianmariefr 3y ago
    Stack trace from React is pretty clear
    • deleted 3y ago
      [deleted]
• iamsaitam 3y ago
  I'd say React (NextJS for fullstack) is that framework, it's already 10 years old.
  • continuational 3y ago
    React Hooks might as well be another framework than React Components, even if it's backwards compatible. If anything, it's proven unstable. My advice is - if you want something that will be stable for 15 years, look for something that has already been stable for 15 years.
    • fullstackchris 3y ago
      > proven unstable care to share a link, blog post, or study? i've built at this point dozens of apps on react, no "instabilities" to call home about
      • continuational 3y ago
        I believe you're thinking unstable as in "it breaks all the time". That's not it; it's that anything written before React Hooks were introduced is now squarely in the category of legacy code (https://react.dev/reference/react/legacy https://react.dev/reference/react/legacy).
• PufPufPuf 3y ago
  Lindy effect (https://en.m.wikipedia.org/wiki/Lindy_effect https://en.m.wikipedia.org/wiki/Lindy_effect) says that the best predictor for software longevity is how long has it been relevant already. So, React seems like what you want. It's considered "old" technology by the hype people, but I don't think you care since you said you're using Rails.
• kamikaz1k 3y ago
  Comparing to Rails/Ruby is not really fair because Ruby’s popularity exploded due to Rails, especially in web context. As such both the primitive and the framework are closely tied (in web dev context). Whereas JavaScript is a primitive, and frameworks have gone and come based on the needs of the time. Depending on your web stack, you probably have a very different view of JavaScript. And actually I’d rather view it as that; JavaScript in the context of a web stack is just an extension of the serving framework. If you say the backend is just a simple REST API, then you fall into the SSR or not camp. If you’re not in SSR, I guess it doesn’t matter. But these days, things aren’t trending towards SSR. So your question actually boils down to, which set of JavaScript libraries will be maintained for a given stack. So the answer is: the most popular JS framework for any established full stack web framework. If not SSR though, I’d say react. Because it’s cheap and ubiquitous.
• meiraleal 3y ago
  I'm using Lit for the past 2 months after Svelte/SvelteKit for another 2 and although I liked sveltekit a lot coming from React, Lit tooling or lack of it is the greatest advantage in comparison. Lit is a great tool to create your own framework while keeping it integrated with other lit-based frameworks and any other framework as it is based on custom Elements so it is an excellent way to write components that can be used together with React, vue, svelte. Another great advantage is that Lit already have top class UI libraries like shoelace, ui5, Lion and many more.
• CharlesW 3y ago
  > For those who know better, what is your current bet for a JavaScript (or TypeScript for that matter) framework that will last the next 15 years? Is Svelte on the list?* I don't know "better", but FWIW I just went through this same exercise and landed on TypeScript and Vue, with Vite as my build system. Vue is 9 years old (vs. React's 10), and I'm reasonably sure that I'm not going to need to learn a new front-end framework before 2040 unless I want to. I think the jury's still out on whether Svelte will be around that long, although I'm rooting for it. IMHO, the key will be the ecosystem that grows (or doesn't) around it.
  • bufferoverflow 3y ago
    TS + Vue + Vite is just so good. I switched to it from React + Webpack, and it's so much better.
  • thunky 3y ago
    > I'm reasonably sure that I'm not going to need to learn a new front-end framework before 2040 unless I want to Maybe not, but there is a good chance that Vue in 2040 is nothing like Vue today.
    • 9dev 3y ago
      Cars 20 years ago weren’t what they are today. Browsers weren’t, politics weren’t, heck, light bulbs weren’t. Things change all the time. It’s okay.
      • thunky 3y ago
        Agree, but my point was that choosing Vue today because it will still be around in 10 years doesn't mean much if it's no longer recognizable and you had to rewrite your code three times to get there.
        • 9dev 3y ago
          Agree as well, but my point was that this distinction altogether is irrelevant because the world changes all the time. Just stick with what feels right, and it’s going to be okay. There aren’t really bad choices among the popular options right now.
• rk06 3y ago
  In 15yrs, None of the current js frameworks will exist as they do now. If I had to make a project, I would bet on vue because it is community funded
  • bufferoverflow 3y ago
    I am pretty sure in 15 years React and Vue and Svelte will still be used frequently. Unless everything gets replaced by AI. We're approaching the diminishing returns when it comes to front end frameworks. All the big ones are decent. I don't feel a need to have a better framework. My bottleneck is how fast I can write logic and CSS. With complex components a lot of time is spent on managing state correctly, implementing all the minute details that the designers came up with.
    • fullstackchris 3y ago
      > everything gets replaced by AI oh god, what would that mean for the web? an unreadable mangle of JS, HTML, and CSS, even when it's in source code format? count me out!
      • bobthepanda 3y ago
        I mean, you don't have to wait for AIs to make that garbage. See: creative software like Adobe CC that technically saves to common formats
      • bufferoverflow 3y ago
        If it works, it won't matter if the source code is unreadable. As long as AI can handle it. Nobody is going to pay programmers to write clean code if AI can write working code for 0.0001% of the price.
    • JoeyJoJoJr 3y ago
      I think we are reaching diminishing returns in the current paradigm that was sparked by React, but the iterative nature of the web means that a new paradigm is bound to appear. I think there are a number ways this can go. - Some older language or tech is upgraded and crosses over via WASM - Immediate mode GUIs rendered with Canvas - Heavier reliance on the base web standards without as much build processes. Either SSR like HTMX or an event driven rehash of MVC for SPAs.
• qudat 3y ago
  It’s still typescript + react. You won’t be able to avoid it for a decade if you are in the FE ecosystem.
• hliyan 3y ago
  Highly unpopular opinion: by 2030, React will probably go the way of jQuery (i.e. a highly popular library that was once considered almost an "industry standard", but later ended up in a graveyard of projects, tutorials and articles). Difficult to say what the replacement will be, but I suspect it will be some form of plain JS + MVVM architecture, with a VM (view model) with two-way bindings, possibly natively part of the DOM, or even the DOM itself being optimised and async-ed to a point where virtual DOM diffing and similar approaches are obsolete, and an M (model) basically providing a client-side interface for the server API with some level of local caching, and providing an event listener interface for the VM to update itself. You may recognise some of these features from much older libraries, but I think a lot of them will be available natively in browsers (hopefully standardised, or in a darker timeline, fragmented between major browser vendors). Another possibility is HTMX-like partial updates getting more native browser support, essentially blurring the line between multi-page applications and SPAs.
  • threatofrain 3y ago
    2030 is an extremely long time horizon in tech years, so who knows what will happen by then. By 2030 I think a more interesting possibility is WASM everywhere. Now all language ecosystems ask whether they want to provide some frameworks or DSL for their users to deploy to web.
    • satvikpendem 3y ago
      Here's a good article about WASM based web apps by the author of the HTML5 spec: https://news.ycombinator.com/item?id=34612696 https://news.ycombinator.com/item?id=34612696 Basically he says that we should use WASM for stuff like Figma (which already does use it) or other types of web apps while keeping the DOM for content based websites.
      • jimmux 3y ago
        That would be great to see. Let the DOM focus on being a good Document Object Model.
  • 3y ago
• earthboundkid 3y ago
  Rails itself is only 19 years old. 15 years is too long to talk about what will or won’t exist with anything like a concrete prediction. At best you can say that legacy systems will still be around. If you’re a hobbyist and you tinker with your personal site or app once every couple of years and you want it to last indefinitely, just make it vanilla JS. For everyone else, it’s not a big deal to do a rewrite every five years as part of the normal maintenance cycle.
  • berkes 3y ago
    > not a big deal to do a rewrite every five years as part of the normal maintenance cycle. I see that mind often and it makes me very sad. 40+ years of computer science, bookshelves, many now must-read classics, written on software maintenance, and this is what we end up with: just throw it out. I despise this mindset in other industries (electronics, phones, toys, furniture) where, instead of designing stuff to both last, and be repairable, we just buy a new couch, phone, or blender once anything breaks. And I dislike it even more in software. I honestly cannot, an will not accept the common statement by random web agency that rebuilding this bakeries WordPress site from scratch, is cheaper than salvaging and repairing it. Nor that rebuilding some Rails backend in Go, or Nest.js the easiest. I mean: I know it often is the cheapest or easiest. But only because those in charge of the previous version never bothered about maintainability.
    • thunky 3y ago
      > I see that mind often and it makes me very sad It's not always a bad thing. It gives you the chance to do it better. When is the last time you looked at your work from 10 years ago and thought you'd do it exactly the same way today? And the cost to destroy and rebuild software is so much smaller than other industries that produce things that exist in the physical world. Why not take advantage of that? Also: job creation.
    • earthboundkid 3y ago
      Read Programming as if People Mattered from 1991. Even back then frontend was a mess of spaghetti code that needed to be periodically tossed out. That’s just how frontend works. UI is ephemeral. The backend can be pure, crystal logic that lasts for decades or maybe centuries. The frontend is a rat’s nest of conditions that will get junked as soon as fashions change. It’s the difference between manufacturing denim and selling jeans. The denim business is forever. The jeans business is constantly changing.
• codeptualize 3y ago
  The problem is the part where you think about the framework instead of what you are building! For 15 years: My bet is on React, see the amount of apps currently build on React, see multiple large companies backing it, see the #huge ecosystem, all the jobs. Even if it goes out of fashion we'll see another 15 years of it. Other mentioning React will be like jQuery supports my point: Out of fashion, but well maintained and still used a lot. (Side note: Rails is also like that imo). Svelte does an interesting thing with the compiler, but otherwise not that revolutionary, and in some parts questionable. In terms of longevity they have a ways to go. But 15 year longevity seems like a strange criteria to me. Is the app you are building really that important that it will need to survive 15 years, but not important enough to update it to newer tech? I think it's also good to realize that all the options are largely similar and only differ on details. It's a different flavor of the same thing. Learn one and you will be able to pick up the others very easily.
  • jfengel 3y ago
    Is the app you are building really that important that it will need to survive 15 years, but not important enough to update it to newer tech? I find that's not uncommon in large corporations. The app does what it does, and nobody particularly wants to rewrite it. It gradually both petrifies and rots, and yet a ton of workflows go through it. For that scenario you want it in a framework that lasts, even if it's not the best one. Some poor schmuck has to keep it limping along, and then pass it off to some other poor schmuck. Eventually the whole thing comes crashing down and you have to deal with Conway's Law -- the whole corporate structure has been built to reflect the scope of that elderly piece of software and everything cobbled to deal with it. You get to re-do it in the latest-and-greatest -- but hopefully one that will last another 15 years.
• HatchedLake721 3y ago
  In the next 15 years? Ember.js and Angular. And I wouldn't call React a framework, it's a view library. Let me explain. While there was a new React router coming out every week in early 2010s, some teams picked a batteries included framework such as Ember.js and focused on productivity and shipping rather than bikeshedding which router to use or what folder structure to have. And those teams have been upgrading their apps for over a decade since the early Ember.js versions (some even upgraded from before Ember was forked from Apple's SproutCore). Intercom swears by it https://www.intercom.com/blog/evolution-of-ember-at-intercom/ https://www.intercom.com/blog/evolution-of-ember-at-intercom... So do some Ember apps at Apple, LinkedIn, Microsoft and Heroku that have been going through this journey for years. And they will carry on. There's a new and faster rendering library out on the block? That's easy. We'll just replace the rendering engine. That's what Ember.js did in mid-late 2010s with Glimmer.js, where they dropped-in a complete replacement of Ember.js rendering engine with full backwards compatibility which was beating React in some benchmarks. https://auth0.com/blog/face-off-virtual-dom-vs-incremental-dom-vs-glimmer/ https://auth0.com/blog/face-off-virtual-dom-vs-incremental-d... So frameworks such as Ember.js, Ruby on Rails and others will still be there in 15 years, alive, with people interested in productivity rather than tinkering keeping them fresh and alive. View libraries? Yes, but in the same sense jQuery is today. It's there, it's being patched, thousands of sites use it, but there'll be better ways to do it.
  • wetpaws 3y ago
    [dead]
  • evilduck 3y ago
    There’s been more effort in the Ember community poured into telling us it’s not dead yet than into doing anything relevant outside the Ember community in the last decade. Might as well have said Dojo and Knockout, it would have meant the same thing.
    • alternatex 3y ago
      As someone who loved Knockout when the only alternative was jQuery, I can't wait for it to die. Same for jQuery and any other library that we've found better alternatives for. I'm surprised by the number of people swearing by React as if it's some holy grail of UI technology that will never die. Popularity is meaningful, but only for a while.
• MrJohz 3y ago
  I think React is always going to be a big hitter. Someone else mentioned jQuery - I don't think that's the perfect comparison, because part of what made jQuery kind of obsolete is that the browser APIs improved to the point where it just wasn't needed any more - that's just not happening with React because browsers aren't looking to ship a whole framework. But the long tail of jQuery projects is a big thing, and I think that's going to be true of React as well, at some point in the future. That said, I think it's becoming increasingly hard to see what value React specifically (as opposed to any other framework) is bringing to new projects. It's slow and heavy, but without the pre-made structure that you get from, say, Angular. It has a great ecosystem, but it's typically harder to integrate with non-React projects libraries. I know Vercel/NextJS are pushing really hard to make the big advantage of React be server-side rendering, islands, suspense, etc - the idea that you can build your entire app in React, but shipping only the code needed to change the few pieces that actually get updated in the UI. There's some merit to this in that all your templating/rendering lives in one place (and you get to use frontend templating tools, which at this point are pretty good), but I think React is the worst framework to take advantage of this idea. Partly that's because it's just very big and slow, and shipping smaller bundles is going to have diminishing returns when React is already half your bundle size, but mainly that's because React doesn't really have the architecture for these sorts of situations. There is a big assumption in React that it controls the world, which makes things like nested island very hard, and means that you need to ship lots of rendering code even if the only thing changing on screen is a CSS class. I'm talking a lot about why React isn't a good candidate for the future, which isn't really answering your question, but that's because it truly is the elephant in the room in these discussions. No-one ever got fired for choosing React, and probably won't for the foreseeable future, even if it isn't perfect. My answer, though, is Vue. Personally, it doesn't do a lot for me, I just like JSX too much and find the excessive Proxy stuff too complicated. But they've got one big advantage over React right now, and that's that they have the right architecture: signals. Signals, when done right, are a great way of skipping a lot of work and VDOM-based updates by directly updating the changes attributes. For example, if you have a class name that depends on some data, and that data changes, you don't rerender the entire component, you just update the class name directly. Currently Vue doesn't do that, but they're working on a new renderer that takes a lot of the idea from SolidJS, and that will drastically improve performance and decrease bundle size (they've released performance benchmarks that have Vue beating Svelte, although obviously take that with a grain of salt!). This is great for client-side rendering, but the best big improvement would obviously be to do less rendering overall. This comes back to Vercel and their big push for islands. One of the things you can do with Signals is, rather than do the whole SSR/hydration dance that Vercel are doing, is to ship only the signals (i.e. the application state and instructions needed to update the page). At that point, you don't even need a client-side renderer - everything just gets updated in the DOM directly. This is the direction that projects like QwikJS are going in. Of the three big frameworks, the only one that's really in a state to take advantage of these advanced is Vue. The React team aren't interested in exploring signals right now, and while the Angular team are moving in the direction, there's a lot of legacy stuff there that's going to make large changes hard. The other alternatives are smaller frameworks like SolidJS, Svelte, etc, but I think they're just too small to really get a huge amount of market share. They make great testbeds for new ideas, but are too nice overall. That said, if you're interested in the craft of frontend development, give SolidJS a go. It's pretty much pure signals, but with a React-like interface. You can explore the compiled output and get an idea of what the compiler is actually doing, and the whole thing is amazingly lightweight and fast - only marginal overheads compared to vanilla code, but with a declarative structure.
• Tainnor 3y ago
  Rails is a niche that went through a hype phase 10-15 years ago. It's not going to die any time soon, but it's also one of these languages that hasn't as many job opportunities (especially outside of major tech hubs) as other stacks. The amount of frontend JS developers is many times larger than the amount of Ruby on Rails developers so the fact that there is less "stability" is hardly surprising.
• mrieck 3y ago
  15 years? No one will do webdev with a keyboard by then. You'll be arranging UI blocks in augmented reality IDE completely powered by AI. AI will use WASM and upon request it will gladly convert to your language/framework of choice so you can view its source. Us old timers won't trust that it converted the code correctly for us to read, but the kids won't care. They'll just give it a new context/edge case examples, and have the AI rewrite everything on demand whenever they run into a problem. Looking at code will be outdated.