23 ms·

Breaking up with JavaScript front ends

• throwaway81523 4y ago
  Dang can you fix the title? Date should be 2016 per this slide: http://triskweline.de/unpoly-rugb/#/19 http://triskweline.de/unpoly-rugb/#/19 I wonder what the dependency pictures on the earlier few slides would look like today.
• eloff 4y ago
  I was just building a very light version of this today. I'm just a backend developer sick of the bloated crap I have to maintain in my day job with React. I'm going old school, and going back to server side templates. Native compiled jinja2 templates using askama in Rust, tailwindcss, Postgres, and a little JavaScript magic to do things like server side form validation without refreshing the entire page. I'm loving it so far. The pages load instantly, they're extremely lightweight, and all the state is on the server where it's easy to debug and all strongly type checked with Rust. I called my little "framework" curmudgeon, because, well I'm under no illusions about what I'm doing. Get off my lawn with those SPA JavaScript frameworks.
  • tartoran 4y ago
    It’s wonderful to build this for yourself. However, when working on our larger projects or with larger teams, they’d have to learn all the random things you came up with, in your own way of thinking and so on. That doesn’t go well sometimes but sometimes it does work out. But if you leave the project, your favorite creation could become a newcommer’s nightmare that being a reason why we need to standardize quite a bit. If someone had to maintain your code, would they feel the same way you do about the code you hate maintaining now? If the answer is a resounding no then you most likely are on the right path.
    • eloff 4y ago
      It's literally a hundred lines of JavaScript, they'd take more time to learn the changes in a point release of React. I think it's a non issue. But the bigger thing is it's just for me, because I'm the only one working on it right now. If the project is successful and I hire people one day, they'll put up with it because I'm the boss :) Meanwhile I'll enjoy working on frontend again, something that hasn't happened in years.
      • tartoran 4y ago
        Nice. Keep up then! Stay simple and nimble
