6 ms·
The question is: how many of these will be maintained several years later? Can you build a long term project on these? Or the expectation is that one has to ma
by dmortin 8y ago
The question is: how many of these will be maintained several years later? Can you build a long term project on these?
Or the expectation is that one has to make a new UI anyway every several years to keep up with the changing fashion, so rewrites are inevitable?
- ggregoire 8y agoIf you pick one made by a big company, it should be fine.
- _eht 8y agoThat's what I thought when I integrated Google Wave into my companies workflow... /s
- quickthrower2 8y agoGoogle is the exception that proves the rule.
- mkozlows 8y agoHow's your Silverlight app working out for you? Does it still connect to your WebObjects server?
- quickthrower2 8y agoI prefer WPF :-). Touche, but Google has more of a habit of killing off perfectly good stuff. But MS does it too. With Silverlight market forces, especially HTML5/mobile and Apple policies most likely killed it.
- Cthulhu_ 8y agoI noticed the sarcasm, but, Google Wave never got out of beta (iirc) so anyone seriously adopting it knew what they were getting into. Same with gmail which was in beta for years for some reason - probably because they wanted to avoid liability for lost data etc.
- s_kilk 8y agoOr Angular v1
- winrid 8y agoWe're very productive with Angularjs...
- jameslk 8y agoThey're open source right? Would you expect to build your own design language, responsive/accessible components, documentation and maintain it any better than an open source solution?
- anyzen 8y agoThese frameworks are inevitably much more generic than any in-house solution. On one side this is great, because it means that the abstractions need to be sensible - but it also means there is much more code to maintain. So yes, sometimes maintaining your own solution will be easier than maintaining an abandoned opensource solution. Of course, even better would be to use a solution which will not be abandoned. Also note that these frameworks lock you into design & feel of their choice. This might work for some use cases and for now, but when the requirements change you often end up fighting the framework. I don't have a solution to that though. :)
- jameslk 8y ago> So yes, sometimes maintaining your own solution will be easier than maintaining an abandoned opensource solution. I'd argue this depends on your needs. If you're using one of these for your consumer-facing product, perhaps so. Otherwise, if your UI is not what you're selling or your product/team is big enough to end up creating one of these from scratch anyway, then no. In the latter case, that's probably why there's so many of these to begin with. > Also note that these frameworks lock you into design & feel of their choice. Some of these frameworks actually let you re-theme them. For example, Ant Design can mostly be re-themed.
- jazoom 8y agoThat's a false dichotomy. The third option is the obvious one: use a framework that will be well-maintained.
- quickthrower2 8y agoJetbrains would be my bet. They'll look after it even if it doesn't become the most famous library.
- pjmlp 8y agoJetbrains is the new Borland, but I hope that their management doesn't come up with an Inprise idea.
- wccrawford 8y agoThank you for this comment. I hadn't noticed that they had a ui library and I agree that they'll probably take care of it even if it's not popular. Very nice.
- Cthulhu_ 8y agoSure, if it works now, it'll work ten years down the line as long as they're not doing anything nonstandard. There's a big fear that projects that become unmaintained suddenly stop working; this isn't correct. Besides, all webapps are rebuilt in a 3-5 year cycle anyway so it really doesn't matter.
- pjmlp 8y agoDo you feel like rewriting a bunch of webapps written in Perl/modapache around early 2000? I know of at least one company with such a stack. Just like I know others with Web Forms, Stucts, SEAM, JSP, Zope and many other stacks in production. Not everyone re-writes their webapps, specially in companies where software is a cost center and totally unrelated to their main business.
- codingdave 8y agoSure, I'd be happy to. Converting apps from an old platform to a newer platform is reliable work, and I've done my share of it over my career. It often is structured as temporary projects, so I've had the opportunity to travel to short-term gigs in new cities while I build out platform conversion plans. Sure, not everyone re-writes old apps. But enough companies do it to make it a decent professional specialty to cultivate. And it doesn't hurt knowing both the modern stacks and multiple generations of legacy stacks when working with large organizations. Sign me up.
- lazerwalker 8y ago"Works" and "is maintained" are two very different things.
- LaGrange 8y ago> Besides, all webapps are rebuilt in a 3-5 year cycle anyway so it really doesn't matter. And I thought places I worked at tended to be terrible :/
- megous 8y ago> There's a big fear that projects that become unmaintained suddenly stop working; this isn't correct. While true, it only applies if you don't want to upgrade your lower level dependencies, ever. And given that this is a React based framework, so it's not based directly on the web platform, if it's not maintained, you'll have to port the framework yourself. Coversely, if it is maintained, you may be forced to keep up and upgrade whatever this is based on, or backport fixes if the project moves on to a newer incompatible version of the lower level dependency. > Besides, all webapps are rebuilt in a 3-5 year cycle anyway so it really doesn't matter. Eh? :D I still iterate on 13 or 9 year old codebases for my clients without re-building anything.
- ergo14 8y agoI think rewriting UI systems every few years and reimplementing in various JS frameworks that come and go is a serious waste of manpower. I'd so wish people would embrace web components properly once and for all, with LitElement, Svelte or Stencil. This way we won't have to live with another framework-bootstrap clone again and again and everyone can contribute to one solution that will work with all JS frameworks.
- chrisweekly 8y agoobligatory xkcd: https://xkcd.com/927/ https://xkcd.com/927/
- nicoburns 8y agoProblem is, web components don't provide the same thing as frameworks like React. And the performance question still hasn't been solved. React was released in 2013, has only had minor breaking chanhes since then, and doesn't show any signs of disappearing anytime soon.
- ergo14 8y agoLit-html is faster than react + vdom - and has 6kb instead of 60kb. And back in the time everyone used jquery, the arguments are always the same.
- naasking 8y agoWhere's the benchmark showing this?
- ergo14 8y agohttps://stefankrause.net/js-frameworks-benchmark8/table.html https://stefankrause.net/js-frameworks-benchmark8/table.html - thats old lit release there vs react 16 (react pre 16 would be slower and everyone agrees its generally fast already), on slack channel I believe I saw newer release benchmarks that are better (it also depends at which specific test you look at). New version of repeat is interesting: https://slack-files.com/T03PF4L4C-FCY51FZAB-c2fcf32931 https://slack-files.com/T03PF4L4C-FCY51FZAB-c2fcf32931
- bradstewart 8y agoThe alternative is to write all of the components yourself. Using one of these frameworks helped us avoid that cost upfront and get the product out the door. If our company is still around in several years, I'll happily maintain it myself (or hire the original author). EDIT: This comment assumes the framework of choice is open source.