Show HN: Sapper.js – towards a better web app framework • Hacker News Board

Re: Show HN: Sapper.js – towards a better web app framework

#161

Post by cryptica » Tue, Jan 02, 2018, 11:55 PM UTC

Isomorphic frameworks are a bad idea. I'm convinced that any attempt at making a single general-purpose web application framework will fail. I've seen it happen too many times before.

SocketStream, Derby, and even MeteorJS which had massive funding and marketing just couldn't do it. NextJS is just the next generation of fools who didn't research the market... Surely we can at least wait for NextJS to go belly up before launching yet another project that's going to waste several more lifetimes of human effort.

There was nothing wrong with the implementation of the MeteorJS project by the way... The problem was the idea itself. All the marketing and funding it received only served to delay its inevitable demise.

Re: Show HN: Sapper.js – towards a better web app framework

#162

Post by nikcub » Wed, Jan 03, 2018, 12:00 AM UTC

rich_harris wrote: post #30

skrebbel wrote: post #29

I've been following Rich's work on Rollup, Svelte and now Sapper with interest and great awe. I truly believe he's onto something. At the same time, if I were designing something like this, I'd use a tool like Flow or TypeScript in a heartbeat. Doing AOT optimization is so much easier when you have type guarantees, I'm sure that once you go deep enough you get into all kinds of little issues that are only issues beca…