• poulsbohemian 4y ago
  So if one were starting a project in 2022, what recommendations would one recommend in terms of framework, tooling, and/or the key questions to ask to determine the right frameworks and tooling? (I'm using Nuxt on a project, but not finding v3 to be as stable as I expected...)
  • debacle 4y ago
    If you ever intend to have more than 1 developer working on the project, just use React.
    • DangitBobby 4y ago
      Next.js is a solid choice if you need a server backend (and even if you don't). Whatever you want otherwise.
  • eyelidlessness 4y ago
    1. If you expect to need a build (since you’re using Nuxt now that seems like a fair given): Vite is probably the best current intersection of easy setup, good defaults, easily discoverable tweaks, high quality integrations. I’ve held off build tool churn for several projects for a couple years now, but after spinning up yet another local exploratory project with Vite today, and minimal fuss for a very unusual use case[1] I can’t recommend anything else anymore. 2. If you’re already familiar with Vue, and have no problems with it, the only reason I’d stray is because stuff in JSX-land is getting around to addressing many of the problems people (rightly or wrongly) complain about here. Weather React Server Components, Qwik which ships minimal JS bundle and data by design, or Solid with recent support for partial hydration… the component story being good for UX is increasingly compelling for JSX. I wouldn’t recommend any of these in particular unless you share more about how you’d prefer to develop. 3. If I were to recommend any meta-framework it’d be Astro. I’d have stronger recs for Solid Start but it’s explicitly not stable at present. Astro also has the benefit of being UI library agnostic which is a good gradual story. 4. Take literally all of this with a grain of salt. Part of the reason all these tools have a bad rep is from trying stuff when existing tools are imperfect but serviceable. Happy to share some ideas of where to look, but if I’m choosing anything for my current projects under maintenance I’m starting with how they can be adapted and reconfigured to solve whatever problems they don’t already solve. I’m only even looking at other tooling because there’s serious gaps in the existing setup. 1: Porting a legacy XML-centric project away from proprietary server dependencies which take ~8 min to build and has gobs of incidental complexity and tons of performance problems… to run in a browser really fast. It took a few minutes to figure out how to set up the project to load static XSLT assets as ESM modules, as well as dynamically loading XML payloads both from local fixtures and as library input. Builds are instantaneous and runtime is fast enough I can sell running it in a headless browser as a major incremental improvement. I can probably also sell scrapping a whole server target, or at least its persistence layer, because it’s fast enough the primary responsibility (caching) is either moot or solvable in the browser.
• EGreg 4y ago
  Over the last 10 years we have been growing our JS + PHP + MySQL framework and unifying the code across all concepts. We started before Promises were standard, before composer and NPM. Before Virtual DOM. Back when we started, there was CodeIgniter and Kohana and jQuery (anyone remember?) Along the way, we kept the vast majority of our code in-house. We didn’t want to pull in libraries or updates unless we understood their code. Looking at the latest and greatest, we were often wondering if we did the right thing. Some developers (especially JS) used to chastize us for not using the latest techniques like “two way bindings” of Angular 1.0 or JSX of React Then - lo and behold - Angular 1.0 is totally rewritten and all those concepts are redone. Over and over. And people come around to our way of thinking. Web Components and Templates appear. Shadow DOM. Our way of thinking is: use standards for HTTP/REST, HTML, HTTP, JS, CSS as they were intended. Every concept should work well with all the others. Result is at https://github.com/Qbix/Platform https://github.com/Qbix/Platform if you want to give any feedback. We have been using it for ALL our projects since 2011.
• darepublic 4y ago
  I don't get page transition being handled server side. They're basically just lying about that right. Maybe the server side framework baked in the page transition Js in it's response but it is still client side code
• genjii931 4y ago
  I'm loving this idea. Hating the presentation. I think a Nim backend with this would be great.
• proc0 4y ago
  Clients are getting more interactive over time. People want more interactivity, not less. Interactivity increases with visual complexity, which in turn requires increasingly complex code. UIs are evolving in the direction of more realtime updates, more animations, more menus and options, etc., etc. It's no coincidence the most popular frameworks are analogous to video game game engines. They both listen to user input, calculate the input against the state, and then render the results to the screen. It's also no surprise UIs are moving in the direction of becoming "gamified" (actual term), and adding elements that guide the user/player's attention. What this means is that we can expect UIs to increase in complexity until they match game engines, at least in terms of how it models interactivity. I should add, there will always be the static, simple pages, but web apps which are currently considered complicated will certainly keep evolving by providing a more immersive experience.
  • jonahx 4y ago
    > People want more interactivity, not less. Nobody cares about "interactivity" or "immersive" experiences except the devs who make them. People want to get their shit done as quickly as possible using software that feels simple and works as they expect the first time. A SPA might be the best way to achieve that. But often it isn't.
    • proc0 4y ago
      That's not what the trend shows. Apps have added more interactivity like live chats, conferencing calls, more editing options (i.e. editing videos when uploading to YouTube), and this is probably going to keep going adding things like voice commands, customizable layouts, and more realtime information being displayed at any given time. The reason it converges with video games, is because both are clients and both process lots of user inputs and then display the result to the screen. edit: i should add I'm not saying it's ALL going this direction, but certainly the big apps with lots of users.
      • jonahx 4y ago
        There is jump going from "I see this happening" to "this is what user's want." For example, the trend is also towards massive tracking, more ads, and heavier and heavier pages. Users don't want these things, but business forces create them. I think this is probably true of many (not all) of the kinds of things you are calling "interactivity". In any case, the reasoning isn't sound, even if you think your conclusion is.
• bellboy_tech 4y ago
  Implementing these library/frameworks are just a small piece of the application. You implement strict development policies and standards that these frameworks wrap around, fit within the architecture. Too many devs rely on the framework to be the architecture. A SPA is a piece of an overall architecture and these frameworks are still just a piece of the overall architecture. Almost all of these frameworks can/will assist in strict standardization. Bootstrap is a good example. BS with a well designed style guide is a blessing, without it's the wild west. Angular, React, Vue are all very useful (back button included) if thought out and as part of an architecture. In the end, they get you much further along with support, than a team could do with vanilla.
• chrismsimpson 4y ago
  The usage of browser history for this page is un-ironically a nightmare.
• padseeker 4y ago
  Your first problem is you're using Angular. There are ways to keep things simple with the front end, only add js for the things where you want instant visual feedback. It requires a little pushback on the part of the dev team, against UX and Product management.
• citrusx 4y ago
  Wow. So much complexity here that they seem to not realize that they've added. Feels like they're just replacing one problem with another, rather than solving anything.
• chrischattin 4y ago
  I’ve been saying this for years, and receiving the subsequent down votes. Front end frameworks are an anti-pattern. They hviolate DRY principles and exemplify premature optimization. They did not grow organically out of the open source community because they solve a problem only a handful of companies on the planet have. They had to be pushed into the dev mind share by the mega cap tech companies. Unfortunately, they’ve been successful over the years.
• deleted 4y ago
  [deleted]
• EugeneOZ 4y ago
  In 7 years they never updated their framework version, and then concluded that it's now difficult to find developers for their mess. What a surprise!
• deleted 4y ago
  [deleted]
• thayne 4y ago
  This reminds me a lot of frames [1]. I wonder if the creators are aware that at one time html did have a way to update different parts of a page independently, but due to various limitations, it fell out of favor and is now deprecated. [1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/frame https://developer.mozilla.org/en-US/docs/Web/HTML/Element/fr...
• mathgladiator 4y ago
  The complexity of the modern web is very off putting to me, but I'm an old timer that spent too long in the land of infrastructure. I'm doing something similar to HTMX or HotWired, but with 100% vertical ownership. I posted about this some time ago: https://www.adama-platform.com/2022/06/26/making-html-the-best-it-can-be.html https://www.adama-platform.com/2022/06/26/making-html-the-be... ; where I am at today: https://book.adama-platform.com/rxhtml/ref.html https://book.adama-platform.com/rxhtml/ref.html The core thesis is to turn the browser into a RIP terminal ( https://en.wikipedia.org/wiki/Remote_Imaging_Protocol https://en.wikipedia.org/wiki/Remote_Imaging_Protocol ) to some degree where the server is 100% in control like a BBS/MUD. As an example app, the main IDE uses it, and it's great how lean everything is. I'm enjoying going my own path.
• wenincode 4y ago
  As a front end developer, i have to agree. Sometimes i think it’s time for me to move on from this role.
• dools 4y ago
  Many years ago a colleague and I wrote a stand-alone version of a package for my own arcane php framework called Remote. The idea was that you write in Web 1.0 and immediately get a Web 2.0 front end because it just updates what it needs to. I still think this is the holy grail of frontends: https://github.com/dgrinton/remote-standalone https://github.com/dgrinton/remote-standalone
• flerp 4y ago
  I thought the days of manic JS bashing was gone
• globalise83 4y ago
  As a web developer, I can now distribute and "install" a sophisticated software application on the work or home computer of one of my users within less than a second just by sending them to a specific link, and that user can even use it offline, with a lightning-quick database saving all of their data for them. Pretty awesome if you ask me! None of that would be achievable without Javascript frontends.
  • happyweasel 4y ago
    whut? You can simply distribute a statically linked binary that does not require admin rights to run? Stores its data in the local users data folder.. How big could a chat app be, for example .. 10mb? 20mb? (without excessive resources) ? With minimal memory use? Use WTL and plain platform api? Pretty doable IMHO. With a lot less dependencies and probably lightning fast dev iteration cycles.
• throwaway4good 4y ago
  Well ... at least they are not doing Coffeescript.
• robot 4y ago
  one of my startup projects failed in 2014. one reason was the complexity slide shown for 2014. After that experience I don't do SPAs anymore. React only complicated the problem further and it is expensive for anyone creating their own projects to hire react devs. what's worse is new devs think react is the best thing to learn and start with that.
• reverseblade2 4y ago
  Probably broken when run inside shadow dom like htmx. Next please?
• 9064035767 4y ago
• zelphirkalt 4y ago
  What most people do not get is, that modern frameworks long have allowed for a mixed approach. One can easily render templates server side in a backend non-JS framework and merely use some VueJS or whatever for a really interactive component on one of those rendered templates. Can even have a noscript block. It will be easy to understand code, work without people having to trust JS code, except for those few interactive parts. No harm done. Instead people go all in and think that it will be better to have everything in JS as an SPA. This SPA unnecessarily approach eats up so much time, it is not rare for things to take weeks instead of days compared to simply rendering templates on the server side in a better language than JS. It should be a simple thing to understand: Use the right tool for the job. Not JS for everything, just because of hype. But I guess part of the issue is the mentality of some frontend people to only learn JS, so they are incapable to going for the mixed approach.
• sir71 4y ago
  This dance, shuffling code between backend and frontend, has been happening for a long time. It's not the first and not the last time someone claims to have found a solution (not even the best, just a solution for certain scenarios). That is fine until the client comes up with a new requirement that completely demolishes your assumptions, or some new awesome JS API appears, and then we're back to SPAs. Ups, who could have known, right? A couple years later, browsers adapt and a bunch of people, again, come up with a revolutionary idea: if we squint a little we can just about squeeze that code on the backend and save a bunch of work. Until new big products come out that change what users consider state of the art and... It's a never ending cycle. SPAs are a pain in the ass, like all distributed systems are, but they're also the most flexible and you don't need to reinvent half your framework or use dirty hacks if you have to do something slightly out of the beaten path. They're not the problem. The real friction comes not from where you put the code but from the fact that you have to use different languages with different ecosystems. I'd claim most of the arguments against SPAs would suddenly disappear if one could write most of the code in whatever, compile to WASM, and slap a generic JS bridge on top.
• pagekicker 4y ago
  Switched to Streamlit, haven't looked back.
  • jerrygenser 4y ago
    From what I've seen streamlit seems to be very focused on data science interactive dashboard type apps. Have you been able to develop much more extensive that power e.g. multiple pages and user interface driven workflows with streamlit?
• jpgvm 4y ago
  I don't want a server side Javascript framework, the whole reason I stick with server side rendering is to avoid Javascript/Typescript/hellscape.
• mnming 4y ago
  An option that keeps both UI fidelity and server side simplicity is to use: https://inertiajs.com/ https://inertiajs.com/
• jerrygenser 4y ago
  I originally tried using htmx a couple of times because I was a stubborn backend engineer that needed/wanted to build some frontends. The idea of partially swapping subset of DOM made a lot of sense especially as a way to make old school full page reload style more modern. However, I migrated to react-router 6.4 and it has a very similar concept of embracing web technologies and partials can be defined as an outlet of another page where only the data for the partial and dom for the partial is loaded if sub sub-tree is navigated in. They say they took this idea from emberjs. I felt the same way as the authors of unpoly and many in this thread looking at most UI frameworks until I stumbled on react router 6.4, and it very much enabled me, a primarily backend engineer, to be productive in the frontend. I highly recommend it to people who are trying htmx but want something that is more IBM "No one ever got fired for picking react"
• pmarreck 4y ago
  The cost of maintaining up to date JS (security patched, fixing breaks in functionality afterwards, etc.) seems larger than any boutique site with 1 dev could handle. I’ve been exploring ripping all my JS out and using LiveView instead for this reason.
• alexplz 4y ago
  I find the complexity graphs to be a little misleading. If the client side complexity grows, but server side complexity doesn't decrease at all, then something has gone wrong. If you have a fully client-rendered SPA (not saying an SPA is the only thing you should ever build, but many of the complaints seem to be aimed SPAs), then why do you still need Models, Controllers, and Views on the server? Or Routing for that matter. Many modernish SPAs would handle all the routing client side. So your backend complexity might look more like: Asset Packing, API, Authorization, Dependencies So you've moved some of the complexity from the server to the client. You may or may not like that, and there may still be a net increase in overall complexity, but it's not the same as necessarily suddenly 2x complexity. Also I don't know what Authorization is doing in both graphs. Or why Virtual DOM is there - yes you might be using a Virtual DOM, but it's presumably part of one of your dependencies, and not something you're interacting with directly or maintaining. Also what is a "Controller" in React? React (and similar frameworks) don't fit neatly into the MVC paradigm. I guess it's more like Components + Models? Although the Components aren't always cleanly separated from Models/business logic, which can be a strength and a weakness.
• _-----_ 4y ago
  I felt like this post was, "SPAs suck, here's a new lightweight SPA."
• intrasight 4y ago
  Wow - lots of opinions on front-end dev. Not much of a surprise. It is a bloated mess. But "breaking up with JavaScript"? There's no way to build anything useful without JavaScript. Build it without frameworks? Absolutely! Build with HTMX? Makes sense to me. It's a light-weight and isolated extension. It would be great if such partial load semantics was added to the web standard. Isn't the core question whether the web client is stateless or not? My front ends have been very stateful for long time. But I build desktop equivalent web apps. I jumped on the AJAX track in 2000 and never looked back. My state has been represented in XML ever since. I sync with server via "updategram" semantics (borrowed from SQLXML), and transform state into HTML with XSLT in the browser. I use no frameworks or libraries/ Has served me very well for 20 years and likely will until retirement.
• togaen 4y ago
  lol, and yet the page doesn’t load with JavaScript disabled
• im_down_w_otp 4y ago
  I would love a way to view this exact same content as a long form vertical scrolling article/post rather than as a virtual slide deck.
  • ramesh31 4y ago
    Yeah, perhaps if only there were a structured markup language that could be used to provide this information in an accessible manner with separation of concerns between content and display.
    • krapp 4y ago
      impossible!
      • zelphirkalt 4y ago
        Frontend guy: I've heard about a new framework, which dynamically loads content from APIs!!11 With that we can surely manage to do this!
• Mountain_Skies 4y ago
  Two arrows until the concept was too annoying to bother with indulging.
• l1n 4y ago
  http://youtube.github.io/spfjs/ http://youtube.github.io/spfjs/ seems like it does much of this for me
• 22289d 4y ago
  If this page is a demonstration of what a future without JavaScript would look like, it's an unintentional advertisement for sticking with JavaScript.
  • JohnFen 4y ago
    I can't tell, because their site won't render without JS enabled, and I'm not willing to enable it for them.
    • cgrealy 4y ago
      The title is poorly chosen at best and misleading at worst. They’re not abandoning JavaScript, they’re just abandoning client side rendering (angular, etc)
  • futureproofd 4y ago
    I think the intention was to spark conversation loosely around SPAs vs SSR. It seems we're at yet another turning point and frankly, I'm enjoying the debate.
• tail_exchange 4y ago
  And the solution was to turn their website into a powerpoint presentation?
  • omnimus 4y ago
    Don't want to break this to you but this is a presentation not their website.
• Waterluvian 4y ago
  Warning: if you want to look at the content of this page, say goodbye to your back button.
  • ledauphin 4y ago
    yeah, this was particularly ironic. The back button has evolved alongside SPAs, and users mostly don't expect or want their back button to take them back through the hundreds of small state changes they've caused by interacting naturally with a UI.
    • omnimus 4y ago
      Because it's not website. It's a reveal.js presentation. It's on purpose so you don't get out of it when presenting.
  • simple10 4y ago
    Yep. Browsed the slides and then couldn't go back to HN using the back button. Is there a max history depth setting per domain in Chrome? I haven't run into this issue in awhile and forget why it happens.
  • qudat 4y ago
    This was pretty brutal.
  • omnimus 4y ago
    This is not a website. It's a presentation made with reveal.js framework. This has been made as slides for a talk. It is very much feature that people accidentally don't back out of their presentation while they are doing it.
    • Waterluvian 4y ago
      There’s a browser API for preventing people from leaving pages if they are in a context like that. And unlike this method, it works for the first page, works if you try to close the tab, and works if you try to navigate to a different link. And it doesn’t become entangled with browser navigation.
• MForster 4y ago
  Unreadable on a phone...
• whoIsYou 4y ago
  huh? this page is unusable. is this a spoof?
• qrohlf 4y ago
  Seems like a half-baked agency-built version of htmx[1], no? I'm actually very intrigued by the whole "let's take a step back and move a lot of our logic back to the server" approach to modern dev, but IMO when you need more than statically rendered pages, it should look a lot more like htmx or Phoenix LiveView (if you're using a framework) or something ultra-minimal like Slimvoice[2] if you want to go the bespoke route. Not this. [1] https://htmx.org/ https://htmx.org/. [2] https://javascript.works-hub.com/learn/a-javascript-free-frontend-61275 https://javascript.works-hub.com/learn/a-javascript-free-fro.... https://slimvoice.co/ https://slimvoice.co/
  • ramesh31 4y ago
    >I'm actually very intrigued by the whole "let's take a step back and move a lot of our logic back to the server" approach to modern dev, What's old is new again. There's an entire generation of developers now who have no concept of the old world. They started with React/Angular/Vue and have no idea that SSR was the standard default for decades. And now it's a "new idea" that is held up against JS development with no understanding of why and how we got to where we are, and the tradeoffs that were made along the way.
    • whatever1 4y ago
      SPAs solved a labor problem I think. It was the reason that front end development grew so fast. It is much faster to train people on a combo js+css framework rather than training someone on backend languages, databases, queues, authentication, scaling + html & css for server side rendering.
      • JackMorgan 4y ago
        A lot of dev managers like that they can turn one team into two teams by splitting everyone into front and back end. This makes hiring easier. I cannot emphasize this enough. Easier hiring is a huge deal. As a secondary effect it also allows for more kingdom expansion. It's much easier to have two teams of five than one team of ten. That being said, I'd rather manage a team of five good full stack engineers than ten average front/back end engineers. The communication cost of trying to get features out the door with two teams of five is very high.
• deleted 4y ago
  [deleted]
• throwaway0x7E6 4y ago
• jrochkind1 4y ago
  It's interesting that they appear to plan to use with Rails as a back-end (they mention Rails bindings), as Rails 7 release corresponded with a solution which appears somewhat similar to me, turbo/stimulus. (I want to provide a link to it, but I honestly don't know any great docs for it!) But I haven't used stimulus/turbo myself. I'd be interested in a compare/contrast between Rails' Stimulus/turbo and "Unpoly" covered here. There also seem to be a number of other non-Rails-related offerings in this space too. They seem to be really multiplying, which I think shows the exhaustion with JS front ends and desire for things in this space (I am not sure quite what to call it). But I wonder if we can converge on one or two instead of creating more and more. One of the benefits of a popular layer is that you can start building share-able re-usable solutions which compose with it -- you can find lots of solutions for certain things for React, like you used to be able to for JQuery, but splitting between stimulus/unpoly/htmx/etc...
  • ransom1538 4y ago
    "I want to provide a link to it, but I honestly don't know any great docs for it!" I setup a demo, rails7/mysql[1]/turbo/docker - one command setup you are playing with it. https://github.com/james-ransom/rails7-on-docker-mysql https://github.com/james-ransom/rails7-on-docker-mysql. Give me a star you have a friend for life! * not Postgres!!
    • jrochkind1 4y ago
      I don't consider a demo app with no docs (that presumably uses stimulus and turbo?) to be anything to close resembling good overview docs on what stimulus and turbo are, but thanks.
  • NegativeLatency 4y ago
    The readme seems to give a pretty good overview of turbo: https://github.com/hotwired/turbo-rails https://github.com/hotwired/turbo-rails
    • jrochkind1 4y ago
• xutopia 4y ago
  While I don't know that I'd go that route to build my own thing when Rails 7 already has turbo_streams and Stimulus I understand wholeheartedly why they'd move away from SPA-for-everything. I can't help but feel that the whole industry is under the spell of React and other single page application frameworks and use them even if other ways would have been faster to build, cheaper to maintain and less complex.
  • cldellow 4y ago
    It's worth noting that this presentation is from July 2016, and Rails 7 was released in December 2021.
• quechimba 4y ago
  Nice, though it would be nice to eliminate the need to write any JS. I disagree with page 17, I think server side apps could handle those things fine if they were made to support them. I've been working on a Ruby framework with all the fancy stuff (reactive VDOM, hot reloading, scoped css) but it's 100% server side. Imagine React, but with Ruby and Haml instead of JS, and all logic runs on the server. The GitHub link can be found in my comment history. It's not ready to be used for anything serious, but I think it's an interesting approach and maybe there is someone who would like to play with it.
• sph 4y ago
  Needs a (2016) in the title. The situation is even worse now.
  • jillesvangurp 4y ago
    I would say things are improving. Through WASM we are now getting more languages running in the browser. They are starting to bring alternative frameworks and ways of doing things to the table as well. Instead of this frontend / backend notion, we should start thinking again about the notion of networked applications; like we used to do before the web became a thing. Inevitably you want some computation to be close to the source data (for efficiency) and some other computation to be close to the point of interaction (for responsiveness). It's not an either / or proposition. You can do both. And phones and browsers can do a lot locally these days. So there's no need to pretend that it is still 1999 in terms of browser capabilities. They can do so much more now. Instead of AJAX, we now have companies like Tailscale doing all sorts of funky networking stuff in a browser. Likewise, people are running entire 3D games, photo and video editing tools, or design tools like figma, etc. in a browser. All enabled by WASM. Most of that stuff does not involve a whole lot of css, javascript, or html. That stuff is increasingly optional. Browser application development and desktop application development are finally merging after being considered completely separate things for more than 2 decades. It's all just application development. It may or may not involve talking to servers via a network. You don't have to limit yourself to HTTP when doing that.
    • steve1977 4y ago
      How is WASM different from what we had with Java applets? (haven’t looked deeply into WASM yet, so seriously asking)
  • riskable 4y ago
    At this point web development has become so complex and fast-changing that by the time you're done explaining how everything works the whole world has moved on to the next generation of complexity. We're almost at the point where web development is becoming "unknowable"; like knowing the position of an electron... You can know where it was at some point (maybe) but really the best you can do is estimate its rough position in the cloud.
• skilled 4y ago
  I think innovation needs to happen in package management. Has it happened yet? Because I don't know for sure, so I am asking because I might have overlooked it. Even projects from a few months ago can be become unusable unless you are willing to sit down and spend a couple of hours fixing the problem. And don't get me started on packages that have been abandoned altogether but are like glue to functional software. (I am talking about npm)
  • bottlepalm 4y ago
    Innovation isn’t going to prevent people from abandoning projects. You have to make smart decisions when adding dependencies based on how mature and supported is it. This often means sticking with the big names even if the little project has more hype.
• rickreynoldssf 4y ago
  TL;DR: We did JavaScript wrong and now we're going to do it even more wrong.
• spritefs 4y ago
  > We're breaking up with JavaScript front ends > Site doesn't load properly with javascript disabled They should put their money where their mouth is
  • dpacmittal 4y ago
    I think it was about breaking up with SPA frameworks/libraries. The whole slideshow is about unpoly which is a JS library which provides SPA like experience without the complexity of a full blown SPA
  • ncr100 4y ago
    Maybe this is an abandoned site? - Site does not support HTTPS https://triskweline.de/unpoly-rugb/#/ https://triskweline.de/unpoly-rugb/#/ => breaks
• jesprenj 4y ago
  https://xkcd.com/927/ https://xkcd.com/927/ There are fourteen competing standards ...
• 29athrowaway 4y ago
  (2016)
  • 29athrowaway 4y ago
    I summon @dang in attack mode. Can you add (2016) to the title? Thanks
• blubberblase42 4y ago
  This is a published presentation not a blog post. That was the reason to use this format.
• simonw 4y ago
  What's the accessibility story for Unpoly? I'm always interested in ways of building partial page fetches, dropdown menus etc in a way that is thoroughly tested to work well with common screenreaders. I'd love to see a frontend framework that includes detailed documentation (and ideally video demos) demonstrating how effective their ARIA screenreader stuff is.
  • omnimus 4y ago
    Why would the story be different than SPAs? The screenreaders read final html in the browser. It shouldn't matter if comes from server rendered template OR javascript template rendered on the client. Seems like it depends on how you code the html/templates not how they are rendered?
    • simonw 4y ago
      SPAs very often have terrible accessibility. I think it's important for frameworks that help people build interactive applications (SPA or otherwise) to provide the best possible defaults, plus guidance as to how to use them to build accessible interfaces.
  • triskweline 4y ago
    Unpoly lead dev here Unpoly takes special care to always move the focus to the next relevant element in an interaction. E.g. when a link updates a fragment, the focus is moved to that fragment. Or when an overlay is closed, focus is returned to the link that originally opened that overlay. More details can be found here: http://triskweline.de/unpoly2-slides/#78 http://triskweline.de/unpoly2-slides/#78 Feel free to install a screen reader and play with the demo app (https://demo.unpoly.com/ https://demo.unpoly.com/).
    • thrdbndndn 4y ago
      Probably the right place to ask this: The slide said > DEMO OF SERVER-SIDE APP ISSUES > Link to demo app (https://demo.unpoly.com/ https://demo.unpoly.com/) > (press Start Classic on first page) but there is no “Start Classic”?
• jokoon 4y ago
  Why can't anybody talk about the fact that HTML was not designed for being dynamic? Isn't there any format that is a real alternative to HTML, which is truly interactive, lighter than the DOM, use text as a mediu, is multi usage and platform agnostic, can use whatever scripting language, and be easily rendered? It's not another new format, it's just that a new format is needed to make things simpler. I have zero patience when it comes to learn angular and its framework model thing. I don't want framework, I want formats and protocols. I don't even know gopher but something new and fresh and different is really needed. Maybe as long as it's used in a controlled environment for internal/pro software.
  • atomicnature 4y ago
    This is on point. The frameworks will always remain crippled due to the underlying platform. Of all the things in the Web Landscape, WebAssembly seemed like a practical move towards what you are speaking about. You can compile Rust/Golang/C++ into a "Web Binary", which in turn can be shipped realtime to clients. However, there's a long way to go, before WebAssembly works as a smooth container environment with better APIs for enhancing the user/dev experience for dynamic apps.
  • npilk 4y ago
    Have you tried htmx? Maybe HTML wasn't designed to be dynamic, but IMO htmx does a great job extending it to provide interactivity in a way that feels natural and simple.
  • temporallobe 4y ago
    HTML wasn’t designed to be dynamic but it certainly evolved to be, and personally I don’t think it’s that bad per se, but modern frameworks such as Angular and React have added so many unnecessary layers of complexity, that most developers have to reason about and work with several layers of abstraction just to make simple things work. There isn’t a real alternative because all the popular modern browsers only fundamentally understand HTML, and have been evolving and refining this over the past three decades or so. What would be nice is to have a new markup that is natively rendered and handled by the browser and that behaves similar to the document/page model everyone is used to but with built-in persistence, session handling, and dynamic rendering with a very simple and intuitive API. Obviously we have all of these already in one form or another but it’s all just hacked-together HTML/JS/CSS under the hood. Edit: minor corrections because mobile devices suck
• artursapek 4y ago
  You should break up with web based front ends and write them in Rust. :-) https://iced.rs https://iced.rs
  • awesomegoat_com 4y ago
    That's the correct answer! Btw, client can run rust in WASM, so no reason to keep javascript in there either!
    • satvikpendem 4y ago
      Soon Flutter will have WASM support too, so it'll be a great time. I've been looking into stuff like Iced, Yew, Tauri etc but the multiple client situation for cross platform isn't too great, unlike with Flutter.
  • rawrenstein 4y ago
    > It is inspired by Elm, a delightful functional language for building web applications. That killed my interest instantly.
    • artursapek 4y ago
      Top HN response dismissive and rude, 100% reliable
    • sheerun 4y ago
      For me it's TODO all over
  • deleted 4y ago
    [deleted]
• francisofascii 4y ago
  > Looking for developers to maintain 150K lines of Angular 1.5 and 7000 abandoned npm packages. I completely get that reason. Any front-end framework app is on live support in a few years. It feels like the equivalent of buying a cheap refrigerator that will break in 4 years, that is easier to get a new one rather than try to fix the old one.
• TheRealPomax 4y ago
  This appears to be from 2016, so probably needs a [2016] in the title.
• awesomegoat_com 4y ago
  Good job. This is the next trend out there. Although, this solution feels to be heavily inspired by https://hotwired.dev/ https://hotwired.dev/ Is there a reason, why new framework (with some extra cool features) have been developed as opposed to contributing to hotwired/turbo frames?
  • bluewalt 4y ago
    The presentation is 6 years old...
• coin 4y ago
  What an annoying website to navigate. Almost unusable on an iPad.
• pjmlp 4y ago
  As someone that pretty much has stayed with Java and .NET SSR frameworks, with snippets of dynamic content where it makes sense, this kind of back and forth is kind of ironic.
• kyleyeats 4y ago
  This is so overdue. I'm ecstatic to see this finally happening. The frontend framework bloat trend honestly went on ten years too long. It was like the thin client and thick client debate turned into the thick client and thicker client debate. People will roll a gigantic create-react-app mess for the tiniest of frontend projects. Yes, it's an instant codebase! But that's all code you have to maintain. Stuff like hotwire and htmx can't come fast enough.
  • tobr 4y ago
    I don’t see the difference. Isn’t backend code code you have to maintain too?
    • PKop 4y ago
      You need a backend anyways. Shifting to a server-side codebase is eliminating duplication, and arguably server languages have better DX so win win.
      • tobr 4y ago
        That might sound convincing to someone who already prefers working on the backend, but you can basically invert your statement to describe a typical serverless setup: “You need a frontend anyways. Shifting to a client-side codebase is eliminating duplication, and arguably browsers have better DX so win win.”
        • spoils19 4y ago
          Most backend developers are used to maintaining high quality codebases, however. On the other hand...
          • personalidea 4y ago
            Uhh. Cheap shot, very constructive…
        • 4y ago
• vladstudio 4y ago
  Probably worth mentioning that the submitted link is just the presentation by the author of Unpoly, with some history and reasoning, but the better explanation of Unpoly itself is on their website: https://unpoly.com/ https://unpoly.com/ Essays on HTMX website also help a lot: https://htmx.org/essays/ https://htmx.org/essays/
  • jb_s 4y ago
    I didn't even realise it was a presentation until this comment. I was clicking stuff and scrolling trying to see content.
• pacomerh 4y ago
  your site needs JS to work though. People love the sensational headlines
• etchalon 4y ago
  This slideshow is relatively old, and frameworks have gotten better, not worse, since then. Server-side DOM mutation is deeply interesting, but I don't think it can be grafted onto existing server-side frameworks. Someone will need to rethink the MVC model with client-side state in mind.
• Erikun 4y ago
  Am I missing something? They say to "Start classic" or "Start enhanced" on the first page of the demo app but neither is there for me.
  • triskweline 4y ago
    Author here. The link is a 6 years old presentation. The demo app has since been rewritten. The old demo app focused on the downsides of classic multi-page apps (MPAs), i.e. the reason the world moved to SPAs all these years ago. In an MPA clicking a link loses all transient state, like focus, scroll positions and unsaved form state. This can all be solved with updating fragments instead of full pages, while still keeping rendering logic on the server.
    • Erikun 4y ago
      Ah, mystery solved. Thanks.
• synergy20 4y ago
  I still think separating frontend from backend makes life easier even though frontend has been chaotic for a decade, and it shows no sign to slow down
  • oblak 4y ago
    Depends on what you're doing. There is great value in SSR but how does one even make anything dynamic/interactive without JS? You can't, so you start adding pure non-spa tainted js. Then you add features until your amazing purist solution is an unworkable mess stuck in the mid 2010s.
    • omnimus 4y ago
      This is just problem of structure. I am not convinced that there is particularly higher chance to end up with "unworkable mess" with SSR compared SPAs (of course most projects end up being a mess). If you look at the hottest trend of the "island architecture". New frameworks like Astro (https://astro.build/ https://astro.build/) and Fresh (https://fresh.deno.dev/ https://fresh.deno.dev/). They are basically what are you describing. All SSR but with dynamic parts. Seems like these "islands" by their nature are less entangled than full SPA.
  • pron 4y ago
    Separating the frontend from the backend doesn't necessarily mean putting all of the frontend logic in the client. Your server can also have separate frontend (or "view") logic.
• noidiocyallowed 4y ago
  Nice font usage.
• poisonborz 4y ago
  Much of this and more was achieved with NextJS. Yes, javascript, but you have absolute control of what you want to render server- or client-side. You don't have to write APIs. And you still have the massive Node or React catalog at your fingertips. I don't think there is a better realisation currently for what they aimed for in this presentation.
  • bottlepalm 4y ago
    Yep started a new project after a month of getting up to date with all frameworks old and new.. Next.js really is the best option right now it seems.
• LAC-Tech 4y ago
  I got very excited at the premise and the first few slides, thinking someone was going to talk about what a secret weapon vanilla JS is for productivity...only to find out they're advocating use of a front end library much larger than react or Vue. At this point I'm getting a bit tired of backend people claiming that the cure to the frontend mess is a big library that pretends to be html.
• deleted 4y ago
  [deleted]
• mattlondon 4y ago
  This is where Angular shines Vs React et al. One "batteries included" library that does everything, no external dependencies unless you go out of your way to add them. I have (and still do) written SPAs that only use Angular and nothing else. I don't even have NPM installed.
• aristofun 4y ago
  Breaking up with JavaScript frameworks by creating another JavaScript framework, really?
  • 0xblinq 4y ago
    C’mon, put a minimum effort to understand what it’s all about before making useless comments. It is not a framework to organize your own JavaScript (like react, vue, etc). It is a framework so that you don’t have to write JavaScript in the frontend. Of course it is written in JavaScript, because that’s the only thing that can run on the browser.
    • aristofun 4y ago
      C׳mon, put a minimum effort to realize, that it was the same kind of original intention behind any js framework - so that you don’t have to write something unnecessary. This is absurd statement. It doesn’t mean that the OP framework is bad or that SPA idea is not generally abused etc and doesn’t call for some changes etc. It’s just a ridiculous and somewhat arrogant way to promote your yet another fancy js thing.
      • 0xblinq 4y ago
        And you still don’t get it. Nevermind
        • aristofun 4y ago
          No, I get you perfectly.
• satvikpendem 4y ago
  Looks very similar to what NextJS is doing, especially with their app directory API [0], ie have everything on the server with React Server Components but then stream in client-side JS as necessary. It's basically the "sweet spot" that TFA talks about. [0] https://beta.nextjs.org/docs/routing/fundamentals https://beta.nextjs.org/docs/routing/fundamentals
• WesSouza 4y ago
  Not secure
• olingern 4y ago
  Like others have mentioned, this seems to be from ~2016. The lack of HTTPS on the provided link ages this some for me, but the use of coffeescript really dates this[1]. I even thought coffeescript had been deprecated, but it does seem that the project is being kept alive[2] which is really cool. Perhaps, what is most interesting is that it took nearly 4-5 years for the front-end community to collectively come to the conclusion that SPAs are not _always_the answer. I don't think the zeal for SPAs came from a bad place either. I can remember how poorly ASP.NET and other frameworks of the 2008-2012 era packaged an overcomplicated way to pass data to view layers. There's lots of curmudgeon-ining from non-frontend folks but, in my opinion, the lack of performance and ergonomics with existing frameworks, combined with the newness of Node.js is what brought about the explosion of tooling and frameworks. There is a place for SPAs, though. VS Code, Spotify, and other apps that need a desktop / browser experience to feel like a mobile app are great candidates. Twitter, for example, shouldn't be a SPA or SPA-like application. I find that it frequently over-caches content and will randomly refresh my feed at times while I'm browsing. It feels as if a simple web page that needs to deliver more JSON responses as I scroll is trying to do too much. 1 - https://github.com/unpoly/unpoly https://github.com/unpoly/unpoly 2 - https://coffeescript.org/#changelog https://coffeescript.org/#changelog
• dougdonohoe 4y ago
  Sort of sounds like Apache Wicket (https://wicket.apache.org/ https://wicket.apache.org/). I used it for a few projects in the mid-late 2000s. I really liked it being server side and the concept of having object-oriented HTML (code paired with HTML snippets). I haven't had a need to use it since 2014, so haven't kept up with the project.
• ostenning 4y ago
  The biggest problem facing the front-end space today isn't so much of complexity of a particular library, rendering technique, or view/model architecture, but rather lots of bad ideas glued together, creating nightmare scenarios for companies trying to maintain products. A micro dependency system with never ending breaking changes to glue different tools and libraries together - bad idea. Using un-opinionated "libraries" that don't scale well, but at scale - bad idea. Technology organizations trying to stay relevant by simply adopting every next hyped fad out there, rather than stepping back to get a bigger picture of what the front-end space actually needs - bad idea. The list goes on, for quite a long time. And all of these issues are further exacerbated by an army of junior developers entering the front-end development space, along with recruiters subscribing to buzzwords to hire them.
  • _djvl 4y ago
    This! The problem is also that as our apps grow the server side part of it and the client side part of it grow at pretty much the same rate. For each new functionality added on the backend we end up writing more UI code. This is a problem. We need start thinking of how a UI frontend can be implemented as a separate app completely independent and agnostic to the backend. To the extent that I can simple take the same frontend code and plug it to any compatible backend and things will just work. We need to develop a frontend client that can work with any backend (your app, my app, her app). The UI across all apps is mostly the same and we keep rewriting the same JS/HTML (albeit using different JS libraries) each time we build a new app. This is the problem. Let's start thinking of how we can build a general-purpose frontend client which doesn't work on low-level details (JS/HTML) but on higher level abstractions.
  • eastbound 4y ago
    Hiring is my problem. They all want to use NPM/React/any fad or not do front-end at all.
  • mckravchyk 4y ago
    I use React and Svelte for different projects. I keep things really simple and it's rare that I need to rely on an external runtime dependency (build tools are another thing), if something is relatively small I will code it myself. I have also built my own state management library (not open sourced yet) that is literally exactly what I wanted out of state management, so I don't need to rely on gazillion plugins to make something possible, I just code it myself.
• TheRealDunkirk 4y ago
  I don't understand why so many people are dismissing this because the post is from 6 years ago. Looks like the project is still actively maintained, which, after the 3 lifetimes that 6 years represents in development timelines, seems to be a stroke in its favor.
• anujdeshpande 4y ago
  Genuine question : Is anyone building a 10 year JS framework? Something similar to how we’ve had C standards - we had c99 and then c11 (followed by c17)
  • holysantamaria 4y ago
    http://vanilla-js.com/ http://vanilla-js.com/
• tannhaeuser 4y ago
  Since TFA is from 2016, it's pretty silly to discuss about trends here isn't it? There's certainly no less JS today, except due to being there less web sites in the first place. What's with this htmlx shilling anyway? If you want an app, just use JavaScript; what's the point of arbitrary syntactical barriers between page content and logic, except for maybe CSS done by UX experts - though if you're bad at CSS then why tf are you into web frontends anyway? If OTOH you think about content-heavy sites, document-oriented workflows, and publishing (ie. what the web was originally made for) then just use a competent markup processor. HTML is based on SGML after all, giving you templating, markdown processing, stylesheets, pipelines, toc and search indexing, and whatnot; there's a wealth of SGML/XML-based tools available.
• crystaln 4y ago
  They were using Angular - enough said.
• nixpulvis 4y ago
  Stop breaking my god damn back button!
• deleted 4y ago
  [deleted]
• holysantamaria 4y ago
  I still don't consider myself a veteran but I saw the web evolves from 2010 up til now. And imho we took a wrong direction. Web apps and pages have become so bloated and complex that's crazy. I'm just starting to recover from my previous work. I had to maintain migrate and add features to a legacy system (built in 2017) which had initially a GraphQL api and a SPA, but that was later split in 12 microservices (with cycling dependencies because hey why not) and 3 Big react applications, all of that in Javascript + Typescript (added later with all the gradual typing stuff that makes you think that your code is correct). All of that to serve 300 monthly users between 35 and 50 years old, who just cared about filling forms here and then and have some charts over data. 0 rocket science. So far I remember history going like this: - 2010 Clean SSR with rock solid boring technologies and some vanilla JS where it made sense, I remember page load where crazy fast and you could not feel the need for an SPA. - 2012 NodeJS arrives. It came to save us from slow blocking IO apparently (??) - 2016 React arrives. It came to save us from boring old SSR apps - 2017 All React + SPA frameworks (in house often) - 2017+ Someone has the brillant idea to do SSR with React. "It's a revolution" - 2017 GraphQL arrives. You are saved. - 2020 Nextjs arrives. You can now do static generation for SEO and SSR and apis ! That's great. Thank you Next ! - 2022 Someone wants now to do Server Component that will make your page load going insanely fast (which we already did in 2010 when we carefully loaded vanilla JS at the time) I learned a bit of ASP.net core recently, and I think that boring razor pages are still relevant. I remember my first lead in 2010 telling me that ORMs and SPA where completely overrated. I didn't agree with him at that time. Now 12 years later I think he might have been correct. I'm not saying SPA have not their place. Some apps can't do without it. I'm saying that we are victims of "hype driven development" which involve having some trendy hashtags in your resume and convince your manager that you have seen an incredible new tech that will make the business incredibly wealthy. Except it does not and you end up with a legacy system that nobody wants to maintain because too complex. Maybe like Jonathan Blow stated in one of his videos, we make a confusion between going forward and progress. Now all the new kids learn React in some boot camp or online but have no idea how to implement a map function. And I feel old and grumpy. And tired by all this.
  • jcmontx 4y ago
    > ASP.net core recently, and I think that boring razor pages Came to a similar conclusion lately. It's a superior, cleaner alternative to traditional MVC controllers. Currently building a side project with Razor Pages + HTMX.
• aussieshibe 4y ago
  Maybe it's just me, but needing to press "back" twenty or so times to get back to HN after viewing some of this presentation really made me question the author's authority when it comes to "how the web should work".
  • eyelidlessness 4y ago
    Unfortunately this particular delivery used a typical slide presentation which deviates from a bunch of its message; and unfortunately polluting history is a pretty typical problem with these slides-as-webpage affairs. I really wouldn’t conflate the medium (which is pretty much typical of the web way before complexity as timelined) in/for the message.
  • majkinetor 4y ago
    Its a matter of preference. I prefer to go to previous presentaton page. You should learn to use browser - there is right click on back button
    • aussieshibe 4y ago
      Maybe in your browser you have that option. Not for me.
  • quickthrower2 4y ago
    Not sure. Does everything on a public url need to be friendly to random forum shares? Maybe this is good enough for the people who needed to see it.
    • aussieshibe 4y ago
      It doesn't need to be, but it certainly undercuts the message a bit if it's not.
• locallost 4y ago
  The key question for me is not whether there is too much complexity, but whether or not this complexity is something that adds value for the actual user. Too many things do not actually do that. I use too many pages where I know it's some kind of an SAP simply because the user experience is buggy, clunky and shitty. Why that is, is a really big topic and there could be many reasons, but it's not really discussed.
• account-5 4y ago
  I haven't scroll the whole way through, and am a complete novice to webdev but this is reminding me of htmx a little. Is it just me?
  • zach_garwood 4y ago
    Unpoly predates htmx by a couple years.
    • recursivedoubts 4y ago
      htmx is intercooler.js 2.0 intercooler.js started in Dec 2013: https://github.com/bigskysoftware/intercooler-js/commit/62d3dbdb5c056ee866aba3575e148de649fc3efe https://github.com/bigskysoftware/intercooler-js/commit/62d3... unploy started in Dec 2014: https://github.com/unpoly/unpoly/commit/6d1691815b9c89f10e9b349d1c2136862eac6c7b https://github.com/unpoly/unpoly/commit/6d1691815b9c89f10e9b...
• mr90210 4y ago
  GOOD FUCKING LUCK
• deafpolygon 4y ago
  I wonder how much traction we could get with a no-JS approach.
  • quickthrower2 4y ago
    Modern browsers make a no-JS (and that means not even HTMX) fairly nice. Live updates might be an issue but if you don’t need those… When the browser can reason about your site it opens up nice cool stuff like right click to open in a new tab, bookmarks always working, fast load times, caching, etc.
• mtoddsmith 4y ago
  Problem: we hate frameworks Solution: creates new framework
• Aaronmacaron 4y ago
  Micro dependencies and dependency hell are two of the Javascript ecosystem's most frequently mentioned issues. Anyone aware of any initiatives to lessen dependencies in important projects? For instance, the typical number of dependencies in a JS project would probably decrease significantly if large libraries and frameworks like webpack, babel, react, etc. all stopped using dependencies like left-pad or is-boolean (and also a bit more sophisticated ones). It would probably be sufficient if the top 1% of packages tried to remove as many dependencies as they could, because those are the dependencies that 90% of developers use. Additionally, large packages likely have the resources to implement helper libraries on their own rather than relying on them.
• matchagaucho 4y ago
  Web front ends have been expanding, per Parkinson's Law, to fill the bandwidth allotted. If it's not an explosion in JS/CSS from frameworks, it's the content image/video size. Upside is that a "fast" user experience is easily achieved by defaulting to first principle JS capabilities of the browser, and delivering compressed content from the CDN edge.
• seandoe 4y ago
  Welp, I couldn't back out of that site after making 100 url changes. Your argument would be a lot more convincing if you addressed that issue. That's such an old issue, please don't bring that back with your new throw-back style.
  • zach_garwood 4y ago
    This is a slide show presentation. The website is here: https://unpoly.com/ https://unpoly.com/
• koonsolo 4y ago
  The biggest problem with front-end development is that it goes all the way from static websites to complex web apps, and developers can't tell the difference. Everyone jumps on the latest hype, going from either server to front-end, or nowadays front-end to server side, without thinking where your application resides on that scale.
• tmd83 4y ago
  The one reluctant use I see of JS based UI (does anyone have an alternative solution?) is to reuse API. Right now we have two code path one where a user action renders the html server side and returns it another where an API call for similar work returns a JSON. A JS UI page can consume the JSON and can render the page reusing the core API. What's the solution to such a use case?
• iainmerrick 4y ago
  Is there a version of this that’s, like, a web page? That you can just scroll through in a couple of minutes, rather than clicking and waiting for a second or two after each tiny slide?
• shinzui 4y ago
  The title should have been breaking up with Angular. I posit that they would have had a much different experience using react with relay and graphql.
• throwaway81523 4y ago
  This is nice but it is from 2016. I wonder if that system is still working and maintained.
  • marvinblum 4y ago
    It is. I just implemented a system using Unpoly this year.
• mawadev 4y ago
  From my experience, the horrors of javascript come from letting the client handle too much stuff. Frontends tend to run a ton of logic that should be handed off to the proper tool for the job: SQL. The time and complexity you save on the backend is simply not put to good use these days. I like to program SPAs like a reactive thin client and let the backend be more SQL or ORM heavy.
  • cpursley 4y ago
    This is not just JS frameworks. Many backend frameworks are overly ORM dependent in my opinion.
    • mawadev 4y ago
      That is true. I have seen a big aversion to writing JPQL or native SQL whenever an ORM like Hibernate or JPA is involved. It seems to be like you home in on a single technology and try to make it fit it into things where another tool can do a better job in less lines of code. I once worked with a team where the devs didn't know what hibernate generates inside the database, it was shocking how much trust is in these layers of abstractions. The concept of unique and foreign key constraints, sequences or indexes was unknown. It may be cleaner to you and written in the same language you are familiar with, but some problems simply aren't that easy to solve.
• xg15 4y ago
  What's the problem with simply writing a JSON API in the backend and vanilla javascript on the frontend? Where does all that complexity come from?
• Sujeto 4y ago
  Just use vanilla js. Re-use helpers on utils.js files. Refactor big utils into libraries.