Thank you. Svelte itself is written in TypeScript so I'm a believer. I'd like to get first-class support for TypeScript in components at some point. Adding .ts support for the non-component parts of a Sapper app should be fairly straightforward (it's just a webpack config after all) — will add that to the TODO list.

> Svelte itself is written in TypeScript

I completely missed this as I looked at the sample project and saw js files - this has me going back and taking a second look, so you might want to mention it.

Re: Show HN: Sapper.js – towards a better web app framework

#163

Post by jondubois » Wed, Jan 03, 2018, 12:13 AM UTC

gedy wrote: post #3

Tankenstein wrote: post #2

As always, my main concern with this is traction. Will this be well supported, with a good community, 4 years down the line? I know React will, just because of the massive amounts of business depending on it. When building something real, i have to think about this because i need to be able to hire developers and actually develop my product instead of rewriting it. That aside, the idea of svelte is cool, and i'm happ…

I think the big benefit here (and most of Rich Harris's projects) is less "will this be the next big thing?" as it is pushing the client-side app world forward with new ideas and questioning status quo. Rich balances these "wild ideas" with solving practical problems and I'm always impressed.

Oh yeah I forgot to factor in the irrefutable fact that Rich is a genius and everyone else who tried building a full stack framework before him was an idiot.

Re: Show HN: Sapper.js – towards a better web app framework

#164

Post by [deleted] » Wed, Jan 03, 2018, 12:18 AM UTC

lassejansen wrote: post #137

rich_harris wrote: post #89

Earlier quoted context omitted.

What about when you start clicking the links in the nav, or opening other stories and profile pages? As far as I can see, the Sapper version blows the original out of the water.

The Sapper version is cheating a little. It is preloading the pages on mouseOver events of the links.

[deleted]

Re: Show HN: Sapper.js – towards a better web app framework

#165

Post by arxpoetica » Wed, Jan 03, 2018, 12:24 AM UTC

nwmcsween wrote: post #133

Could webpack be replaced with something else? IMO webpack is a giant mess.

Have you had a look at Rollup.js (incidentally by the author of Sapper).

Re: Show HN: Sapper.js – towards a better web app framework

#166

Post by rich_harris » Wed, Jan 03, 2018, 12:25 AM UTC

DougWebb wrote: post #159

lassejansen wrote: post #137

Earlier quoted context omitted.

The Sapper version is cheating a little. It is preloading the pages on mouseOver events of the links.

It's not just cheating a little. Just moving the mouse around the page causes lots of data to be downloaded behind the scenes; you could end up loading every story on HN without ever leaving the Top list. That's not friendly to user's data plans, and it's very far from expected browser behavior.

It's configurable. Add rel=prefetch to an element and you'll get that behaviour; don't, and you won't. Since the links are small, mousing over them tends to suggest you intend to click them, but the exact behaviour is subject to refinement over time (this is pre-1.0 software, adjust your expectations accordingly).

Incidentally, 'cheating' is a bit of a silly word to use for a feature designed to improve UX that people spend a lot of time trying to implement (see e.g. http://instantclick.io/)

Re: Show HN: Sapper.js – towards a better web app framework

#167

Post by zsck » Wed, Jan 03, 2018, 12:25 AM UTC

weego wrote: post #128

scottmf wrote: post #42

Earlier quoted context omitted.

I feel like a lot of HN is stuck in 2010 and dislikes all of this new web tech because they don’t understand it. This comment is a prime example.

I am willing to concede your pedigree as a developer as necessary but I've been writing all manner of languages and environments since 99 and I'm sorry to say there's no revolution here, no battlefield to die on. It's a poor model that has been tried and abandoned any number of times in my career. The ubiquity of platforms that suit these ideas and developers who think Web development began with node and spas isn't c…

This is an incredibly common stance, and it's also very obviously problematic. No one is saying that your experience in software is invalid or that you're wrong about "these modern frameworks" having been wrong in their time. However, if you aren't yourself working as a frontend developer in a modern startup-ey development environment, you aren't in a position to make so many assumptions about the problems such developers do or do not have. Surely, as professionals and adults, we can all appreciate that we are each dealing with problems in the world for which people believe we deserve to be paid. We all take what we do seriously, and are trying to build the best tools we can to do the best work possible. Even if something comes in as a fad, what good is it to bawk at a perfectly valuable learning experience?

Re: Show HN: Sapper.js – towards a better web app framework

#168

Post by fineline » Wed, Jan 03, 2018, 12:44 AM UTC

rich_harris wrote: post #147

atoko wrote: post #143

Earlier quoted context omitted.

That syntax looks arbitrary and frankly, hell to mantain. The cost:benefit ratio of learning all these idioms ("idioms", a huge red flag) doesn't seem efficient at all. I apologize for being blunt, yet I still recognize your work as great for pushing boundaries in web development. What made you turn away from javascript and into templates?

Simply put, you can do more with templates. It's the Principle of Least Power at work — the same way you can do more with a blob of JSON than a blob of JavaScript, templates allow you to do things that are basically impossible with JSX, such as compiling to a string concat function for server-side rendering that is much, much faster. Ask the teams behind Glimmer, Marko, and other tools, and they'll tell you the exact…

Hi Rich, I notice you mention Marko. That was my first thought when checking out Svelte today - Marko uses somewhat similar approach, and thus brings somewhat similar benefits. But Marko has couple of other advantages - beautiful "concise" syntax option, and easy debugging at dev time as the Lasso bundler turns JS modules into equivalent files in the browser, complete with same line numbering. (It only works with CommonJS modules, but that's what I prefer to use anyway as it allows unit testing in Node without transpilation.) What advantages would you say Svelte has that would make me consider using it over Marko? Thanks.

Re: Show HN: Sapper.js – towards a better web app framework

#169

Post by leeoniya » Wed, Jan 03, 2018, 12:58 AM UTC

mlsarecmg wrote: post #124

pwaai wrote: post #109

How many of you actually built a React/Redux stack SPA that actually came anywhere near what Sapper offers? The file size problem is underrated. Not everybody walks around with 5G like in South Korea. Not everybody has the latest and greatest Samsung or Apple phone. It's a big problem when you advertise PWA as quick and fast but then in tiny letters mention its using the best case on best network and best phone. If y…

You can boil down react to virtually nothing. preact-compat turns it into 4kb. Redux + router don't add that much. The loading impact, if you watch out, code split, isn't the dire problem. As for laggy experience, Fiber is the only feasible attempt at the moment to actually tackle it. Microbenchmarks will not help and neither Svelte nor anything else will make a webapp fast on a slow phone as baseline diffing has nev…

> Imagine an app with 100.015 rows

i can imagine an app like this. and such an app would have been designed with 0 thought given to the actual usability by humans. the proper solution is to provide sorting, grouping, filtering and pagination. your UIs should be small enough to remain fast without insane optimization tricks. mobile and even desktop browsers are plenty slow at rendering/reflowing 100k DOM nodes; the fastest way to render this is simply not to.

it's not as if suddenly you don't have to worry about the shitty UX and performance of your app's architecture "because fiber".

Re: Show HN: Sapper.js – towards a better web app framework

#170

Post by unclebucknasty » Wed, Jan 03, 2018, 1:21 AM UTC

DougWebb wrote: post #18

Sorry, I couldn't resist. Second and third paragraphs, with some minor editing: HTML is close to this ideal. If you haven't encountered it yet, I strongly recommend going through the tutorials at https://www.w3schools.com/html/ . HTML introduced a brilliant idea: all the pages of your app are files in a your-project/pages directory, and each of those files is just an HTML page. Everything else flows from that breakth…

>HTML is close to this ideal

HTML is anything but ideal. In fact, it's the core of the problem where Web applications are concerned. HTML and its kin (particularly CSS) were designed for content-oriented Web pages, not Web applications.

Continuing to devise Web-app frameworks that are predicated upon developers wrangling HTML for controls and CSS for layout will lead to more iterations of frustration; only to perhaps slightly lesser degrees. It doesn't matter if you write JS that renders it or templates. It's the same problem.

What's needed is a component-framework with proper tooling (including IDEs) for layout and design. We've solved this with Swing and even Visual Basic. So, for the life of me, I still can't figure out why we haven't moved in this direction full-on for Web frameworks. If the issue is that HTML and CSS are standards with broad support, then I concur: but compose the app via a proper GUI and let the tooling generate the HTML/CSS.

It's odd: we use Webpack, Browserify, etc. for full on Web-app builds, along with various cross-compilers for JS. But, at the end of the day, we're still writing HTML-based templates (or JS) and CSS.

This is generally an unpopular view on HN. But, I can nearly guarantee that the next truly meaningful advancement in frameworks will be via a component-oriented approach that abandons direct manipulation of Web standards like HTML/CSS altogether.